Hi,
Unfortunately I've been sidetracked with other tasks, so only just
coming back to look at my implicit authentication problems first raised
a couple of weeks ago . . .
Using DSpace v1.4.2. This DSpace is being used as a Learning Object
repository and all the items in the repository are protected (only
accessible to Stirling staff and students).
Summary of main problem, when accessing a protected bitstream with the
token required for implicit authentication in place (a cookie from our
portal in this case), instead of being authenticated/authorised and
routed to the requested bitstream, the user is authenticated but then
routed to "Authorisation Required" page (even though they are now
authenticated!) ....
This doesn't happen if accessing My DSpace with the required token in
place - user is authenticated and then seamlessly routed to My DSpace.
It's also worth noting that this problem doesn't occur if you use an
explicit authentication method - when the unauthenticated user attempts
to access a protected bitstream, they are correctly routed to the login
page, and then on to the requested bitstream.
I've been digging a little deeper into the code and I think this
behaviour may be caused by a bug - if there is anyone out there using an
implicit authentication method I would be interested to know if you have
this problem as well (i.e. is it a reproducible bug?). If there is
anyone who is more familiar with the authentication flow than I, I could
do with a little help (to confirm whether the problem definitely is a
bug and to help me fix it if possible!) . . .
Jim Rutherford responded to my original posting:
> This sounds a little odd. Try checking the ordering of the
> authorization processes in the two servlets (BitstreamServlet
> and MyDSpaceServlet if my memory serves me correctly).
OK - looking at the code - the reason My DSpace works but the bitstream
access doesn't seems to be because accessing My DSpace invokes the
"RegisteredOnlyFilter" which puts the authentication context in place
before continuing on to MyDSpaceServlet.
The bitstream access is handled by DSpaceServlet using the doDSGet in
BitstreamServlet - when the BitstreamServlet attempts to retrieve the
required item object using Bitstream.retrieve, the retrieve method calls
AuthorizeManager.authorizeAction, which throws an authorizationException
if the user is not authorised (fair enough).
This authorizationException is caught by DSpaceServlet:
----------------------
catch (AuthorizeException ae)
{
/*
* If no user is logged in, we will start authentication,
since if
* they authenticate, they might be allowed to do what they
tried to
* do. If someone IS logged in, and we got this exception,
we know
* they tried to do something they aren't allowed to, so we
display
* an error in that case.
*/
if (context.getCurrentUser() != null ||
Authenticate.startAuthentication(context, request,
response))
{
// FIXME: Log the right info?
// Log the error
log.info(LogManager.getHeader(context,
"authorize_error", ae
.toString()));
JSPManager.showAuthorizeError(request, response, ae);
}
}
------------------------------
So, if the user isn't logged in, this will call
Authenticate.startAuthentication in order to authenticate the user.
It is in Authenticate.startAuthentication where I believe the problem
lies - this does different things for implicit and for explicit
authentication:
- for implicit authentication, if authentication is successful, it
simply returns true.
- for explicit authentication, it stores the current request and
redirects to the login page. The login page passes the credentials to
PasswordServlet which, once authentication is complete, resumes the
interrupted request, so we go round the circle again, but this time with
the appropriate user context in place so they get access.
> Looking at the logs, it seems you are challenged to authenticate,
> you are logged in implicitly, but something doesn't quite work
> correctly:
>> 2008-03-28 16:09:12,594 INFO
>> org.dspace.app.webui.servlet.DSpaceServlet @
>>
[EMAIL PROTECTED]:session_id=1C92899D8684656C55C3EE88796A86CF:ip_addr=139
>> .153.92.71:authorize_error:org.dspace.authorize.AuthorizeException:
>> Authorization denied for action READ on BITSTREAM:232 by user 0
> The logging code has your email address, but not your user ID.
> Can you figure out why this is? This really shouldn't be possible,
> and the reason it's failing is because the auth check is using
> your ID, not your email address to do the resource policy lookup.
Looking at the code above this becomes (fairly) obvious - the
authorisation exception is thrown for the unauthenticated user (as
described above), so the catch block calls the authentication code - the
implicit authentication succeeds and returns true, but then
DspaceServlet simply logs the exception (which happened before the user
had authenticated, hence no user ID, but the logging call contains the
up-to-date context with the user's email address) and then redirects to
the Authorisation Required page . . . .
All the above comes with the caveat that I am not "at one" with the
DSpace code so could quite easily have misunderstood what is going on,
so if that is the case, please feel free to correct me.
I've tried a couple of (fairly random) hacks in various places to try
and get the request re-routed back to the original URL, but I've had no
joy :-(.
The academic that I've implemented this repository for is doing a demo
to the University community on May 8th, so I'm obviously very keen to
try and fix this before then! If there is anyone out there who may be
able to help, it would be very much appreciated!!
Many thanks,
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/
--
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.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
