Hi, so we gathered some feedback on how the per layer security was implemented and some changes are needed. They do not change the contents of the proposal, but the way it is implemented, in particular, the proposal was not complete on
The current approach (let's call it HIDE) assumes the user authenticated himself before doing any business with the server, and the server in turn lets her see only the layers that she's authorized to see, and pretends layers that she can only access read only to really be read only. That is, capabilities don't list the layers that you can't access to, direct access returns a service exception stating the layer is not there, direct write on a layer where you have no write access states the layer is not writable. No where the server says you should authenticate of change your authentication to perform the operation that failed. This works fine from a security point of view, you cannot even infer the layers are there, but has quite some issues with standard clients such as uDig, or Google Earth, since they do not allow you to authenticate preventively and assess your authentication went fine. They are made to react to a 401, only then they will present an authentication dialog. So for those clients a different approach is needed, one where the capabilities do contain all the layers, and where you get a 401 when you try to use a layer you don't have clearance for. Let's call this approach CHALLENGE. Unfortunately none of the above suits the needs of the organisation sponsoring the "per layer security" work. They need a half in between, which I'll call MIXED, in which the capabilities do contain only what you're supposed to see with the current authentication (if any), but direct access to a layer (one that was not in the capabilities) triggers a 401 and makes the client (in their case, OL or Google Eearth) ask for an authentication. In this case they don't want the world to see the list of layers actually available, but they do want people with direct link be able to use them from GE in a way that makes GE trigger an authentication request. So it seems that for various reasons I'll have to implement all three behaviour. HIDE is already there, CHALLENGE is needed for capabilities driven clients to work, MIXED is what the sponsoring organisation needs. Of course the code to handle the three options is becoming quite a bit hairy but... I'm not seeing any escape route. I'm going to commit the changes as soon as I'm done for you to look at, and I'm open to suggestions and of course reviews. Cheers Andrea ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
