Simon,
Thank you for the advice. I guess I was generalizing a bit too much based on
administrator behaviors.
Regarding Stuart's recommendation of extending EmbargoSetter to meet our
needs, I created a local subclass of EmbargoSetter to set the READ
permission for the bundle and the bitstreams, for the group that is defined
in the IP authentication section. This is done after all READ permissions
are removed from the bitstream. Inspecting the authorizations on embargoed
items, the permissions are being applied as expected.
I am still unable to read the bitstreams for the embargoed items when I am
accessing the collection from an IP address listed in dspace.config. To be
sure that the read permission was being recognized for the group, I created
a new user and added that user to the group. When I logged in as that user,
I was able to read the bistreams for embargoed items.
This leads me to believe that there must be a problem with how I configured
IP authentication. The following snippets are from
[dspace]/config/dspace.cfg (group name and IP address have been obfuscated):
377 plugin.sequence.org.dspace.
authenticate.AuthenticationMethod = \
378 org.dspace.authenticate.IPAuthentication, \
379 org.dspace.authenticate.PasswordAuthentication
506 authentication.ip.GROUP = xxx.xxx.xxx.xxx/18
I hope I am not being too forward, but I feel like there might be something
fundamental that I am not understanding. Any pointers are greatly
appreciated.
Thank you,
Dave Falke
On Fri, Mar 12, 2010 at 11:20 AM, Simon Brown <[email protected]> wrote:
>
> On 11 Mar 2010, at 20:41, Dave Falke wrote:
>
> > Thanks for the response, Stuart. That is what I was thinking. I had
> > also added a DEFAULT_BITSTREAM_READ policy on the collection for
> > administrators, and I was still able to view embargoed items when
> > logged in as an administrator. This led me to believe that not all
> > READ permissions were not being removed from the bitstreams.
>
> You probably shouldn't be basing any conclusions on what being logged
> in as an admin lets you do. Admins are special in many ways, because
> it's hard to admin a repository you don't have access to bits of. You
> should do all your testing of access-related stuff with a non-admin
> account.
>
> --
> Simon Brown <[email protected]> - Cambridge University Computing Service
> +44 1223 3 34714 - New Museums Site, Pembroke Street, Cambridge CB2 3QH
>
>
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Dspace-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
