On Wed, Feb 29, 2012 at 8:49 PM, Justin Deoliveira <[email protected]> wrote: > Hi all, > > I have been working through the feedback gathered for GSIP 73. > > > http://geoserver.org/display/GEOS/GSIP+73+-+Workspace+Local+Styles+and+Layer+Groups > > From the email exchange earlier this week this the major feedback I mined > out of it: > > 1. rest api needs to be updated > 2. better ui for local workspace stuff, ideally a single global workspace > drop down > 3. more care taken when updating the ResourceAccessManager interface > 4. ResourceAccessManager might not be the best place for simply filtering > styles and layer groups > > (1) has been completed. Will update patch shortly.
Nice > (2) I would like to push off as a future improvement. I thought about it and > I think it represents quite a bit of work, but i do agree it would be a much > better workflow. I can go for that. Do you mind if we start a parallel, background discussion on how to best implement that? It may turn out we find a simpler way to do that, or it could become something we implement in a code sprint. > (3) Added an abstract base class for the ResourceAccessManager that > extensions can extend from, protecting them from future api changes Nice > (4) This one i am torn on and allow me to explain. I agree that the > ResourceAccessManager should really be used strictly for security, but on > the other hand we currently do use it for filtering components of the > catalog. And the CatalogFilter interface already supports some catalog > components so why not others. CatalogFilter is a nice general concept, however it is not necessarily connected to security. > As previously mentioned for this proposal I had to add a second catalog > wrapper called LocalWorkspaceCatalog, to do some special handling around > local workspace stuff. I could move all the local workspace filtering stuff > there and away from the CatalogFilter interface. But then we would be > duplicating a lot of the stuff done in SecureCatalog to do filtering of the > various catalog contents. This is actually more inline with how the local > workspace stuff was originally implemented but then it was decided that > using the CatalogFilter interface would be a good idea for that. > > To decide which way to go I would like to ask a secondary question. Does > having access limits for styles and layer groups make sense, in any context, > not just a workspace local context? If it doesn't then i can remove those > interface and move everything over to the LocalWorkspaceCatalog wrapper. I can see that as a security concern, yep. For example, some heavy styles might be available only to certain users for performance reasons, or some styles might show information that the general public should not see, or finally some styles could be using attributes that are not allowed for everybody to access. > However if those interfaces do make sense then the fact that we use them for > this filtering is really just an implementation detail, and we could > potentally leave things as is now and move them over at a later time. I'm ok with the changes, what I was trying to point out is that any change to the ResourceAccessManager must be thought through also from the point of view of security, since that's its primary purpose. 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 339 8844549 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 ------------------------------------------------------- ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
