[Geoserver-devel] release testing

Taking conversation to Jira:

Known issue:

  • GEOS-7482 404 when logging in from certain pages

I still have not caught up with everything from Chris Snider’s excellent testing (thanks Chris).

···


Jody Garnett

On Wed, Apr 20, 2016 at 2:28 AM, Jody Garnett <jody.garnett@anonymised.com>
wrote:

Taking conversation to Jira:
- https://osgeo-org.atlassian.net/browse/GEOS-7507 shutdown.bat (not a
priority)
- https://osgeo-org.atlassian.net/browse/GEOS-7507 windows service jetty
wrapper
- https://osgeo-org.atlassian.net/browse/GEOS-7508 unable to start dmg
due to spring-security exception
- https://osgeo-org.atlassian.net/browse/GEOS-7509 windows installer
startup.bat path

Known issue:
- GEOS-7482 404 when logging in from certain pages

Hi Jody,
I've made a pull request that seems to fix GEOS-7482, have a look here:
https://github.com/geoserver/geoserver/pull/1579

It basically determines on the fly the appropriate number of ../ to use the
in the login form,
depending on the requested page URL. Other possible fixes would have been
to build
an absolute URL and then use the url manglers, but I'm not sure we want the
UI links
to be subject to proxy handling and the like.

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

I was wondering about the j_spring_security_check endpoint on the pages. I recalled seeing something from Justin back in March about the endpoint changing to /login.

“In terms of compability issues the only issue I have found thus far is the issue with the spring security login endpoints changing (ie. /j_spring_security_check is now /login).”

Did spring not actually change to login?

Chris Snider

Senior Software Engineer

Intelligent Software Solutions, Inc.

Description: Description: Description: cid:image001.png@...3926...

(attachments)

image001.png

···

On Wed, Apr 20, 2016 at 2:28 AM, Jody Garnett <jody.garnett@…403…> wrote:

Taking conversation to Jira:

Known issue:

  • GEOS-7482 404 when logging in from certain pages

Hi Jody,

I’ve made a pull request that seems to fix GEOS-7482, have a look here:

https://github.com/geoserver/geoserver/pull/1579

It basically determines on the fly the appropriate number of …/ to use the in the login form,

depending on the requested page URL. Other possible fixes would have been to build

an absolute URL and then use the url manglers, but I’m not sure we want the UI links

to be subject to proxy handling and the like.

Cheers

Andrea

==

GeoServer Professional Services from the experts! Visit

http://goo.gl/it488V for more information.

==

Ing. Andrea Aime

@geowolf

Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)

phone: +39 0584 962313

fax: +39 0584 1660272

mob: +39 339 8844549

http://www.geo-solutions.it

http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.


On Wed, Apr 20, 2016 at 3:28 PM, Chris Snider <chris.snider@anonymised.com>
wrote:

I was wondering about the j_spring_security_check endpoint on the pages.
I recalled seeing something from Justin back in March about the endpoint
changing to /login.

“In terms of compability issues the only issue I have found thus far is
the issue with the spring security login endpoints changing (ie.
/j_spring_security_check is now /login).”

Did spring not actually change to login?

I'm not sure, but that was the first actual change that I've tried, making
the home page use "../login" instead of "../j_spring_security_check" and
... it did not work
at all (no login working, not even the main home page, let alone from the
others).

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

I am sneaking in a small low-risk Resources bugfix from Niels (merged on master):

GEOS-7493 Path.names not removing root slash
https://github.com/geoserver/geoserver/pull/1565
https://osgeo-org.atlassian.net/browse/GEOS-7493

Kind regards,

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

I just started the release builds.

I had a comment on 1565 on this change to ResourceAdapter:

private ResourceAdaptor(File file) {

  • this.file = file;
  • this.file = file.getAbsoluteFile();

I wanted to make sure that this change was on purpose, since it changes the capability of the class in some respect.

···

On 20 April 2016 at 14:54, Ben Caradoc-Davies <ben@anonymised.com> wrote:

I am sneaking in a small low-risk Resources bugfix from Niels (merged on master):

GEOS-7493 Path.names not removing root slash
https://github.com/geoserver/geoserver/pull/1565
https://osgeo-org.atlassian.net/browse/GEOS-7493

Kind regards,


Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand


Jody Garnett

Jody, it is not essential to get this into 2.9-beta2. If it is not included, then please change the Fix Version of GEOS-7493 to 2.9-RC1.

I considered the impact of the change you noted below, and also whether it should be getCanonicalFile (and I thought not). As far as I know, there is no new requirement for the file to exist, and this change did not break any resource theory tests. How do you think it changes the capability of the class? It is a change that caught my attention too. Thanks for your eagle-eyed scrutiny!

I could speculate why this change was made but I would rather let Niels answer for himself. Niels?

Kind regards,
Ben.

On 21/04/16 10:10, Jody Garnett wrote:

I just started the release builds.

I had a comment on 1565 on this change to ResourceAdapter:

          private ResourceAdaptor(File file) {
- this.file = file;
+ this.file = file.getAbsoluteFile();
              ...

I wanted to make sure that this change was on purpose, since it changes the
capability of the class in some respect.

--
Jody Garnett

On 20 April 2016 at 14:54, Ben Caradoc-Davies <ben@anonymised.com> wrote:

I am sneaking in a small low-risk Resources bugfix from Niels (merged on
master):

GEOS-7493 Path.names not removing root slash
https://github.com/geoserver/geoserver/pull/1565
https://osgeo-org.atlassian.net/browse/GEOS-7493

Kind regards,

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

We have three things:

  • Configuration stuff in the data directory → resource api
  • Files ( relative files in the data directory, absolute files for external references ) - should only be used as connection parameters now
  • and this thing ResourceAdaptor which served to bridge the two worlds during the transition

So I guess I want context? If the transition is done (I think it is!) then yes ResourceAdaptor could be restricted to only using absolute file references.

What was the need to convert a relative filename to an absolute file name? Whatever the need was it strikes me as a gap in the story above…

···

On 20 April 2016 at 15:26, Ben Caradoc-Davies <ben@anonymised.com> wrote:

Jody, it is not essential to get this into 2.9-beta2. If it is not included, then please change the Fix Version of GEOS-7493 to 2.9-RC1.

I considered the impact of the change you noted below, and also whether it should be getCanonicalFile (and I thought not). As far as I know, there is no new requirement for the file to exist, and this change did not break any resource theory tests. How do you think it changes the capability of the class? It is a change that caught my attention too. Thanks for your eagle-eyed scrutiny!

I could speculate why this change was made but I would rather let Niels answer for himself. Niels?

Kind regards,
Ben.

On 21/04/16 10:10, Jody Garnett wrote:

I just started the release builds.

I had a comment on 1565 on this change to ResourceAdapter:

private ResourceAdaptor(File file) {

  • this.file = file;
  • this.file = file.getAbsoluteFile();

I wanted to make sure that this change was on purpose, since it changes the
capability of the class in some respect.


Jody Garnett

On 20 April 2016 at 14:54, Ben Caradoc-Davies <ben@anonymised.com> wrote:

I am sneaking in a small low-risk Resources bugfix from Niels (merged on
master):

GEOS-7493 Path.names not removing root slash
https://github.com/geoserver/geoserver/pull/1565
https://osgeo-org.atlassian.net/browse/GEOS-7493

Kind regards,


Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand


Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand


Jody Garnett

When you to take the path of a resource, it isn't possible to derive from the path whether it is absolute or relative in Linux (Resource paths according to the specs do not support relative paths and make no difference between a starting slash and no starting slash).

I don't think this would be dangerous or affect anything. ResourceWrappers are used to provide simple files to objects and methods that expect a Resource. They should be threaten like a normal resource, and are mostly used to directly read and write to it.

Returning a relative file path from a resource provides incomplete, nonsensical information to somebody who just wants to use the resource API.

This change simply guarantees that the path returned is unique and makes some kind of consistent sense to somebody who is following the resource API.

Regards
Niels

On 21-04-16 00:26, Ben Caradoc-Davies wrote:

Jody, it is not essential to get this into 2.9-beta2. If it is not included, then please change the Fix Version of GEOS-7493 to 2.9-RC1.

I considered the impact of the change you noted below, and also whether it should be getCanonicalFile (and I thought not). As far as I know, there is no new requirement for the file to exist, and this change did not break any resource theory tests. How do you think it changes the capability of the class? It is a change that caught my attention too. Thanks for your eagle-eyed scrutiny!

I could speculate why this change was made but I would rather let Niels answer for himself. Niels?

Kind regards,
Ben.

On 21/04/16 10:10, Jody Garnett wrote:

I just started the release builds.

I had a comment on 1565 on this change to ResourceAdapter:

          private ResourceAdaptor(File file) {
- this.file = file;
+ this.file = file.getAbsoluteFile();
              ...

I wanted to make sure that this change was on purpose, since it changes the
capability of the class in some respect.

--
Jody Garnett

On 20 April 2016 at 14:54, Ben Caradoc-Davies <ben@anonymised.com> wrote:

I am sneaking in a small low-risk Resources bugfix from Niels (merged on
master):

GEOS-7493 Path.names not removing root slash
https://github.com/geoserver/geoserver/pull/1565
https://osgeo-org.atlassian.net/browse/GEOS-7493

Kind regards,

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

Oh and why this was necessary. In the tests, path logic is used to create new resources.
That is why it is necessary the paths make consistent sense.

For example, If there are two files
1) one has relative path "/some/file" inside "/some/base"
2) the other one has relative path "/some/file" inside "/some/other/base"

You make a resourcewrapper from each of those. Both will return the same path().
If you create a new resource from that path, at least one of them is going to be pointing at a different file.
That doesn't make any sense.

And again, all I did was follow the official API which says relative paths are not supported.

Regards
Niels

On 21-04-16 11:24, Niels Charlier wrote:

When you to take the path of a resource, it isn't possible to derive
from the path whether it is absolute or relative in Linux (Resource
paths according to the specs do not support relative paths and make no
difference between a starting slash and no starting slash).

I don't think this would be dangerous or affect anything.
ResourceWrappers are used to provide simple files to objects and methods
that expect a Resource. They should be threaten like a normal resource,
and are mostly used to directly read and write to it.

Returning a relative file path from a resource provides incomplete,
nonsensical information to somebody who just wants to use the resource API.

This change simply guarantees that the path returned is unique and makes
some kind of consistent sense to somebody who is following the resource API.

Regards
Niels

On 21-04-16 00:26, Ben Caradoc-Davies wrote:

Jody, it is not essential to get this into 2.9-beta2. If it is not
included, then please change the Fix Version of GEOS-7493 to 2.9-RC1.

I considered the impact of the change you noted below, and also
whether it should be getCanonicalFile (and I thought not). As far as I
know, there is no new requirement for the file to exist, and this
change did not break any resource theory tests. How do you think it
changes the capability of the class? It is a change that caught my
attention too. Thanks for your eagle-eyed scrutiny!

I could speculate why this change was made but I would rather let
Niels answer for himself. Niels?

Kind regards,
Ben.

On 21/04/16 10:10, Jody Garnett wrote:

I just started the release builds.

I had a comment on 1565 on this change to ResourceAdapter:

           private ResourceAdaptor(File file) {
- this.file = file;
+ this.file = file.getAbsoluteFile();
               ...

I wanted to make sure that this change was on purpose, since it
changes the
capability of the class in some respect.

--
Jody Garnett

On 20 April 2016 at 14:54, Ben Caradoc-Davies <ben@anonymised.com> wrote:

I am sneaking in a small low-risk Resources bugfix from Niels
(merged on
master):

GEOS-7493 Path.names not removing root slash
https://github.com/geoserver/geoserver/pull/1565
https://osgeo-org.atlassian.net/browse/GEOS-7493

Kind regards,

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

What about this guys https://github.com/geoserver/geoserver/pull/1556
Is there something holding this back, it is a minor fix for spring security LDAP. I would expect this to be merge before release

Regards
Niels

On 20-04-16 23:54, Ben Caradoc-Davies wrote:

I am sneaking in a small low-risk Resources bugfix from Niels (merged on
master):

GEOS-7493 Path.names not removing root slash
https://github.com/geoserver/geoserver/pull/1565
https://osgeo-org.atlassian.net/browse/GEOS-7493

Kind regards,

I talked to damiano about his tests and therefore I would merge it.

That said, please, open a jira, describe the problem and reference the
JIRA in the PR.

Regards,
Simone Giannecchini

GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more information.

Ing. Simone Giannecchini
@simogeo
Founder/Director

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 333 8128928

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate.
Il loro utilizzo è consentito esclusivamente al destinatario del
messaggio, per le finalità indicate nel messaggio stesso. Qualora
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo
cortesemente di darcene notizia via e-mail e di procedere alla
distruzione del messaggio stesso, cancellandolo dal Vostro sistema.
Conservare il messaggio stesso, divulgarlo anche in parte,
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità
diverse, costituisce comportamento contrario ai principi dettati dal
D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely
for the attention and use of the named addressee(s) and may be
confidential or proprietary in nature or covered by the provisions of
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New
Data Protection Code).Any use not in accord with its purpose, any
disclosure, reproduction, copying, distribution, or either
dissemination, either whole or partial, is strictly forbidden except
previous formal approval of the named addressee(s). If you are not the
intended recipient, please contact immediately the sender by
telephone, fax or e-mail and delete the information in this message
that has been received in error. The sender does not give any warranty
or accept liability as the content, accuracy or completeness of sent
messages and accepts no responsibility for changes made after they
were sent or for other risks which arise as a result of e-mail
transmission, viruses, etc.

On Thu, Apr 21, 2016 at 11:41 AM, Niels Charlier <niels@anonymised.com> wrote:

What about this guys https://github.com/geoserver/geoserver/pull/1556
Is there something holding this back, it is a minor fix for spring
security LDAP. I would expect this to be merge before release

Regards
Niels

On 20-04-16 23:54, Ben Caradoc-Davies wrote:

I am sneaking in a small low-risk Resources bugfix from Niels (merged on
master):

GEOS-7493 Path.names not removing root slash
https://github.com/geoserver/geoserver/pull/1565
https://osgeo-org.atlassian.net/browse/GEOS-7493

Kind regards,

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel