Andrea,

I would recommend this is another patch outside the scope of the  
delegate admins patch. As the two are functionally different  
issues.   I agree that its a problem, but the majority of the usage  
is in static main methods, I think that was its initial impetus. I'd  
like to see the methods deprecated and if the code requires some form  
of escalated privileges to complete, then we should write some  
internal form of the method that completes tat task without  
authorization restrictions. Also these calls are basically to alter  
the behavior of a "Context" Object, in such cases instantiating a new  
Context object, or having the Context subclasses have more explicit  
types like UserContext vs. SystemContext. would resolve some of this  
as well.

-Mark


On Mar 21, 2007, at 7:08 AM, Andrea Bollini wrote:

> Well I'm putting myself at work...
> I have some questions about the authorization system that I would like
> to share with the community:
>
> 1) in many points of the "DSpace core" code there are
> setIgnoreAuthorization(true-false) blocks. I don't like them, many of
> them are related to the creation of  "stub" newly objects that are not
> yet related to other ones. If we introduce a "stub" flag in  
> DSpaceObject
> abstract class, we can check for autorization only when this flag  
> is set
> to false. Of course, the default of the flag will be false and it will
> be set to true only in create method where the check for authorization
> is responsibility of the container (community, collection, item,  
> bundle
> and so...).
>
> 2) the bug fix 1480496 (Cannot turn off "ignore authorization" flag!)
> has shown that the authorization method setIgnoreAuthorization() is  
> not
> friendly. In fact if we have two blocks that require authorization  
> check
> to false and these blocks are nested, as in the following example:
> ...[some java code here]...
> setIgnoreAuthorization(true) // start of first block
> ---my first block without authorization check
> ---my first block without authorization check
> ---my first block without authorization check
> ------setIgnoreAuthorization(true) // start of second block
> ------my second block without authorization check
> ------my second block without authorization check
> ------my second block without authorization check
> ------setIgnoreAuthorization(false) // end of second block
> ---other code in first block
> setIgnoreAuthorization(false) // end of first block
> ...
> the "other code in first block" is executed with authorization  
> check and
> does not work. It will be really too easy to come up with this  
> situation
> (actually possible for my patch automapper) with the new code  
> called by
> the Event System, so it should be fixed.
> A simple solution is to store the previous state of authorization  
> check
> before changing it, and to restore it at the end of the "special"  
> block.
> I can post a patch for this shortly, but I would like to know in  
> advance
> if someone sees any problems with the following:
> 1) add two methods: TurnOffAuthorizationSystem /
> RestoreAuthorizationSystem, with some code that can also be useful  
> when
> the debug is on to see "malformed" (XML-like) authorization blocks
> (thanks to James Rutherford for some useful suggestions);
> 2) set the setIgnoreAuthoritation methods to deprecated.
>
> Best wishes,
> Andrea
>
>
>
>
> Tim Donohue ha scritto:
>> Andrea,
>>
>> You are correct that we have your "Authorization system: delegate  
>> admins
>> patch" running in our production system here at UIUC (which was just
>> recently upgraded to 1.4.1).
>>
>> Currently, unfortunately the code has become a little embedded  
>> into some
>> of our other customizations here at UIUC.   So, I could  
>> potentially try
>> and pull it apart a bit.  But, admittedly, I currently have a growing
>> "to-do" list and I'm not sure that I'd get to it until at least  
>> the end
>> of March or early April.
>>
>> I would like to see this continued though, Andrea!  It'd be great  
>> to get
>> this code into one of the upcoming versions of DSpace (even 1.5, if
>> possible).   I know UIUC loves the ability to be able to assign
>> Community Administrators (which is what we use it for the most) as  
>> well
>> as Collection Administrators.
>>
>> Let me know if you do want my input in an updated patch.
>>
>> - Tim
>>
>> Andrea Bollini wrote:
>>
>>> Hi,
>>> I have insert in cc the dspace-tech mailing list where you can found
>>> more help about this and similar topics. I'm starting in a couple of
>>> days a review of my patch for make it compatible with the next  
>>> 1.5, I
>>> know that Tim (also in cc) use it in his istitutional repository  
>>> and it
>>> is a 1.4.x version but there are not a "public package" available  
>>> for
>>> this version...
>>> Tim can you provide it? if not don't worry ;-), I can make it for  
>>> the
>>> end of march.
>>>
>>> Best wishes,
>>> - Andrea
>>>
>>> Vlastimil Krejcir ha scritto:
>>>
>>>>   Dear Andrea,
>>>>
>>>>   I would like to use your patch "Authorization system: delegate
>>>> admins patch" (1373613). Unfortunately this patch is a bit old  
>>>> and I
>>>> cannost use it (or only with too much effort) for DSpace 1.4. Is  
>>>> there
>>>> any newer version for DSpace 1.4? And is it publicly available?
>>>>
>>>>   thank you for help
>>>>
>>>>   best regards
>>>>
>>>>   Vlastik Krejcir
>>>>
>>>> ------------------------------------------------------------------- 
>>>> ----------
>>>>
>>>> Mgr. Vlastimil Krejčíř
>>>> Library and Information Centre, Institute of Computer Science
>>>> Masaryk University in Brno, Czech Republic
>>>> Email: krejcir (at) ics (dot) muni (dot) cz
>>>> ICQ: 163963217
>>>> ------------------------------------------------------------------- 
>>>> ----------
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> DSpace-tech mailing list
> DSpace-tech@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dspace-tech

~~~~~~~~~~~~~
Mark R. Diggory - DSpace Systems Manager
MIT Libraries, Systems and Technology Services
Massachusetts Institute of Technology



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Reply via email to