[GeoNetwork-devel] Spring Security in GN

GeoNetwork GeoNetwork Developer
1

hello list,

I’m wondering if it was really necessary to remove the classic xml.user.login authentication ?

This breaks backward compatibility. For example for users of the GN harvester protocol, and for anyone who made their own tooling.

Would it not be possible to adapt the classic authentication and authorization approach to the new configuration, in a way that backwards compatibility is not broken ?

Kind regards
Heikki Doeleman

2

we could add a rewrite rule possibly for backwards compatibility. We don’t think it is easy to change the new login url because while it can be a different url I don’t think it can be have the srv/… portion of the url because spring creates the service.

···

On Tue, Nov 13, 2012 at 1:48 PM, heikki <tropicano@anonymised.com> wrote:

hello list,

I’m wondering if it was really necessary to remove the classic xml.user.login authentication ?

This breaks backward compatibility. For example for users of the GN harvester protocol, and for anyone who made their own tooling.

Would it not be possible to adapt the classic authentication and authorization approach to the new configuration, in a way that backwards compatibility is not broken ?

Kind regards
Heikki Doeleman

Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

3

but is the url the only thing to it ?

with the changs to user-profiles.xml, etc …

···

On Tue, Nov 13, 2012 at 1:48 PM, heikki <tropicano@anonymised.com> wrote:

hello list,

I’m wondering if it was really necessary to remove the classic xml.user.login authentication ?

This breaks backward compatibility. For example for users of the GN harvester protocol, and for anyone who made their own tooling.

Would it not be possible to adapt the classic authentication and authorization approach to the new configuration, in a way that backwards compatibility is not broken ?

Kind regards
Heikki Doeleman

Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

4

2012/11/13 Jesse Eichar <jesse.eichar@anonymised.com>

we could add a rewrite rule possibly for backwards compatibility. We
don't think it is easy to change the new login url because while it can be
a different url I don't think it can be have the srv/... portion of the
url because spring creates the service.

It looks good to me. I also noticed that the login service requires to use
POST and not GET.

Cheers.

Francois

On Tue, Nov 13, 2012 at 1:48 PM, heikki <tropicano@anonymised.com> wrote:

hello list,

I'm wondering if it was really necessary to remove the classic
xml.user.login authentication ?

This breaks backward compatibility. For example for users of the GN
harvester protocol, and for anyone who made their own tooling.

Would it not be possible to adapt the classic authentication and
authorization approach to the new configuration, in a way that backwards
compatibility is not broken ?

Kind regards
Heikki Doeleman

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork

5

GET is not a secure way to send credentials. I think it is an option but I have intentionally disabled it for better security out of the box. If one wants they can adjust the configuration for their installation.

···

On Tue, Nov 13, 2012 at 4:50 PM, Francois Prunayre <fx.prunayre@anonymised.com> wrote:

2012/11/13 Jesse Eichar <jesse.eichar@anonymised.com>

we could add a rewrite rule possibly for backwards compatibility. We don’t think it is easy to change the new login url because while it can be a different url I don’t think it can be have the srv/… portion of the url because spring creates the service.

It looks good to me. I also noticed that the login service requires to use POST and not GET.

Cheers.

Francois

Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

On Tue, Nov 13, 2012 at 1:48 PM, heikki <tropicano@anonymised.com> wrote:

hello list,

I’m wondering if it was really necessary to remove the classic xml.user.login authentication ?

This breaks backward compatibility. For example for users of the GN harvester protocol, and for anyone who made their own tooling.

Would it not be possible to adapt the classic authentication and authorization approach to the new configuration, in a way that backwards compatibility is not broken ?

Kind regards
Heikki Doeleman

Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

6

but my pointe was about backwards compatibility …

···

On Tue, Nov 13, 2012 at 4:50 PM, Francois Prunayre <fx.prunayre@anonymised.com> wrote:

2012/11/13 Jesse Eichar <jesse.eichar@anonymised.com>

we could add a rewrite rule possibly for backwards compatibility. We don’t think it is easy to change the new login url because while it can be a different url I don’t think it can be have the srv/… portion of the url because spring creates the service.

It looks good to me. I also noticed that the login service requires to use POST and not GET.

Cheers.

Francois

Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

On Tue, Nov 13, 2012 at 1:48 PM, heikki <tropicano@anonymised.com> wrote:

hello list,

I’m wondering if it was really necessary to remove the classic xml.user.login authentication ?

This breaks backward compatibility. For example for users of the GN harvester protocol, and for anyone who made their own tooling.

Would it not be possible to adapt the classic authentication and authorization approach to the new configuration, in a way that backwards compatibility is not broken ?

Kind regards
Heikki Doeleman

Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

7

So if a node wants to be backwards compatible it has to add a rewrite rule from srv/eng/xml.user.login to j_spring_security_check and support GET method. This looks to be the only changes ?

Francois

···

2012/11/13 heikki <tropicano@anonymised.com>

but my pointe was about backwards compatibility …

On Tue, Nov 13, 2012 at 5:06 PM, Jesse Eichar <jesse.eichar@anonymised.com> wrote:

GET is not a secure way to send credentials. I think it is an option but I have intentionally disabled it for better security out of the box. If one wants they can adjust the configuration for their installation.

On Tue, Nov 13, 2012 at 4:50 PM, Francois Prunayre <fx.prunayre@anonymised.com> wrote:

2012/11/13 Jesse Eichar <jesse.eichar@anonymised.com>

we could add a rewrite rule possibly for backwards compatibility. We don’t think it is easy to change the new login url because while it can be a different url I don’t think it can be have the srv/… portion of the url because spring creates the service.

It looks good to me. I also noticed that the login service requires to use POST and not GET.

Cheers.

Francois

Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

On Tue, Nov 13, 2012 at 1:48 PM, heikki <tropicano@anonymised.com> wrote:

hello list,

I’m wondering if it was really necessary to remove the classic xml.user.login authentication ?

This breaks backward compatibility. For example for users of the GN harvester protocol, and for anyone who made their own tooling.

Would it not be possible to adapt the classic authentication and authorization approach to the new configuration, in a way that backwards compatibility is not broken ?

Kind regards
Heikki Doeleman

Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

8

Hi

I think that will work only if Spring Security uses db auth (or ldap), but not for other methods like CAS or so that requires to do the login in external service? But maybe I’m wrong, not an expert about this.

Even if only works with db or ldap auth, possibly is acceptable for backwards compatibility?

Regards,
Jose García

···

2012/11/13 heikki <tropicano@anonymised.com>

but my pointe was about backwards compatibility …

On Tue, Nov 13, 2012 at 5:06 PM, Jesse Eichar <jesse.eichar@anonymised.com> wrote:

GET is not a secure way to send credentials. I think it is an option but I have intentionally disabled it for better security out of the box. If one wants they can adjust the configuration for their installation.

On Tue, Nov 13, 2012 at 4:50 PM, Francois Prunayre <fx.prunayre@anonymised.com> wrote:

2012/11/13 Jesse Eichar <jesse.eichar@anonymised.com>

we could add a rewrite rule possibly for backwards compatibility. We don’t think it is easy to change the new login url because while it can be a different url I don’t think it can be have the srv/… portion of the url because spring creates the service.

It looks good to me. I also noticed that the login service requires to use POST and not GET.

Cheers.

Francois

Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

On Tue, Nov 13, 2012 at 1:48 PM, heikki <tropicano@anonymised.com> wrote:

hello list,

I’m wondering if it was really necessary to remove the classic xml.user.login authentication ?

This breaks backward compatibility. For example for users of the GN harvester protocol, and for anyone who made their own tooling.

Would it not be possible to adapt the classic authentication and authorization approach to the new configuration, in a way that backwards compatibility is not broken ?

Kind regards
Heikki Doeleman

Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

9

I have no problem adding the rewrite rule as part of the default configuration. For cas it won’t work of course. it will give an error, but if you are doing that level of security customization then that is simply the consequence.

For GET my preference is to not have it as default, but we can vote on this of course.

Jesse

···

On Tue, Nov 13, 2012 at 5:28 PM, Jose Garcia <jose.garcia@anonymised.com> wrote:

Hi

I think that will work only if Spring Security uses db auth (or ldap), but not for other methods like CAS or so that requires to do the login in external service? But maybe I’m wrong, not an expert about this.

Even if only works with db or ldap auth, possibly is acceptable for backwards compatibility?

Regards,
Jose García

On Tue, Nov 13, 2012 at 5:22 PM, Francois Prunayre <fx.prunayre@anonymised.com.> wrote:

So if a node wants to be backwards compatible it has to add a rewrite rule from srv/eng/xml.user.login to j_spring_security_check and support GET method. This looks to be the only changes ?

Francois

Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

–

GeoCat Bridge for ArcGIS allows instant publishing of data and metadata on GeoServer and GeoNetwork. Visit http://geocat.net for details.

Jose García
GeoCat bv
Veenderweg 13
6721 WD Bennekom
The Netherlands
http://GeoCat.net

Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

2012/11/13 heikki <tropicano@anonymised.com1…>

but my pointe was about backwards compatibility …

On Tue, Nov 13, 2012 at 5:06 PM, Jesse Eichar <jesse.eichar@anonymised.com> wrote:

GET is not a secure way to send credentials. I think it is an option but I have intentionally disabled it for better security out of the box. If one wants they can adjust the configuration for their installation.

On Tue, Nov 13, 2012 at 4:50 PM, Francois Prunayre <fx.prunayre@anonymised.com> wrote:

2012/11/13 Jesse Eichar <jesse.eichar@anonymised.com>

we could add a rewrite rule possibly for backwards compatibility. We don’t think it is easy to change the new login url because while it can be a different url I don’t think it can be have the srv/… portion of the url because spring creates the service.

It looks good to me. I also noticed that the login service requires to use POST and not GET.

Cheers.

Francois

Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

On Tue, Nov 13, 2012 at 1:48 PM, heikki <tropicano@anonymised.com> wrote:

hello list,

I’m wondering if it was really necessary to remove the classic xml.user.login authentication ?

This breaks backward compatibility. For example for users of the GN harvester protocol, and for anyone who made their own tooling.

Would it not be possible to adapt the classic authentication and authorization approach to the new configuration, in a way that backwards compatibility is not broken ?

Kind regards
Heikki Doeleman

Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

10

2012/11/13 Jesse Eichar <jesse.eichar@anonymised.com>

I have no problem adding the rewrite rule as part of the default
configuration. For cas it won't work of course. it will give an error,
but if you are doing that level of security customization then that is
simply the consequence.

For GET my preference is to not have it as default, but we can vote on
this of course.

Fine for me.

Francois

Jesse

On Tue, Nov 13, 2012 at 5:28 PM, Jose Garcia <jose.garcia@anonymised.com>wrote:

Hi

I think that will work only if Spring Security uses db auth (or ldap),
but not for other methods like CAS or so that requires to do the login in
external service? But maybe I'm wrong, not an expert about this.

Even if only works with db or ldap auth, possibly is acceptable for
backwards compatibility?

Regards,
Jose García

On Tue, Nov 13, 2012 at 5:22 PM, Francois Prunayre <fx.prunayre@anonymised.com
> wrote:

So if a node wants to be backwards compatible it has to add a rewrite
rule from srv/eng/xml.user.login to j_spring_security_check and support
GET method. This looks to be the only changes ?

Francois

2012/11/13 heikki <tropicano@anonymised.com>

but my pointe was about backwards compatibility ..

On Tue, Nov 13, 2012 at 5:06 PM, Jesse Eichar <
jesse.eichar@anonymised.com> wrote:

GET is not a secure way to send credentials. I think it is an option
but I have intentionally disabled it for better security out of the box. If
one wants they can adjust the configuration for their installation.

On Tue, Nov 13, 2012 at 4:50 PM, Francois Prunayre <
fx.prunayre@anonymised.com> wrote:

2012/11/13 Jesse Eichar <jesse.eichar@anonymised.com>

we could add a rewrite rule possibly for backwards compatibility.
We don't think it is easy to change the new login url because while it can
be a different url I don't think it can be have the srv/... portion of the
url because spring creates the service.

It looks good to me. I also noticed that the login service requires
to use POST and not GET.

Cheers.

Francois

On Tue, Nov 13, 2012 at 1:48 PM, heikki <tropicano@anonymised.com> wrote:

hello list,

I'm wondering if it was really necessary to remove the classic
xml.user.login authentication ?

This breaks backward compatibility. For example for users of the GN
harvester protocol, and for anyone who made their own tooling.

Would it not be possible to adapt the classic authentication and
authorization approach to the new configuration, in a way that backwards
compatibility is not broken ?

Kind regards
Heikki Doeleman

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a
single
web console. Get in-depth insight into apps, servers, databases,
vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases,
vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork

--
*
GeoCat Bridge for ArcGIS allows instant publishing of data and metadata
on GeoServer and GeoNetwork. Visit http://geocat.net for details.
_________________________
Jose García
GeoCat bv
Veenderweg 13
6721 WD Bennekom
The Netherlands
http://GeoCat.net/&gt;

*

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork

11

I have done this. I have also made some other fixes for security. like improving login when login credentials are wrong, fixed logout when using widget ui and csw test.

···

On Wed, Nov 14, 2012 at 8:07 AM, Francois Prunayre <fx.prunayre@anonymised.com.> wrote:

2012/11/13 Jesse Eichar <jesse.eichar@anonymised.com>

I have no problem adding the rewrite rule as part of the default configuration. For cas it won’t work of course. it will give an error, but if you are doing that level of security customization then that is simply the consequence.

For GET my preference is to not have it as default, but we can vote on this of course.

Fine for me.

Francois

Jesse

On Tue, Nov 13, 2012 at 5:28 PM, Jose Garcia <jose.garcia@anonymised.com> wrote:

Hi

I think that will work only if Spring Security uses db auth (or ldap), but not for other methods like CAS or so that requires to do the login in external service? But maybe I’m wrong, not an expert about this.

Even if only works with db or ldap auth, possibly is acceptable for backwards compatibility?

Regards,
Jose García

On Tue, Nov 13, 2012 at 5:22 PM, Francois Prunayre <fx.prunayre@anonymised.com.> wrote:

So if a node wants to be backwards compatible it has to add a rewrite rule from srv/eng/xml.user.login to j_spring_security_check and support GET method. This looks to be the only changes ?

Francois

Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

–

GeoCat Bridge for ArcGIS allows instant publishing of data and metadata on GeoServer and GeoNetwork. Visit http://geocat.net for details.

Jose García
GeoCat bv
Veenderweg 13
6721 WD Bennekom
The Netherlands
http://GeoCat.net

Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

2012/11/13 heikki <tropicano@anonymised.com1…>

but my pointe was about backwards compatibility …

On Tue, Nov 13, 2012 at 5:06 PM, Jesse Eichar <jesse.eichar@anonymised.com> wrote:

GET is not a secure way to send credentials. I think it is an option but I have intentionally disabled it for better security out of the box. If one wants they can adjust the configuration for their installation.

On Tue, Nov 13, 2012 at 4:50 PM, Francois Prunayre <fx.prunayre@anonymised.com> wrote:

2012/11/13 Jesse Eichar <jesse.eichar@anonymised.com>

we could add a rewrite rule possibly for backwards compatibility. We don’t think it is easy to change the new login url because while it can be a different url I don’t think it can be have the srv/… portion of the url because spring creates the service.

It looks good to me. I also noticed that the login service requires to use POST and not GET.

Cheers.

Francois

Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

On Tue, Nov 13, 2012 at 1:48 PM, heikki <tropicano@anonymised.com> wrote:

hello list,

I’m wondering if it was really necessary to remove the classic xml.user.login authentication ?

This breaks backward compatibility. For example for users of the GN harvester protocol, and for anyone who made their own tooling.

Would it not be possible to adapt the classic authentication and authorization approach to the new configuration, in a way that backwards compatibility is not broken ?

Kind regards
Heikki Doeleman

Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork