The GroundBlog By Duncan Mills
Duncan Mills's WebLog from GroundSide

Warning: This is quite an old posting - about 2 years old now. It does work and has been used successfully by many people. Some folks, however, seem to have problems with it and much as I'd love to spend time looking at their web descriptors I don't have that time to spend. So if this does not work for you just check everything carefully. This is an idea not a product. Ideally of course the JCP would sort out this whole issue and we'd have a generic way of working with container security and JSF without having to use hacks like this or verbatim tags. Now read on...

---

I've been over the problems with trying to create a J2EE login form
with JSF before and had pretty much decided that it was simply not
possible to do in a clean way without <f:verbatim> tags.
Well I've been looking at the problem again and have changed
my thinking a little and I've come up with a (not too hacky)
solution.
Let me recap the issue here. The various Form components available in
JSF will not let you specify the target action, everything is a
post-back. When using container security, however, you have to
specifically submit to the magic action j_security_check.
This means that the only way to do this in a JSF page is to use an HTML
form tag enclosed in verbatim tags. This has the side effect that the
post is not handled by JSF at all meaning you can't take advantage of
normal JSF functionality such as validators, plus you have a horrible
chimera of a page containing both markup and components. This screws up
things like skinning.
 In a flash of inspiration it occurred to me that I could
build the whole login page as a pure JSF page and avoid the whole
problem of having to use verbatim tags at all. Instead the JSF page
would simply gather the input for the username and password and would
pass that on to a proxy to do the actual submit for me. I'd tried
something similar before programmatically with no luck, but this time
I'm using a JSPX (not JSF) page as the proxy. Let's look at the
bits

The Main Login Page

The main login is a normal JSF page at it's most basic it will need two
fields and a commandButton to "logon" so a simple example (excluding
headers) will look a little like this:

<f:view>
  <afh:html>
    <afh:head title="login">
      <meta
http-equiv="Content-Type"
           
content="text/html; charset=windows-1252"/>
    </afh:head>
    <afh:body>
     
<h:form>
       
<afanelForm>
         
<af:inputText label="User Name:"
           
           
id="j_username"/>
         
<af:inputText label="Password:"
           
           
id="j_password"
           
           
secret="true"/>
         
<f:facet name="footer">
           
<afanelButtonBar>
             
<af:commandButton text="Logon"
           
           
       
action="#{Login.loginAction}"/>
           
</afanelButtonBar>
         
</f:facet>
       
</afanelForm>
     
</h:form>
    </afh:body>
  </afh:html>
</f:view> 
The key things here are the setting of the ID attributes of
the input fields to ensure that the correct names for the values are
used on the POST, and the action defined for the
commandButton. 

The loginAction

The commandButton references an action in a request scope
managed bean. This action is pretty simple:
public String loginAction() throws IOException,
ServletException {
  ExternalContext ectx =
FacesContext.getCurrentInstance().getExternalContext();
  HttpServletRequest request =
(HttpServletRequest)ectx.getRequest();
  HttpServletResponse response =
(HttpServletResponse)ectx.getResponse();
  RequestDispatcher dispatcher =
request.getRequestDispatcher("loginProxy.jspx");
  dispatcher.forward(request,response);
  return null;
}
The code basically issues a forward to the page
"loginProxy.jsp", note that by the time this code executes, things like
validators on the main login page will have a chance to be
processed. 
As a side note it did occur to me to dispatch direct to
j_security_check at this point - however, in OC4J certainly the
getRequestDispatcher() call will return null for j_security_check, so
that was a non starter. If you use a different app server give that a
go first - before you try the proxy page - it might just work.

The loginProxy

The proxy page is a plain JSPX (although it can also be JSP as
well) that actually has not visible
UI. It re-maps the values for username and password off the request and
auto-submits to j_security_check:
<?xml version='1.0' encoding='windows-1252'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page"
version="2.0">
  <jsp:output omit-xml-declaration="true"
doctype-root-element="HTML"
             
doctype-system="http://www.w3.org/TR/html4/loose.dtd"
             
doctype-public="-W3CDTD HTML 4.01 Transitional//EN"/>
  <jsp:directive.page
contentType="text/html;charset=windows-1252"/>
  <html>
    <head>
      <meta
http-equiv="Content-Type"
           
content="text/html; charset=windows-1252"/>
     
<title>Logging in</title>
    </head>
      <body
onload="document.forms[0].submit()">
      <form
method="post" action="j_security_check">
       
<input type="hidden" name="j_username"
value="${param.j_username}"/>
       
<input type="hidden" name="j_password"
value="${param.j_password}"/>
      </form>
    </body>
  </html>
</jsp:root>

So there you go - this technique seems to work well. The only
problem is that the browser will flash to a blank page when you forward
to the proxyPage, however, this is not so bad and you could dress that
page with a friendly message if you really need to. On the up side,
using this technique will mean that the login fields and button can be
happily mixed onto any JSF page and you can take full advantage of JSF
for pre-processing before the you forward to the proxy. For instance if
you wanted to add a "Remember Me" checkbox into the login you can now
do it.