On Mon, Apr 11, 2011 at 8:58 PM, Gabriel Roldán <[email protected]> wrote:
> On Mon, 2011-04-11 at 16:30 +0200, Andrea Aime wrote:
>> On Sun, Apr 10, 2011 at 10:07 PM, Gabriel Roldán <[email protected]> wrote:
>> > You may be able to bring some light over the following:
>> > While testing this I found it seems impossible to get really rid of the
>> > default geoserver security filter chain in order to provide an alternate
>> > auth system.
>> > Or at least that's what it looks like to me.
>> > Reason being org.geoserver.filters.SpringDelegatingFilter applying all
>> > the filters found in the app context, so no matter geonode declares a
>> > different set, geoservers' default win. Specially the
>> > GeoSeverAuthenticationProcessingFilter gets duplicated, geoserver's
>> > relying on the default daoAuthenticationManager, geonode's in it's own
>> > one, that gets never called.
>>
>> Bug reported already:
>> http://jira.codehaus.org/browse/GEOS-4421
>>
>> > Which in turn brings me to the following reasoning:
>> > having applicationSecurityContext in the main module is wrong.
>> > appSecurityContext.xml belongs to web-app, _and_ web-app should be no
>> > more than the glue that sets up the app. Otherwise /main is assuming a
>> > lot of things that may not hold true on a different set up or directly
>> > don't belong to it. The security set up is a cross cutting concern
>> > that's better addressed where the app is laid out.
>> > This is the same I had to do with geowebcache, moving appSecurityContext
>> > to its web module, so that geoserver can depend on gwc without carrying
>> > over its assumptions.
>> > But in this case it's geonode depending on geoserver. And the right
>> > thing to do IMHO would be that geonode doesn't depend on geosever's
>> > web-app, but lays out its own war as it needs it.
>> >
>> > Now, for this to work we should move everything in web/app/src/main/java
>> > to web-core, but let web-app just decide on the bean weaving.
>> >
>> > makes sense, or am I missing something obvious?
>>
>> It was there in the beginning, but I could not perform quite a bit of
>> testing that was to be done in the main module, so it was moved back
>> to main so that cobertura could reliably report on test coverage.
>>
>> We could move the stuff back in web/app and the tests too.
>> At the time it was important I could prove some test coverage, making
>> the move would make it impossible to prove certain classes are
>> tested at all (don't remember which ones, that happened two years
>> ago)
> wouldn't it be possible to move the real appSecurityContext to web-app
> and have one in main/src/test/resources for main's testing purposes?
> I guess it would if we used JUnit4's
> @RunWith(SpringJUnit4ClassRunner.class):
> <http://static.springsource.org/spring/docs/2.5.x/reference/testing.html>

Maybe? Don't have time to do this right one, want to take it up?

Btw, upgrading to junit 4 should be a matter of discussion, in GeoTools
we have it and it's quite messy to have tests setup in both ways, Eclipse
gets confused and one has to modify the test runner in order to run
just one test.

Cheers
Andrea

-- 
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:      +39 0584 962313
mob:    +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

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

------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to