Robert Tansley ha scritto: > On 01/09/07, Mark Diggory <[EMAIL PROTECTED]> wrote: > >> Restricting access to Communites, Collection or Items directly is >> certainly not what DSpace was designed to do. >> > > The real issue is more that the DSpace authz model has no notion of > 'know of an object's existence' as an action. One of the 'finish 1.0 > in a finite amount of time' tradeoffs was not to implement this (for > precisely the reasons that Andrea mentioned -- the complexity and > expense of evaluating visibility in operations like search, browse and > harvest.) > Hi Rob, I'm not sure that splitting the current READ permission in a more granular way could be the rigth solution... Could we have an EXISTENCE permission on an object without READ permission? Could we have a READ permission on an object without EXISTENCE? I think that the answer is NO for both the questions. IMHO the current permissions are sufficient enough. There is only one problem about bitstreams READ definition. In fact, while for communities, collections, item and bundle READ means the possibility of metadata access (therefore knowing about the object existence), the READ permission for bitstream allows both medatata (name, size, format, etc.) and content access (InputStream). Therefore I think that it would be good to make this behaviour uniform also hooking-up the READ permission to the InputStream, and this would also make sense for WRITE permission.
> >From a design standpoint, I think authz needs an overhaul as I've > mentioned many times before; I think introducing the notion of 'know > of an objects existence' distinct from the existing READ is the right > way to go about this rather than overloading READ. > > It makes sense to me to have queries evaluated using a particular > Context could we use different indexes? Every EPerson could have a set of lucene indexes, which would contain only the objects that he can see... In this scenario we need to keep 1 index for any group or eperson that have READ policies Andrea > (be they search etc) only return objects that the > currently-authenticated e-person can 'see'. The system has not > evolved in a way amenable to this, however. Post-query filtering > doesn't work because if you ask for 'the first 10 items with titles > starting with C', you may end up with only 6 visible results. For a > more general solution, either every indexing system needs to be > ACL-aware (yuck), or we should create a unified query API whose > implementation is ACL-aware, i.e. indexes relevant permissions. > Lucene seems the most likely candidate for such an API. Unfortunately > things seem to be diversifying rather than unifying in this area. > > Rob > > ------------------------------------------------------------------------- > 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
