Hi Pere,
In theory, the "intercept and force login" way JSPUI does things should make
it easier for us to allow the request to continue afterwards, though the
other issue you touch on (a user is viewing an item, but wants to login and
then be redirected back to their start page) needs some thought, too...
To expand a bit on how the JSPUI currently works: (all: please correct me if
I'm wrong!)
In JSPUI's web.xml, we have "filter-mapping" entries as well as URL mapping
entries, which tell JSPUI which paths require particular filters (eg.
AdminOnlyFilter, RegisteredOnlyFilter). These filters intercept the request,
obtain context, start stackable auth, and allow the filter chain to proceed.
The authentication is handled by org.dspace.app.webui.util.Authenticate,
which is where things are currently going wrong (though I don't know why,
without closer inspection). It tries to store the original request in a
session attribute called "interrupted.request.url", and then retrieves it in
resumeInterruptedRequest(). If it can't find that original URL, it defaults
to "/mydspace".
As things stand, session.getAttribute("interrupted.request.uri") is *always*
null, so the user is always directed to /mydspace.
I'll do some tracing of the request, session, context etc. to see if I can
find out where/why this is happening.
For more information, take a look at
org.dspace.app.webui.filter.RegisteredOnlyFilter and
org.dspace.app.webui.util.Authenticate
(Also note that to my knowledge, "ShibbolethFilter" doesn't appear to be
used anywhere.. the RegisteredOnlyFilter is enough, since it starts
stackable authentication, and if Shibboleth is in there, it'll just be
another auth method.)
On a tangent, I just want to say it's great that you're taking an interest
in DSpace development above and beyond your GSoC project.. your efforts are
certainly appreciated by the community!
Cheers,
Kim
On 8 October 2010 10:38, Pere Villega <[email protected]> wrote:
> Hi,
>
> I have a question on DS-570, I would like the opinion of the community:
>
> - For XMLUI, the functionality is clear, you press login and you come back
> to the page you were watching after successful login.
>
> - For JSPUI, the problem is that we don't have a "login" button. For the
> user to authenticate, it must request an action that requires permissions
> not given to anonymous users, then the user will see the login screen. This
> means login is always a result of an interrupted request. So, to emulate the
> behaviour of XMLUI, we would need to add a "login" link hidding in the
> process the current user-related links (My Dspace, etc) and displaying them
> after the user has authenticated.
>
> This said, I'm not sure if it makes sense to add a "login" button to JSPUI.
> What do you think? We should add this to JSPUI too, or we just leave it as
> it is? If you think we should modify JSPUI, I can try to do it this weekend.
>
> Cheers,
> Pere Villega
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
> Spend less time writing and rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Dspace-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>
>
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
