Problem 1), the cookie is not used after GetCapabiliteis
Let us examine your cookie attributes. What are the values of
Secure
Domain
Path
HTTPOnly
Expires
Especially the value of HTTPOnly is interesting. If true, the cookie is not
visible to scripts. (I assume your client uses Java Script).
Normally, the browser takes care of sending the cookie for each request.
The attribute SPRING_SECURITY_CONTEXT holds the security token, this is
correct.
Problem 2) wicket session.
This is a new aspect, perhaps I have to create the session compatible to
the admin interface.
Problem 3) Not using a session. This is the default for stateless services.
An example for openlayers is here
http://osgeo-org.1560.x6.nabble.com/Load-GeoServer-WMS-secured-layers-with-OpenLayers-td3919938.html
Christian
2013/6/24 Thomas Colley <it...@neath-porttalbot.gov.uk>
> 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$SessionBindingListener@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:christian.muel...@os-solutions.at]
> *Sent:* 17 June 2013 11:18
> *To:* Thomas Colley
> *Cc:* geoserver-users@lists.sourceforge.net
> *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 <it...@neath-porttalbot.gov.uk>****
>
> 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:christian.muel...@os-solutions.at]
> *Sent:* 15 June 2013 15:38
> *To:* Thomas Colley
> *Cc:* geoserver-users@lists.sourceforge.net****
>
>
> *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****
>
> ** **
>
--
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
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
