Hi,
I have integrated (one of) our DSpace instances (running v1.4.2) with
our (home grown) portal authentication by creating an implicit
authentication class that checks for our portal authentication cookies,
and if they are there (and valid), it creates a DSpace authentication
context for the user (creating an ePerson record on the fly if
necessary) - it works pretty well, but I have 2 problems I can't get to
the bottom of and wondered if anyone had any pointers etc.
Problem 1:
=======
If a user logs in to our portal and then accesses DSpace and clicks "My
DSpace", the authentication class kicks in and they end up at their My
DSpace page . . . Fine.
The bitstreams in DSpace are protected by a READ policy that only allows
members of the group STIR_USERS to get access (and all new portal
authenticated ePersons are automatically added to this group) - if a
user has a DSpace authentication context in place (i.e. it says "Logged
in as" at the top left), the user can access protected bitstreams no
problem. Fine.
However, if a user logs on to our portal, and then accesses DSpace (so
not actually logged on to DSpace at this point but portal auth cookies
in place), the first time they try to access a bitstream they get the
page "Authorisation Required" - however, when presented with the
"Authorisation Required" page, it appears that they have been
authenticated because the "logged in as" message has appeared, and
hitting refresh brings up the required bitstream (and subsequent access
to bitstreams works fine). So it looks like the authentication class is
being correctly called when they try to access the bitstream, and the
authentication context is being set up, but for some reason I can't
fathom, they don't get access to the bitstream but instead get
redirected to the Authorisation Required screen . . .
The logs give me this:
2008-03-28 16:09:12,594 INFO
org.dspace.eperson.StirPortalAuthentication @
anonymous:session_id=1C92899D8684656C55C3EE88796A86CF:ip_addr=139.153.92
.71:login:type=StirPortalAuthentication
2008-03-28 16:09:12,594 INFO org.dspace.app.webui.util.Authenticate @
[EMAIL PROTECTED]:session_id=1C92899D8684656C55C3EE88796A86CF:ip_addr=139.1
53.92.71:login:type=implicit
2008-03-28 16:09:12,594 INFO org.dspace.app.webui.servlet.DSpaceServlet
@
[EMAIL PROTECTED]:session_id=1C92899D8684656C55C3EE88796A86CF:ip_addr=139.1
53.92.71:authorize_error:org.dspace.authorize.AuthorizeException:
Authorization denied for action READ on BITSTREAM:232 by user 0
- which seems to suggest some kind of problem - it recognises me as
[EMAIL PROTECTED] but describes me as "user 0". If I hit refresh, the item
appears and the log shows the next line as:
2008-03-28 16:09:16,605 INFO
org.dspace.app.webui.servlet.BitstreamServlet @
[EMAIL PROTECTED]:session_id=1C92899D8684656C55C3EE88796A86CF:ip_addr=139.1
53.92.71:view_bitstream:bitstream_id=232
Has anyone else ever seen this kind of behaviour with an implicit
authentication class? Anyone have any idea why this may be happening? Am
I doing something stupid with permissions? Any ideas where in the code I
can dig about to learn more about what is happening, or any code hack
suggestions to make this work the way I think it should?
Problem 2:
=======
Portal authentication is part of an authentication stack with "normal"
authentication below (so external users can create accounts if needs be)
- if a user who has NOT logged on to our portal attempts to access a
bitstream the implicit authentication fails (correctly), and they are
routed to the normal DSpace logon page - I've added a link to this page
for our local users which goes to our portal logon page with a redirect
back to the DSpace homepage - I would like, however, for this redirect
to take the user back to whatever page/bitstream they were trying to
access.
So, is there anyway to pick up the URL of the page they were trying to
access (where the authentication was required) from within the logon JSP
page so that I can embed this in the link to our portal logon page?
Another possibility is to remove the "normal" authentication class
altogether (understanding that this means no external users can use this
instance of DSpace) and have the portal authentication class
automatically route them to our portal logon (along with an appropriate
redirection URL back to DSpace) if the implicit authentication fails -
is this doable? If so, anyone got any pointers on how best to achieve
it?
Thanks in advance for any suggestions/pointers anyone may have (and to
anyone else who bothered to read to the end of this rather wordy request
for help!).
Cheers,
Mike
Michael White
eLearning Developer
Centre for eLearning Development (CeLD)
S7, The Library
University of Stirling
Stirling SCOTLAND
FK9 4LA
Email: [EMAIL PROTECTED]
Tel: +44 (0) 1786 466877
Fax: +44 (0) 1786 466880
http://www.is.stir.ac.uk/celd/ <http://www.is.stir.ac.uk/celd/>
--
The University of Stirling (a charity registered in Scotland, number
SCO11159) is a university established in Scotland by charter at Stirling,
FK9 4LA. Privileged/Confidential Information may be contained in this
message. If you are not the addressee indicated in this message (or
responsible for delivery of the message to such person), you may not
disclose, copy or deliver this message to anyone and any action taken or
omitted to be taken in reliance on it, is prohibited and may be unlawful.
In such case, you should destroy this message and kindly notify the sender
by reply email. Please advise immediately if you or your employer do not
consent to Internet email for messages of this kind.
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
