On Fri, Mar 28, 2008 at 04:27:41PM +0000, Michael White wrote: > 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. > > <snip/> > > 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 . . .
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). Looking at the logs, it seems you are challeneged 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. > 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. This is not an uncommon request. It is technologically possible to do this by just passing around the request path & parameters from the URL, but DSpace just doesn't do it. I'm not sure about the historical reasons why (beyond simplicity of implementation), but it shouldn't be too much work to include. When I've done this in the past, I just include the requested page as a hidden parameter in the login form and have the processing servlet look for the parameter and use it if appropriate. > 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? This probably isn't going to be pleasant for your users because it rips them out of the context of DSpace and puts an extra burden on your portal to do the redirection back. Again, it would be possible, but I think it's probably the wrong approach, and having DSpace take care of the redirection would be for the best (indeed, if you can do this in a general way and provide a patch, I'm sure you'd make some friends ;). cheers, Jim -- James Rutherford | Hewlett-Packard Limited registered Office: Research Engineer | Cain Road, HP Labs | Bracknell, Bristol, UK | Berks +44 117 312 7066 | RG12 1HN. [EMAIL PROTECTED] | Registered No: 690597 England The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error, you should delete it from your system immediately and advise the sender. To any recipient of this message within HP, unless otherwise stated you should consider this message and attachments as "HP CONFIDENTIAL". ------------------------------------------------------------------------- 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
