Predictions

[Roger]

In the Predictions app, both the login and the list links share the same URL: .../predict/main/lists/PredictionListAction.list

How does the app know when to route unauthenticated user to Login.jsp page? I searched through the code but did not find the logic. Does j_security_check handle that behind the scene?

Thanks,

Roger

[Roger]

I found the logic. It is in web.xml.

Does the web4j framework handle the password un-hashing during authentication or it let j_security_check to take care of that end-to-end? 

[John O'Hanley]

Hi,

You may be confused by the general scheme of how log-in works in a servlet.

The secret is that there is no login url, per se. The user can bookmark any url they want, and the security mechanism will always kick in (if that url is protected by a security-constraint.)

The servlet spec takes a different approach: it acts to protect URLs. The app and the container cooperate closely to implement login.
1. The app specifies a 'security-constraint' (a family of URLs) in web.xml.
2. The end-user the requests a url that's part of a security-constraint.
3. The *container* (Tomcat) detects the url is part of a security-constraint defined in the app's web.xml. Here, Tomcat is acting as a kind of a wrapper around the app's regular behavior.
4. Tomcat asks for the user's name/password, using a form specified in web.xml.
5. Tomcat compares the credentials to a data source specified in web.xml.
6. If Tomcat determines that the credentials are good, it *redirects* the user to the page they originally requested, and the user is now logged in.

j_security_check is a special name defined by the servlet spec (not web4j). The login form needs to use that name as its target.

Tomcat allows the password to be stored in a hashed form, as long as you tell it the hash function being used. That's part of Tomcat config, not the servlet spec, I think.

Is this helpful? Or am I misunderstanding your puzzlement?

- John