hirondelle.web4j.security
Interface LoginTasks

public interface LoginTasks

Perform tasks required after successful user login.

See BuildImpl for important information on how this item is configured. BuildImpl.forLoginTasks() returns the configured implementation of this interface. There is no default implementation of this interface. You must supply one. (You can always supply an implmentation that does nothing, if you wish.)

This interface exists to allow an application to react to successful user logins. At least one of those tasks must put an item in session scope. The web4j Controller will use the presence/absence of that item to determine if the login tasks have already been performed.

Example tasks :

• place user preferences in session scope
• place the user id in session scope; the id is different from the user login name (see important note below). It's highly recommended that such an id be placed in session scope using ActionImpl.USER_ID as its key. Doing so lets your Actions easily access the id using ActionImpl.getUserId().

User Login Name Versus User Id

After a successful login, the container will always place the user's login name in session scope. However, it's often convenient or desirable to have a corresponding user id in session scope as well. In this context, the user id is a database identifier, the primary key of an underlying user record in the database (almost always an integer value). Having the user id in session scope often helps to enforce data ownership constraints.

The User Id Is a Server Secret

The user login name and the user id must be treated very differently. While the user login name can of course be displayed to the user, the user id is a server-side secret, and should never be made visible to the user. It's nobody's business, including the user to whom it belongs. You can place the user id in session scope, and your server-side code can use it, but its value can never be part of the HTTP response in any way. Exposing it allows one user to access the data of another. Always treat the user id as a server-side secret. Failure to do so is a huge security risk.

Consolidating User Preferences Into One Object

If there are many user preferences, and not just one, then it might make sense to place a single object into session scope, which gathers together all such preferences into a single object. Note, however, that the default implementations of LocaleSource and TimeZoneSource are not consistent with such a style, since they expect their data to be stored under separate keys defined in Controller.

Method Summary

boolean	hasAlreadyReacted(HttpSession aSession) Return true only if the user login has already been processed by reactToUserLogin(HttpSession, HttpServletRequest).
void	reactToUserLogin(HttpSession aExistingSession, HttpServletRequest aRequest) React to a successful user log in.

Method Detail

reactToUserLogin

void reactToUserLogin(HttpSession aExistingSession,
                      HttpServletRequest aRequest)
                      throws AppException

React to a successful user log in. Typically, implementations will look up data related to the user, and place it in session scope.

This method is called only if all of the following are true:

• a session already exists
• the user has successfully logged in
• hasAlreadyReacted(HttpSession) returns false

Throws:

AppException

hasAlreadyReacted

boolean hasAlreadyReacted(HttpSession aSession)

Return true only if the user login has already been processed by reactToUserLogin(HttpSession, HttpServletRequest). Typically, implementations will simply return true only if an item of a given name is already in session scope.