cannot get original request URI on JSF2 based form login page

[j_ri]

Hi,

I try to implement a JSF2 login page for container form based authentication

in my web.xml I have this configuration:

{code:xml}
 <login-config>
       <auth-method>FORM</auth-method>
       <realm-name>CustomRealm</realm-name>
       <form-login-config>
           <form-login-page>/login.jsf</form-login-page>
           <form-error-page>/login.jsf</form-error-page>
       </form-login-config>
   </login-config>
{code}

In my backing bean for login.xhtml I tried to get the original URI for redirecting after successful login like this:

{code}
String uri = externalContext.getRequestMap().get("javax.servlet.forward.request_uri");
{code}

Unfortunateyl this returns nothing;-(

I also tried to get the URI directly in the view page, instead of the backing bean,

{code:xml}
#{requestScope['javax.servlet.forward.request_uri']}
{code}

but I also get an empty result here.

I found several sites which state that it should work this way....but not for me;-(

e.g.

[http://stackoverflow.com/questions/8024344/user-login-with-jsf-2-0]
[http://stackoverflow.com/questions/5144186/redirect-to-protected-resource-or-original-saved-request-after-servlet-3-0-https]
[https://community.jboss.org/message/129648#129648]

Do you have any ideas how to achieve want I want to? Or is that a bug in JBoss 7?

Thanks,

Jochen

[sfcoy]

Form based login has always been a bit pathologically private in that users are not intended to link directly to the login form.

The idea is that when a user attempts to access a protected resource, the container automatically invokes the login form, and then redirects to the original URL following successful authorisation.

You would not normally perform this redirection yourself.

[j_ri]

But why was HttpServletRequest.login(username, password) introduced with servlet-specification 3.0, if you shouldn't use it?

Actually the "/j_security_check" method is sufficient. But if you use a custom page, you can have better info/error messages.....

[sfcoy]

That's different. Either you manage the login process, or let the container do it (via /j_security_check, etc). I suspect that mixing the two may lead to confusion.

[j_ri]

Sorry, I don't agree, since the new Servlet 3.0 method HttpServletRequest.login(username, password) does exactly the same as "/j_security_check". It delegates the login process to the container.

I think it was introduced to be able to make a "clean" JSF2 login page. With "/j_security_check" you have to implement a mix between JSF/Facelet tags and plain HTML for the form.....

[sfcoy]

My reading of the spec differentiates "Declarative Security" and "Programmatic Security". It says this about programmatic security:

The login method allows an application to perform username and password collection (as an alternative to Form-Based Login). The authenticate methods allow an application to instigate authentication of the request caller by the container from within an unconstrained request context.

Declarative security consists of (amongst other things) Form-Based Login which uses the "/j_security_check" mechanism.

But all of that is incidental really. JSF2/Facelets form based authentication (aka Declarative Security) works just fine for me. I've not needed to use Programmatic Security for this purpose.

[j_ri]

Which version of the spec did you cite? I just downloaded the 3.0 final spec and cite it like that:

The authenticate method allows an application to perform username and

password collection (as an alternative to Form-Based Login). The login methods

allow an application to instigate authentication of the request caller by the container

from within an unconstrained request context.

I interpret this, as I already explained. "HttpServlerRequest.login(user, pwd)" delegated to the container.

The actual question is: Is the container, based on the

{code:xml}

    <form-login-config>

        <form-login-page>/login.jsf</form-login-page>

        <form-error-page>/login.jsf</form-error-page>

     </form-login-config>

{code}

configuration, doing a forward according to chapter 9.4.2 of the specs?

If yes the "javax.servlet.forward.*" request attributes must be set.

[sfcoy]

FWIW, I have:

Version 3.0 Rev a Rajiv Mordani December 2010

The section I quoted has a change bar next to it .

The behaviour of form based login is described in §13.6.3. There is nothing there that suggests that it will perform a servlet level "forward". It just renders the login form and returns it to the client instead of the requested resource.

[j_ri]

But all of that is incidental really. JSF2/Facelets form based authentication (aka Declarative Security) works just fine for me. I've not needed to use Programmatic Security for this purpose.

IF the user entered the correct password and everything works fine the declarative security works for me, too. What I'm missing is the possibility to show messages. E.g. "Incorrect Password", "Account deactivated due to 5 tries", "LDAP not available", etc.

How do you show these messages on the login page?

[sfcoy]

{code:xml}<form-error-page>/login.jsf?loginFailed=true</form-error-page>{code}

{code:xml}<h:panelGroup layout="block" id="login-error" rendered="#{param['loginFailed']}">#{loginPage['message.authenticationFailed']}</h:panelGroup>{code}

Never ever display any more information than "login failed", otherwise you give potential attackers clues as to how they may better proceed.

[j_ri]

we only use it for our inhouse applications, so the problem with potential attackers ist not that important. since we actually use SPNEGO based single-sign-on the form is only shown for developers..and if there is something wrong with the sso mechanism. and for the latter case I want to show the message who should be contacted.

anyway, thanks you for hint with "<form-error-page>/login.jsf?loginFailed=true</form-error-page>". this should be sufficient for now.