Hi Mark et all, > Restricting access to Communites, Collection or Items directly is > certainly not what DSpace was designed to do. you are right, but the question now is should DSpace support this type of needs? well, I (and you seeing last line of your response) think that it should. > > This is really one of the real "pain points" of DSpace IMO. There are > just so many places where the assumption that a container > (Community/Collection/Item) will be unrestricted. To correctly fix the > issue requires access control to be taken into consideration "in" the > DSpace Model in methods such as DSpaceObecjt.findAll and that services > that need to access those methods (JSPUI/OAI/XMLUI/CLI) such that they > only return the children that the context is authorized to see, this > means that every child needs to be evaluated before being returned in > the List, Array or Iterator that comes back from these methods. evaluate any elements at any time is simply to heavy... at the moment dspace model & ACL code are already too related, I'm looking at a solution where model is clean (i.e. don't need to know ACL). You, Graham or some others, I don't remember, have already talk about "different context" for DB, Authorization and so. I'm think that we could have a "simple" context and an "authorized context" that wrap it. Authorized context could intercept (this is where I see an use of AOP in dspace) call to methods that require authorization check and add it to them. (I think that this should result in only 1 + 1 queries) > The Harvest class (I.E. OAI Harvest) would need to have its own logic > cleaned up (because if I remember correctly) it directly queries the > database and uses its own instantiation to return objects. harvest use findAll() for retrieval of sets and owner query for item
> Conversely, as Andrea states, Search and Browse would need to be > extended to support indexing Access control details and to manage > limiting search across those spaces. this could to be more complex, because we use lucene and not db query for search so I don't see a way to count hits without evaluate any elements of results but I need to look at lucene API more closely > > I thought about this a bit and considered exploring such work, we just > keep stepping back and asking "why are we attempting to restrict > access to a Community/Collection/Item?" and redoing our requirements > to eliminate the need. For instance: > > 1.) Don't use "Communities/Collections" to Identify only the items you > want to expose of OAI harvesting, maybe instead use an external OAI > Server and only add the items you want to that Gateway and not use the > internal dspace-oai implementation. > > 2.) Use another installation of DSpace restricted exclusively to that > user group for those wishing to have controlled access to > Communities/Collections/Items. > this is the right approach in a simple scenario where all restrictions are required from only one group of users. More times there are many different groups that need to restrict they work from any other. In this scenario we need more and more (little) dspace instances and this in not convenient Andrea > My warning is that you've really reached a "boundary" in the > capability/design of DSpace and rather falling off into a bottomless > pit of customizations that you have maintain, instead reuse instances > of dspace and OAI services with a little configuration/automation > between them to achieve the same goal. > > I think its clear that with such an architectural issues being exposed > as limitations, we should certainly consider putting it into the > design requirements for DSpace 2.0 > > Cheers, > Mark > > On Sep 1, 2007, at 9:38 AM, Andrea Bollini wrote: > >> mmm... I'm really wrong >> I'm sorry but I should read more closely your wiki page ;-) >> You have modified some part of retrieval API so your patch is not only >> for JSPUI, as you have noted it doesn't works on oai-pmh because there >> are others methods (as findAll() used by oai-pmh) for retrieval >> collection & communities. >> Note that if you hide some collections in findAll() you can have problem >> in oai-pmh response because your record could have a reference to a set >> (=collection) not displayed in ListSets (it use findAll). >> If you hide collection in Item.getCollection() this will result in >> strange behavior when you display item mapped from an hidden collection >> to a not hidden collection... (so the problem has not a really simple >> solution "community wide"). >> >> Finally, you have missed another end-user point where he can see your >> hidden collection&communities: advanced-search, try a first search with >> no result or wrong input and in the dropdown menu its appears >> best, >> Andrea >> >> Andrea Bollini ha scritto: >>> Hi Lucas, >>> thanks for you clear wiki page, it should be useful for someone others. >>> Please note that your "patch" is *only* on user interface (JSPUI) so >>> the >>> communities and the collections that you hide are visible on oai-phm >>> response (if you think you can add this info in "Things to do"). >>> A more complete solution needs to alter the retrieval API >>> (getCollections(), getItems(), getCommunities and so...) I'm currently >>> exploring this scenario. >>> Best, >>> Andrea >>> >>> Schaik, L.B. van ha scritto: >>> >>>> Hi, >>>> >>>> At Leiden University, The Netherlands, we wanted to hide some >>>> collections and communities from the Communities and Collections page. >>>> This is because we have a special community for all our harvest >>>> collections (that include a subset of items from our normal >>>> collections), but we did not want to show them to the "normal" user. >>>> Also, we have a community for a special group within our >>>> University, and >>>> we wanted to be able to show this community only to people working at >>>> this special group. >>>> >>>> Well, we modified Dspace in such a way that we leverage to power of >>>> resource policies to determine if a community/collection needs to >>>> display on the Communities and Collections page. >>>> >>>> How we did that and how you can implement this too, is explained on >>>> the >>>> following wiki page: >>>> http://wiki.dspace.org/index.php/Hide_Community_or_Collection_from_list >>>> >>>> >>>> >>>> Hope this is useful to someone. If you have questions, please let me >>>> know. >>>> >>>> regards, >>>> >>>> Lucas van Schaik >>>> Developer >>>> >>>> Leiden University Library >>>> Witte Singel 27, Postbus 9501, 2300 RA Leiden >>>> Tel. +31 71 - 527 28 87 >>>> E-mail: [EMAIL PROTECTED] >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> ------------------------------------------------------------------------- >>>> >>>> This SF.net email is sponsored by: Splunk Inc. >>>> Still grepping through log files to find problems? Stop. >>>> Now Search log events and configuration files using AJAX and a >>>> browser. >>>> Download your FREE copy of Splunk now >> http://get.splunk.com/ >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> Dspace-devel mailing list >>>> [EMAIL PROTECTED] >>>> https://lists.sourceforge.net/lists/listinfo/dspace-devel >>>> >>>> >>> >>> >>> >> >> >> -- >> Dott. Andrea Bollini >> Responsabile tecnico sviluppo e formazione applicativi JAVA >> Sezione Servizi per le Biblioteche e l'Editoria Elettronica >> CILEA, http://www.cilea.it >> tel. +39 06-59292831 cel. +39 348-8277525 >> >> >> ------------------------------------------------------------------------- >> >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> _______________________________________________ >> DSpace-tech mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/dspace-tech > > ~~~~~~~~~~~~~ > Mark R. Diggory - DSpace Systems Manager > MIT Libraries, Systems and Technology Services > Massachusetts Institute of Technology > > > > -- Dott. Andrea Bollini Responsabile tecnico sviluppo e formazione applicativi JAVA Sezione Servizi per le Biblioteche e l'Editoria Elettronica CILEA, http://www.cilea.it tel. +39 06-59292831 cel. +39 348-8277525 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
