Hi Christian
Thanks very much for the work you've done fixing this issue. I can
confirm that using the new nightly build sessions are now being created.
That said requests sent after the authenticating GetCapabilities request
still do not seem to be using the session. I still get the same pink
tiles or authentication prompt when adding a restricted layer.
Looking at the sessions in Tomcat, the session created from the ows
request has 1 attribute called SPRING_SECURITY_CONTEXT but the session
created from logging in to the admin page has additional attributes
called:
wicket:wicket:session -
org.geoserver.web.spring.security.GeoServerSession@6bea4bbf
wicket:wicket:m:null - [PageMap name=null]
Wicket:SessionUnbindingListener-wicket -
org.apache.wicket.protocol.http.AbstractHttpSessionStore$SessionBindingL
istener@63131ff2
I have noticed that deleting the wicket:session attribute breaks the
functionality of restricted layers on the map when logged in to the
admin console. Sorry if this is completely irrelevant as I don't really
understand what I am talking about.
On a separate note, am I using sessions in the wrong way here? Is it
better to not create sessions at all and just attach the header to every
request? I have tried to think of a way to do this painlessly but
cannot.
Thanks again
Tom
From: Christian Mueller [mailto:[email protected]]
Sent: 17 June 2013 11:18
To: Thomas Colley
Cc: [email protected]
Subject: Re: [Geoserver-users] Geoserver Header Auth
Hi Thomas
Long story for short, you detected a bug. Can you open a JIRA issue and
copy/paste your description (step 1 - 4).
There should be an HTTP session but there is none. I looked a the code
and can confirm your observations.
I will fix this ASAP.
2013/6/17 Thomas Colley <[email protected]>
Thanks for your reply Christian.
1) The pink tiles are due to Geoserver returning a "could not find
layer" message as Catalog Mode under Data Security was set to HIDE. If I
change Catalog Mode to CHALLENGE instead of pink tiles I get the 401
challenge prompt.
2) That makes sense, I was on completely the wrong track with
Remember Me, it was just a guess.
3) Removing the anonymous filter would not be ideal as the way I
was hoping it would work is users with access to restricted layers would
authenticate via proxy and everyone else would fallback to anonymous
access (anonymous has always been below proxy in the chain). However I
have tried removing anonymous from the filter chain and it doesn't fix
the problem.
The problem seems to be that although I have HTTP session creation
allowed on the default chain the getcapabilities request containing the
header is not creating a session. I can see this by monitoring the
Tomcat manager. If I log in to the Geoserver admin interface a session
is created and while still logged in the mapping application works fine.
As soon as I log out of admin page the restricted map layers break.
Here is the exact process:
1) Openlayers page loads and submits a getcapabilities request with
HTTP header added.
2) WMS layer tree is displayed showing the correct restricted
layers (data is restricted at a workspace level in Geoserver) so
authentication has definitely been successful at this point.
3) Checking Tomcat manager no session has been created
4) Trying to load a restricted layer from this list results in
either "can't find layer" error (pink tiles) or 401 prompt depending on
Geoserver setting.
So it appears that for some reason even though I am sending a request
with header that is getting successfully authenticated (step 2) a
session is not being created.
Thanks again for your help
Tom
From: Christian Mueller [mailto:[email protected]]
Sent: 15 June 2013 15:38
To: Thomas Colley
Cc: [email protected]
Subject: Re: [Geoserver-users] Geoserver Header Auth
Hi Thomas
About your questions
1) Adding a layer and getting pink tiles
No idea here, adding a layer has nothing to do with authentication,
could you reproduce this problem using the default security
configuration ?
2) The remember me service works only with http basic auth and form
based login. Why ?. The remeber me services uses a cookie and stores a
digested representation of the password as cookie value (along with the
user id) . Header authentication uses no password --> no remember me
service.
3) Your filter chain
You have a proxy and the anonymous filter. The last filter in the chain
determines the authentication entry point (e.g. redirecting the browser
to a login form). The anonymous filter has no authentication entry
point because it always logs you in as "anonymous" successfully. If you
use an anonymous filter, the filter has to be the last filter in the
chain. A filter behind the anonymous filter will never be used.
You have HTTP session creation enabled. I assume you send the http
header once and use the session cookie for subsequent requests. This may
be problematic in case of a session time out because you are logged in
again as anonymous "automatically". Remove the anonymous filter if this
is possible in your scenario. Upon session time out, you must log in
again.
If you cannot remove the anonymous filter, you have to send the http
header attribute in each request which requires authentication, there is
no other solution. In this scenario, you can disable session creation.
Hope this helps
Christian
--
DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
