• Post Reply Bookmark Topic Watch Topic
  • New Topic

Security  RSS feed

 
Corey McGlone
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd like to allow users to log in to a site with a user name and password. Now, don't get me wrong, I'm not going to be passing any sort of highly confidential data (like CC numbers or the like). Rather, each user should be able to log in and have their preferences enacted.
Now, what I need to know is, what is the best way to keep track of each user? I mean, once they've given me their user name and password, how do I know that the next request they send is from them? Is it safe to simply put their user information in the session? Is there some other way I should go about this?
Also, would it be worth it to try to use SSL for the login procedure? Security isn't a major concern of mine and, if using SSL is difficult, I just won't bother for now. I'm more concerned that I'm able to keep track of my users.
Thanks,
Corey
 
ersin eser
Ranch Hand
Posts: 1072
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you have a limited number of users you can list them in tomcat-users.xml under
C:\Apache Tomcat 4.0\conf as follows
<tomcat-users>
<user name="tomcat" password="tomcat" roles="tomcat" />
<user name="role1" password="tomcat" roles="role1" />
<user name="both" password="tomcat" roles="tomcat,role1" />
<user name="simon" password="password" roles="registered" />
<user name="guest" password="" roles="guest" />
</tomcat-users>
Then, You can validate them declaratively using
<security-constraint> <web-resource-collection> tags
Big number of users probably will be stored in DB.
If the traffic going to be very high and if you Are going to
store the settings in db too, then you might wanna consider using Value objects
to get their customization settings .
Or if you allow some standart set of custom effects: get their standart custom
settings style indicator, store it in the session variable and tie it to related xslt or css file dynamically .
Did I go crazy here ? :-)
 
Corey McGlone
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not as concerned with them "logging in" (although your info is very helpful) as I am with maintaining their logged in status. I don't want to have them send along their user id and password every time the submit a request for a new page, but I do want to know who they are every time they do that.
For example, when someone would come to the site initially, they'd be prompted for a username and password through an HTML form. I can go ahead and validate that and then display them a fitting page. We'll assume that the user logged in successfully.
Now, when the user clicks on a link to go to another page and the servlet is invoked, how do I know the request came from the same user that just logged in and not from some user that had been logged in for some time?
Is it possible to simply put the user's info in the session? Is that a safe place to put it? Are there any other ideas about how this could (or should) be done?
Thanks,
Corey
 
ersin eser
Ranch Hand
Posts: 1072
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, I believe that it is OK to keep the info in the session (this is not an expert's answer , I am not an expert)
One might think that this info could be manipulated, but they deprecated getSessionContext() and Interface HttpSessionContext probably for this reason to keep it secure.
Any other ideas?
 
David O'Meara
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sounds like you should investigate FORM-based Authentication and LDAP.
(You can settle for BASIC Authentication if FORM-based is too much for your requirements) These authentication mechanisms are built into app servers and all logging in, resource security and remembering stuff is done by the server for you. This makes it decidedly easier than programming security into each page when you have a lot of pages to protect.
Regardless of the mechanism, it generally goes like this:
  • user requests a resource (servlet, JSP, static page etc)
  • servlet finds out if the person is logged in and allowed to get the resource
  • if the person is not logged in, send a username/password challenge (if they are, give them the resource)
  • server gets the username/password back and tests it
  • if it fails to authenticate the user, send a fail page
  • otherwise, add user info to the session so that the user is not asked again.


  • If you have a look at the HttpServletRequest in the Servlet API, getRemoteUser() will return the 'username' that the user logged in with, getUserPrincipal() returns a security object representing the logged in user and isUserInRole(role) is used if you are using Authorisation as well.
    Note also the place where this data is read-only, so you cannot generally create your own Authenication mechanism which plugs into these useful methods.
    Dave
     
    Corey McGlone
    Ranch Hand
    Posts: 3271
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks, David. From your description, it sounds like that's just what I was looking for.
    Corey
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!