This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
I have written a simple web application, using JSF on Glassfish, that requires the user to logon via form based authentication. I have the basics working fine but cannot work out how I can achieve this using HTTPS. From searching the internet, it seems you can configure j_security_check to do this for you. However, a longstanding problem about this is that JSF does not have the ACTION capability but posts to managed beans. Has anyone any ideas about how to get around this?
In addition, once the user has successfully logged on and a session created, I would like to switch back to HTTP in order to save on the performance overhead. Is this a case of redirecting? Also, how do you configure the server to handle this?
When you use form-based authentication as defined in web.xml, you're asking for the JEE Container to manage security. You don't write any login code yourself - it's built into the container. The login process is done by hijacking the incoming request, replacing it with a request to the login (or loginfail) page, and processing the inputs (user ID and password). If the container determines the user is authorized, the hijacked request is popped out of the place where it was temporarily stored and processing is resumed as though login had never been requested. Except, of course, that if it hadn't, you'd never have been allowed to continue.
The transport mechanism (http/https) is also defined in web.xml. You can specify that certain URLS )as defined by URL patterns) MUST be accessed solely HTTPS. Other URLs can be HTTP or HTTPS access, and so to drop back to HTTP, just link to a URL with an "http:" in it.
Returning to the login process, login is forced whenever your web.xml matches the URL to a pattern that's under authentication control. The login action itself, incidentally, does not provide the full set of resources that a normal URL request can access, so login pages can't be built on complex servlet-dispatched frameworks such as JSF or Struts. Also, make sure that your login/loginfail pages don't attempt to access resources that won't be available until AFTER you've logged in!
JSF introduces one additional wrinkle to the equation. Since JSF URLs don't track directly, you sometimes have to force them or you'll end up with a security hole, as a secured resource gets accessed under a non-secured URL. You can avoid this by adding the <redirect/> element to a navigation item to cause it to be forced to use its "proper" URL.
Customer surveys are for companies who didn't pay proper attention to begin with.