7

How can I create a new session in JSF 2.0 as soon as a new User logs in on the application?

Tiny
  • 27,221
  • 105
  • 339
  • 599
Rajat Gupta
  • 25,853
  • 63
  • 179
  • 294
  • Well, as soon as the user accesses the application, it will be a new session unless your cookies are set to be remembered forever. – adarshr Mar 31 '11 at 19:40
  • You can use apache shiro to do this and another things to manage authentication. You can view a great tutorial made by Bauke (BalusC): http://balusc.blogspot.com/2013/01/apache-shiro-is-it-ready-for-java-ee-6.html – John Alexander Betts Oct 24 '13 at 16:13

1 Answers1

9

You don't need to. It makes in well designed webapps no sense. The servletcontainer does already the session management. Just put the logged-in user in the session scope.

@ManagedBean
@RequestScoped
public class LoginController {

    private String username;
    private String password;

    @EJB
    private UserService userService;

    public String login() {
        User user = userService.find(username, password);
        FacesContext context = FacesContext.getCurrentInstance();

        if (user == null) {
            context.addMessage(null, new FacesMessage("Unknown login, try again"));
            username = null;
            password = null;
            return null;
        } else {
            context.getExternalContext().getSessionMap().put("user", user);
            return "userhome?faces-redirect=true";
        }
    }

    public String logout() {
        FacesContext.getCurrentInstance().getExternalContext().invalidateSession();
        return "index?faces-redirect=true";
    }

    // ...
}

The logged-in user will be available as #{user} in all pages throughout the same session and also in @ManagedProperty of other beans.

On logout, however, it makes more sense to invalidate the session. This will trash all session scoped beans as well. You can use ExternalContext#invalidateSession() for this.

    public String logout() {
        FacesContext.getCurrentInstance().getExternalContext().invalidateSession();
        return "index?faces-redirect=true";
    }

See also:

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • I would definitely invalidate the session. The reason is a little bit contrived, but it covers a theoretical security issue: The old user can note the session id while logged in. Then, when the new user logs in, the old user can use the existing session id (e.g. on a second computer) to work in the session of the new user. – Chris Lercher Mar 31 '11 at 20:39
  • @Chris: sessions (read: cookies) are not shared among computers. You're probably confusing with [session fixation](http://en.wikipedia.org/wiki/Session_fixation) hacks when a session ID has been leaked by bug/mistake/accident. Invalidating the session helps very little to nothing against. When the user is logged out, there's already no user in the session and nothing can be taken over :) Invalidating the session is however a good practice to do a "quick cleanup" of memory resources. – BalusC Mar 31 '11 at 20:44
  • @BalusC: You're setting a new user in the current session (without invalidate). The session information is (typically) held in a cookie in the browser. Copy the sessionId in that cookie into a new browser e.g on a different machine, and the session *will* be shared between the two computers (I've tested this). – Chris Lercher Mar 31 '11 at 20:50
  • @Chris: Yes, that's the session fixation hack. Invalidation doesn't help against that. – BalusC Mar 31 '11 at 20:53
  • 1
    ...which would be defeated by session.invalidate()... :-) The new user gets a new session id. The old user's session id is invalid, as soon as the logged in user changes, so he can't use it anymore. – Chris Lercher Mar 31 '11 at 20:55
  • @Chris: Just setting user to `null` would have effect in the other (hacker's) side as well. – BalusC Mar 31 '11 at 20:58
  • @BalusC: Yes, of course. But that's not exactly what your code does - on login, it sets `current` to a new user. – Chris Lercher Mar 31 '11 at 21:00
  • @Chris: That doesn't harm if the session is not hacked. Whatever you do, invalidating the session doesn't prevent session fixation hacks, it's then too late already since the victim is usually not aware of that. Avoiding leaking the session ID (by XSS, by copypastes/screenshots of request/response headers, etc) is the only prevention. – BalusC Mar 31 '11 at 21:05
  • @BalusC: I'd like to illustrate my point with a little story (I like stories): Let's say I'm using my computer to check my webmail (maybe even using HTTPS). While I do that, I look into the browser cookies, and write down my session id (I wouldn't even call this a hack - it's my session after all). My girlfriend wants to check her webmail, too. So I let her have the keyboard, and she logs in. I leave the room, because she doesn't want me to read her mail. But now, I can use my laptop in the other room to read her mail. If the session were invalidated, this wouldn't work. – Chris Lercher Mar 31 '11 at 21:13
  • @Chris: nice edge case. Not really a hack, no :) – BalusC Mar 31 '11 at 21:18
  • @BalusC: Sorry for being so insistent on this case by the way... I do get carried away when it comes to security issues sometimes :-) Nevertheless, I'd prefer, if you updated your answer, because it could lead to quite unnecessary security risks (think internet cafes, ...), so it's simply not "good advice" as it stands now. – Chris Lercher Mar 31 '11 at 21:57
  • Why would we store a @managedbean in session, which then contains the user bean ? Wouldn't it be better to only store the user bean in session, as BalusC showed [here in the updated part of his answer.](http://stackoverflow.com/a/2207147/401881) ? – Med Mar 24 '13 at 17:10