[Geoserver-devel] Spurious http session creation, patches ready, what to do vs 2.1.0?

GeoServer GeoServer Developer
1

Hi,
following up a report of GeoServer creating thousands of http sessions
during "normal" operation I've built a tool to investigate the session
creations and a patch that solves the session creations I've noticed.

The tool is a servlet filter that wraps the HttpServletResponse and
logs the full stack trace of every call forcing the creation of a http
session. It is included in this patch:
http://jira.codehaus.org/browse/GEOS-4478

About the tool, it's quite handy in that it would allow someone else
to also do this kind of debugging, on their own servers.
I'm just undecided on how to integrate it:
a) ship it in the code, but comment out its declaration in web.xml
    Whoever needs it just had to hand modify the web.xml to activate it
b) ship it in the code and have it statically declared in the web.xml,
    and use a system variable to actually make it wrap the servlet
    request (otherwise make it a no-op)
c) ship it and have it always on, any session creation outside of
   the web UI is something we want to be informed of asap anyways

I'm tempted to go c), even when wrapping the tool is quite light
unless there is indeed a session creation going on...
how do people feel about this?
Can someone double check/review the patch at
http://jira.codehaus.org/browse/GEOS-4478

The other part of the work is the actual fix, using the tool I've found
a couple of unexpected session creations, both due to the Spring Security
integration not behaving quite like I hoped:
http://jira.codehaus.org/browse/GEOS-4477

The patch fixes the issues I've seen and should result in greater
scalability for applications that are using secured data layers and
the "www" folder.
However the testing I've made is quite on the light side (checked with some
secured layers)... we'd need someone heavily using security to confirm the
changes are not breaking anything else. Any takers?

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

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

2

On Sun, 2011-04-10 at 15:31 +0200, Andrea Aime wrote:

Hi,
following up a report of GeoServer creating thousands of http sessions
during "normal" operation I've built a tool to investigate the session
creations and a patch that solves the session creations I've noticed.

The tool is a servlet filter that wraps the HttpServletResponse and
logs the full stack trace of every call forcing the creation of a http
session. It is included in this patch:
http://jira.codehaus.org/browse/GEOS-4478

About the tool, it's quite handy in that it would allow someone else
to also do this kind of debugging, on their own servers.
I'm just undecided on how to integrate it:
a) ship it in the code, but comment out its declaration in web.xml
    Whoever needs it just had to hand modify the web.xml to activate it
b) ship it in the code and have it statically declared in the web.xml,
    and use a system variable to actually make it wrap the servlet
    request (otherwise make it a no-op)
c) ship it and have it always on, any session creation outside of
   the web UI is something we want to be informed of asap anyways

I'd go with c). It wouldn't hurt though if fillInStackTrace() is guarded
by a LOGGER.isLoggable(Level.FINE/Level.INFO) as appropriate.

I'm tempted to go c), even when wrapping the tool is quite light
unless there is indeed a session creation going on...
how do people feel about this?
Can someone double check/review the patch at
http://jira.codehaus.org/browse/GEOS-4478

The other part of the work is the actual fix, using the tool I've found
a couple of unexpected session creations, both due to the Spring Security
integration not behaving quite like I hoped:
http://jira.codehaus.org/browse/GEOS-4477

as far as I can tell we have to account for the following gwc paths:
/gwc/web/** --> same as /www
/gwc/demo --> same as as /rest
/gwc/rest/** --> same as /rest
/gwc/service/** --> same as /wms /wcs etc

I'll try to narrow the list as appropriate and post back a patch to
GEOS-4477

The patch fixes the issues I've seen and should result in greater
scalability for applications that are using secured data layers and
the "www" folder.
However the testing I've made is quite on the light side (checked with some
secured layers)... we'd need someone heavily using security to confirm the
changes are not breaking anything else. Any takers?

I'll test with GeoNode and report back, as it uses an alternate
authentication mechanism.

cheers,
Gabriel

Cheers
Andrea

--
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers

3

On Sun, Apr 10, 2011 at 7:31 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
following up a report of GeoServer creating thousands of http sessions
during “normal” operation I’ve built a tool to investigate the session
creations and a patch that solves the session creations I’ve noticed.

The tool is a servlet filter that wraps the HttpServletResponse and
logs the full stack trace of every call forcing the creation of a http
session. It is included in this patch:
http://jira.codehaus.org/browse/GEOS-4478

About the tool, it’s quite handy in that it would allow someone else
to also do this kind of debugging, on their own servers.
I’m just undecided on how to integrate it:
a) ship it in the code, but comment out its declaration in web.xml
Whoever needs it just had to hand modify the web.xml to activate it
b) ship it in the code and have it statically declared in the web.xml,
and use a system variable to actually make it wrap the servlet
request (otherwise make it a no-op)
c) ship it and have it always on, any session creation outside of
the web UI is something we want to be informed of asap anyways

Seems pretty useful. I don’t have a strong opinion about how to integrate it. (c) seems good but I wonder if the start of a new session should be logged as INFO in the web case? Perhaps FINE seems more appropriate for that case since it is a normal occurrence? Logging at INFO for the non web ui case seems well warranted though.

I’m tempted to go c), even when wrapping the tool is quite light
unless there is indeed a session creation going on…
how do people feel about this?
Can someone double check/review the patch at
http://jira.codehaus.org/browse/GEOS-4478

The other part of the work is the actual fix, using the tool I’ve found
a couple of unexpected session creations, both due to the Spring Security
integration not behaving quite like I hoped:
http://jira.codehaus.org/browse/GEOS-4477

Recently some of our client side folks have been working on authentication from javascript apps using some of the current geoserver auth logic… not sure if this patch affects that at all. I will work with Tim to try and test this out to see if the patch changes anything.

The patch fixes the issues I’ve seen and should result in greater
scalability for applications that are using secured data layers and
the “www” folder.
However the testing I’ve made is quite on the light side (checked with some
secured layers)… we’d need someone heavily using security to confirm the
changes are not breaking anything else. Any takers?

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

Xperia™ PLAY
It’s a major breakthrough. An authentic gaming
smartphone on the nation’s most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev

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.

4

On Sun, Apr 10, 2011 at 7:25 PM, Gabriel Roldán <groldan@anonymised.com> wrote:

c) ship it and have it always on, any session creation outside of
the web UI is something we want to be informed of asap anyways

I'd go with c). It wouldn't hurt though if fillInStackTrace() is guarded
by a LOGGER.isLoggable(Level.FINE/Level.INFO) as appropriate.

Yep, very much agree.

I'm tempted to go c), even when wrapping the tool is quite light
unless there is indeed a session creation going on...
how do people feel about this?
Can someone double check/review the patch at
http://jira.codehaus.org/browse/GEOS-4478

The other part of the work is the actual fix, using the tool I've found
a couple of unexpected session creations, both due to the Spring Security
integration not behaving quite like I hoped:
http://jira.codehaus.org/browse/GEOS-4477

as far as I can tell we have to account for the following gwc paths:
/gwc/web/** --> same as /www
/gwc/service/** --> same as /wms /wcs etc

which means, for both, same as the new /** rule (which covers everything
but web ui and rest)

/gwc/demo --> same as as /rest
/gwc/rest/** --> same as /rest

Humm... ha. I guess demo was not in the list of rest-y paths

I'll try to narrow the list as appropriate and post back a patch to
GEOS-4477

Thanks!

The patch fixes the issues I've seen and should result in greater
scalability for applications that are using secured data layers and
the "www" folder.
However the testing I've made is quite on the light side (checked with some
secured layers)... we'd need someone heavily using security to confirm the
changes are not breaking anything else. Any takers?

I'll test with GeoNode and report back, as it uses an alternate
authentication mechanism.

Yep, that would be good, again, thanks :slight_smile:

Cheers

--
-------------------------------------------------------
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

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

5

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.

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?

cheers,
Gabriel

On Sun, 2011-04-10 at 21:39 +0200, Andrea Aime wrote:

On Sun, Apr 10, 2011 at 7:25 PM, Gabriel Roldán <groldan@anonymised.com> wrote:
>> c) ship it and have it always on, any session creation outside of
>> the web UI is something we want to be informed of asap anyways
> I'd go with c). It wouldn't hurt though if fillInStackTrace() is guarded
> by a LOGGER.isLoggable(Level.FINE/Level.INFO) as appropriate.

Yep, very much agree.

>> I'm tempted to go c), even when wrapping the tool is quite light
>> unless there is indeed a session creation going on...
>> how do people feel about this?
>> Can someone double check/review the patch at
>> http://jira.codehaus.org/browse/GEOS-4478
>>
>> The other part of the work is the actual fix, using the tool I've found
>> a couple of unexpected session creations, both due to the Spring Security
>> integration not behaving quite like I hoped:
>> http://jira.codehaus.org/browse/GEOS-4477
> as far as I can tell we have to account for the following gwc paths:
> /gwc/web/** --> same as /www
> /gwc/service/** --> same as /wms /wcs etc

which means, for both, same as the new /** rule (which covers everything
but web ui and rest)

> /gwc/demo --> same as as /rest
> /gwc/rest/** --> same as /rest

Humm... ha. I guess demo was not in the list of rest-y paths

> I'll try to narrow the list as appropriate and post back a patch to
> GEOS-4477

Thanks!

>>
>> The patch fixes the issues I've seen and should result in greater
>> scalability for applications that are using secured data layers and
>> the "www" folder.
>> However the testing I've made is quite on the light side (checked with some
>> secured layers)... we'd need someone heavily using security to confirm the
>> changes are not breaking anything else. Any takers?
> I'll test with GeoNode and report back, as it uses an alternate
> authentication mechanism.

Yep, that would be good, again, thanks :slight_smile:

Cheers

--
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers

6

On Sun, Apr 10, 2011 at 10:07 PM, Gabriel Roldán <groldan@anonymised.com> 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)

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

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

7

On Sun, Apr 10, 2011 at 9:39 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

On Sun, Apr 10, 2011 at 7:25 PM, Gabriel Roldán <groldan@anonymised.com> wrote:

c) ship it and have it always on, any session creation outside of
the web UI is something we want to be informed of asap anyways

I'd go with c). It wouldn't hurt though if fillInStackTrace() is guarded
by a LOGGER.isLoggable(Level.FINE/Level.INFO) as appropriate.

Yep, very much agree.

Filter committed.
I'll wait for some feedback before committing also the Spring Security
changes

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

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

8

On Mon, 2011-04-11 at 16:30 +0200, Andrea Aime wrote:

On Sun, Apr 10, 2011 at 10:07 PM, Gabriel Roldán <groldan@anonymised.com> 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&gt;

Gabriel

Cheers
Andrea

--
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers

9

On Mon, Apr 11, 2011 at 8:58 PM, Gabriel Roldán <groldan@anonymised.com> 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 <groldan@anonymised.com> 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&gt;

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

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

10

On Mon, 2011-04-11 at 21:23 +0200, Andrea Aime wrote:

On Mon, Apr 11, 2011 at 8:58 PM, Gabriel Roldán <groldan@anonymised.com> 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 <groldan@anonymised.com> 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&gt;

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.

I think I could give it a try on the following days but for the reasons
you mention would try to avoid junit4. Although I'd like to move to
juni4 that's a totally different issue that I agree is not to take
lightly with the amount of junit3 dependent infrastructure we have in
place.
But perhaps there's a junit3 friendly way of letting spring pick up a
test-only app context xml document. The point being the doc shall be
named differently for it not being picked up when running from eclipse
for example.

cheers,

Gabriel

Cheers
Andrea

--
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers

11

After testing the patch, I added my comments from a client perspective to the ticket.

http://jira.codehaus.org/browse/GEOS-4477

Exec summary: only folks who were relying on the cookie from unauthenticated requests should be affected.

Tim

On 4/10/11 1:33 PM, Justin Deoliveira wrote:

On Sun, Apr 10, 2011 at 7:31 AM, Andrea Aime
<andrea.aime@anonymised.com <mailto:andrea.aime@anonymised.com>> wrote:

    Hi,
    following up a report of GeoServer creating thousands of http sessions
    during "normal" operation I've built a tool to investigate the session
    creations and a patch that solves the session creations I've noticed.

    The tool is a servlet filter that wraps the HttpServletResponse and
    logs the full stack trace of every call forcing the creation of a http
    session. It is included in this patch:
    http://jira.codehaus.org/browse/GEOS-4478

    About the tool, it's quite handy in that it would allow someone else
    to also do this kind of debugging, on their own servers.
    I'm just undecided on how to integrate it:
    a) ship it in the code, but comment out its declaration in web.xml
        Whoever needs it just had to hand modify the web.xml to activate it
    b) ship it in the code and have it statically declared in the web.xml,
        and use a system variable to actually make it wrap the servlet
        request (otherwise make it a no-op)
    c) ship it and have it always on, any session creation outside of
       the web UI is something we want to be informed of asap anyways

Seems pretty useful. I don't have a strong opinion about how to
integrate it. (c) seems good but I wonder if the start of a new session
should be logged as INFO in the web case? Perhaps FINE seems more
appropriate for that case since it is a normal occurrence? Logging at
INFO for the non web ui case seems well warranted though.

    I'm tempted to go c), even when wrapping the tool is quite light
    unless there is indeed a session creation going on...
    how do people feel about this?
    Can someone double check/review the patch at
    http://jira.codehaus.org/browse/GEOS-4478

    The other part of the work is the actual fix, using the tool I've found
    a couple of unexpected session creations, both due to the Spring
    Security
    integration not behaving quite like I hoped:
    http://jira.codehaus.org/browse/GEOS-4477

Recently some of our client side folks have been working on
authentication from javascript apps using some of the current geoserver
auth logic... not sure if this patch affects that at all. I will work
with Tim to try and test this out to see if the patch changes anything.

    The patch fixes the issues I've seen and should result in greater
    scalability for applications that are using secured data layers and
    the "www" folder.
    However the testing I've made is quite on the light side (checked
    with some
    secured layers)... we'd need someone heavily using security to
    confirm the
    changes are not breaking anything else. Any takers?

    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

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

    ------------------------------------------------------------------------------
    Xperia(TM) PLAY
    It's a major breakthrough. An authentic gaming
    smartphone on the nation's most reliable network.
    And it wants your games.
    http://p.sf.net/sfu/verizon-sfdev
    _______________________________________________
    Geoserver-devel mailing list
    Geoserver-devel@lists.sourceforge.net
    <mailto: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.

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.

12

On Mon, Apr 11, 2011 at 10:46 PM, Tim Schaub <tschaub@anonymised.com> wrote:

After testing the patch, I added my comments from a client perspective
to the ticket.

http://jira.codehaus.org/browse/GEOS-4477

Exec summary: only folks who were relying on the cookie from
unauthenticated requests should be affected.

Pity. The client was certainly used some undocumented (and unintended)
behavior, I'm wondering how many people noticed that loophole and are
going to be affected.

As far as I understand from your comments there are workarounds that use
the form based authentication, right?
That is not really a supported path either, but at least it's one that
is supposed
to create a session, while restful services should be stateless.

Other options?

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

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

13

ok, I gave it a try at moving applicationSecurityContext.xml to web-app
and it works.
Here's the diff:
<https://github.com/groldan/geoserver_trunk/compare/master...security_breakdown&gt;

The goal is to have the security subsystem being laid out by the web app
and not main, allowing the set up of alternate web applications that
relies on certain geoserver components and can override the security
subsystem as a whole. Which is what GeoNode needs to do.

Please take a look at that branch at your earliest convenience and let
me know if it seems reasonable to apply on trunk. And I'd like to apply
to 2.1.x after 2.1.0 is out too.

For the sake of simplicity, I left a single
applicationSecurityContextTest.xml in main/src/test/java instead of
having to create separate ones for each test that relies on the security
features.

Cheers,
Gabriel

On Mon, 2011-04-11 at 16:57 -0300, Gabriel Roldán wrote:

On Mon, 2011-04-11 at 21:23 +0200, Andrea Aime wrote:
> On Mon, Apr 11, 2011 at 8:58 PM, Gabriel Roldán <groldan@anonymised.com> 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 <groldan@anonymised.com> 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&gt;
>
> 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.
I think I could give it a try on the following days but for the reasons
you mention would try to avoid junit4. Although I'd like to move to
juni4 that's a totally different issue that I agree is not to take
lightly with the amount of junit3 dependent infrastructure we have in
place.
But perhaps there's a junit3 friendly way of letting spring pick up a
test-only app context xml document. The point being the doc shall be
named differently for it not being picked up when running from eclipse
for example.

cheers,

Gabriel
>
> Cheers
> Andrea
>

--
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers