Bear Bibeault wrote:A typical scenario is that the business layer needs to know which user is "logged in" and makes sure that the user has the ability to perform the operation.
Thus each business layer operation gets passed the current user and does a check for permissions or scope or whatever determines whether the request is valid prior to actually doing something.
In the system I an currently working on, we do both. We have a permissions structure that defines what a user is allowed to do, and scoping to determine what the user is allowed to do those operations to.
This is not generally something tacked on in the UI layers. Your business layer needs to be set up to handle this.
Bear Bibeault wrote:Well, I assume that your users are logging in and interacting with the system via the UI.
What are you using for authentication? I never seem to find the container-managed stuff versatile enough for my needs, so I always set up my own. Basically, when a user logins in, a token is place in the session. This token, which is used to identify not only that a user is logged in, but which one, is passed to each business layer operation, whose job it is to validate the permissibility of the operation before carrying it out.
Bauke Scholtz wrote:HttpSession#setAttribute().
Learn to find, read and understand the API, luke: javax.servlet.http.HttpSession.
Bauke Scholtz wrote:It is stored entirely on the server side. All what the client have with regard to the session is a simple cookie referenceing the session ID or the jsessionid addendum in the URL. So it's secure enough. You have full control over what you get/set in the session. After all it depends on the robustness of the code you write yourself.
Bear Bibeault wrote:I'd have it redirect to your login page explicitly.
Bear Bibeault wrote:The context should never be hard-coded. Be sure to obtain it dynamically. (See the FAQ entry on resource URLs in the JSP FAQ if need be).
Bear Bibeault wrote:I just personally find that fragile. I like to be more explicit.
Bear Bibeault wrote:These days I'm doing things in a more Ajax-y manner, but using traditional requests I used to set up a session variable that had a pending message. If the page saw that such a message was there, it would display it and remove the message from the session.
As I user a front controller (see FrontMan link below) it's easy for me to control what prefixes all the URLs have, and to ignore prefixes that address resources that don't need authentication.