Hi all, in investigating bringing GeoNode in line with the new security system I’ve run into an odd issue. Until recently (r16964) GeoServer only used named configurations from the data directory to load filters configured in the new security system. This revision introduced a fallback - beans from the Spring context can also be loaded. The commit message for this revision was:
GEOS-5065, factoring out filter chain configuration for cas into cas auth provider
Which doesn’t seem to imply anything about changing the lookup mechanism. Is this change intentional? More importantly, can I rely on this behavior in GeoNode?
–
David Winslow
OpenGeo - http://opengeo.org/
Hey David,
Short answer, yes, you can rely on it.
Long answer, the support for spring bean lookup was to support authentication mechanisms that need a filter that the user will/should not explicitly have to configure. Which was the case for CAS. The cas filter always is there (loaded by name from the spring context) but if the user wants CAS they go and manually create the authentication provider, which relies on the filter.
Make sense?
On Wed, May 9, 2012 at 2:54 PM, David Winslow <dwinslow@anonymised.com> wrote:
Hi all, in investigating bringing GeoNode in line with the new security system I’ve run into an odd issue. Until recently (r16964) GeoServer only used named configurations from the data directory to load filters configured in the new security system. This revision introduced a fallback - beans from the Spring context can also be loaded. The commit message for this revision was:
GEOS-5065, factoring out filter chain configuration for cas into cas auth provider
Which doesn’t seem to imply anything about changing the lookup mechanism. Is this change intentional? More importantly, can I rely on this behavior in GeoNode?
–
David Winslow
OpenGeo - http://opengeo.org/
Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Yes, it makes sense. Thanks Justin.
–
David Winslow
OpenGeo - http://opengeo.org/
On Wed, May 9, 2012 at 5:01 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Hey David,
Short answer, yes, you can rely on it.
Long answer, the support for spring bean lookup was to support authentication mechanisms that need a filter that the user will/should not explicitly have to configure. Which was the case for CAS. The cas filter always is there (loaded by name from the spring context) but if the user wants CAS they go and manually create the authentication provider, which relies on the filter.
Make sense?
On Wed, May 9, 2012 at 2:54 PM, David Winslow <dwinslow@anonymised.com.1501…> wrote:
Hi all, in investigating bringing GeoNode in line with the new security system I’ve run into an odd issue. Until recently (r16964) GeoServer only used named configurations from the data directory to load filters configured in the new security system. This revision introduced a fallback - beans from the Spring context can also be loaded. The commit message for this revision was:
GEOS-5065, factoring out filter chain configuration for cas into cas auth provider
Which doesn’t seem to imply anything about changing the lookup mechanism. Is this change intentional? More importantly, can I rely on this behavior in GeoNode?
–
David Winslow
OpenGeo - http://opengeo.org/
Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.