I'm using Struts 2 in my web application. My client is asking me to implement "Remember Me" feature, so that he doesn't have to login again. This is what I think should be done:
I should create a cookie with some user-specific key and store the same in database on user login if "Remember me" option is checked.
I should write an interceptor, that takes out cookies from the request, checks the key against the database and if found and not expired (7 days), it puts the corresponding user in session.
Is there any other, more effective & easy & better, performance-wise method?
Your approach is correct and this link will help you to implement it in a more effective way :)
Related
I'm making an online multiplayer chess game using java servlet in the back-end. In
the front-end I'm using JavaScript, Ajax, Html. Client\Player request is sent through ajax request to the servlet controller. Now, I want to know which is the best option for handling a client request\state. I don't want to use cookies. I know URL rewriting is an option for managing client session. Apart from these, what are the other efficient approach for managing client sessions? Is HttpSession Object is a good option for uniquely identifying client sessions?
HttpSession in turn uses cookie to identify session (JSESSIONID) , it will be automatically setup when session is created
If you really don't want to use cookies , then go for Token Based Authentication , there are lot of tutorials available online, but it need a little more work for token management. This is been used widely now
Update
quick search on token based authentication on google gives this,
https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/
http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html
http://www.javabydefault.com/2014/11/implementing-token-based-authentication.html
yes using sessionId will be good option for you you can get the seesionis by using the following code session.getId()
If you are not concerned about security, you need not worry about 'authentication' mechanisms.
For example, if you just want to differentiate between two clients, you can simply add an extra parameter like clientId in each of your requests.
It can work like this:
Create one global variable in javascript like globalClientId =
null;
At the time of each request, send this as an extra parameter
If globalClientId is null, generate a 16-digit random number and
store it (this will be done only on first time per page)
However, some disadvantages of this method compared to Cookies are:
It works only for one tab
It will be lost if that tab is closed
I need to implement captcha functionality like in Gmail.
If the user has requested first time, no captcha image will be shown.
But, if user is requesting second time to login, (User has entered wrong password first time) need to show the captcha.
Please let me know how to check if the request has come from the same user so that I can implement some business logic in my spring classes.
Why are you trying to tie up login attempts to concrete user? If I'm a malefactor and I want to guess the password, I'll use the bruteforcer which can use proxies.
Each time I'll have new IP, so your captcha will not work for me.
In my opinion the better solution is to store counter of incorrect login attempts. Each time anybody inputs wrong password for particular login-name, you increase the counter value for this login. If password is correct, you set this value to 0. If counter value more than 0, you'll show your captcha.
Attach the counter to the HTTP session. You may required to store the session on the server side, and in a distributed ENV, you should SYNC the HTTP session across servers. You can also store that info into Client side cookies.
At server side(servlet) create HttpSession
HttpSession session = request.getHttpSession();
and keep count of hit inside this session
session.setAttribute("count",i); //you can use getAttribute() method to check the count.
There are a couple of ways to do that:
When the page is first loaded, start a session (or send out a coookie). Use a count against the session/cookie. You can spit out a captcha once you find the cookie for the second time.
Use hidden form fields. Put a special name/value pair that you can identify on the second request and send a Captcha across.
Use AJAX! This would involve using an XMLhttprequest to submit your form, if invalid, you can show a captcha! This would probably give you more control, but at the expense of re-working a bit.
The last two bullets are assuming you want captcha on wrong passwords rather than on a different request/page-reload.
Every one of the above methods has its own pros and cons. You need to choose one or a combination or more than one according to your need.
Assume I have a single servlet in a web app, and all users need to be logged in before they can do anything. So in the get and post methods there is an if block to test if the user is logged by trying to extract a session attribute in to process request, and else to redirect to login page if not logged in.
Given this scenario, is there a way an intruder can manipulate the system to gain entry without knowing the password? Assume the password is hard-coded into the servlet. If yes, where would he start?
I would look at http://docs.oracle.com/javaee/5/tutorial/doc/bncbe.html#bncbj and the section linked from that section about specifying authentication mechanisms.
See also (on Stackoverflow) Looking for a simple, secure session design with servlets and JSP and How do servlets work? Instantiation, sessions, shared variables and multithreading
In short, you don't need to do much yourself about checking for a session attribute if you use the mechanisms described on those pages. Your login form can be used in the 'form-login' configuration requiring authentication.
The key of security is around your comment extract a session attribute -- how are you doing this? Are they sending you a query string param? Are they sending you credentials in the method headers?
To #Hogan's point, unless this is over HTTPS the answer is: "No, it is not secure. A man-in-the-middle (MITM) can get the password from your submission and simply re-use it to mask its own nefarious requests".
If the communication IS done over HTTPS, then you should be fine. Having a single hard-coded password is fine, but consider the case where the password gets compromised; now every single client/user/etc. has to change their code.
A better design is to issue clients a key they can send along with their requests that you can use to identify who they are and if a key gets compromise, re-issue a new one to that user/client/etc.
This assumes traffic is over HTTPS
If traffic is not, a lot of this breaks down and you need to look at things like HMAC's. I wrote this article on designing secure APIs -- it should give you a good introduction to how all this nightmare of security works.
If your eyes are rolling into the back of your head and you are thinking "My god, I just wanted a YES/NO", then my recommendation is:
Require all traffic to be over HTTPS
Issue individual passwords to each client so if one gets compromised, every single one isn't compromised.
That should get you pretty far down the road.
Hope that help. This topic is super hairy and I know you didn't want a history lesson and just want to solve this question and move forward. Hope I gave you enough to do that.
Hi i'm working on play20 framework with java application.For that
i want to implement "remember me" functionality like gmail or facebook
without cookies . i don't know how to start .Can any one help me in
that ?
Thank you in Advance.
Why do you want it without cookies? If you'll remove all google.* cookies it will not remember you as well.
Of course you do not need to store credentials in the cookies to keep the user logged in. Most probably you need to save some kind of ID in the database for each logged user and then store this ID as a cookie. When user comes back you have to check if stored cookie fits any of the user and if it do, just consider the user is logged in.
Of course to avoid brute force attempts you should also create additional validation cookie(s) and each time check if sets of cookies matches each other with server-side comparison.
I think you definitely need cookies. However RememberMe isn't so trivial as it's looks. I implement one for permsec in play2.0. After finish it, I found this article, which shows a lot of problems with stolen cookies.
I don't think it is possible without using cookies. If you want to implement this functionality with cookies, when user clicks "remember me" just let the expire date be in a distant future.
I have a situation where ideally I want to be able to log-in to a secure area using a Java application.
I would like to make an HTTP request and check the response to see if I need to do some kind of authenication before I can actually get the response expected, instead of effectively some login page. The complication is that the server that responds will not always be the same - the user of the Java app specifies the URL - and the server may be using some kind of single sign on authentication or the web container's.
I don't know the field names for the username and password fields or the action of the form, is there a simple way to obtain this kind of information from the URL?
I see the URLConnection object has methods getPermission() which has a method getActions() but are not suitable, anything that might be?
I guess example things I am looking to determine:
Does the response require authentication?
If so; what type / which servlet? e.g. j_security_check, josso single sign on, ...
And then some way of authenticating the client
And finally managing the state of the authenticated user for other requests
Do I need to know the attributes of the login form before attemping to login? And then, is the onoly way of verifying permission to the requested resource to manually manage the cookies?
Thanks in advance.
What I did in the end was sent a request to a page, checked for a login form (a form which has two visible fields, one of which is of type password) and obtained the form field names from that.
Posted the values back (along with hidden values and JSession cookies) and saved the cookies returned by the server. This works! And then as long as I send, with every request, those cookies, I can access sercured pages.
Thanks.
Also - why is my reputation score around 100 less than when I last logged in, despite not getting down voted on anything??
It sounds as if you are trying to create an SSO process in the client. I don't fully understand your design here, but when I see clients that are effectively allowing the user through to the server they usually just provide a checkbox "requires authentication" if the user clicks yes then he/she would fill out username/password fields. You will need to know before hand what the server is expecting so you can code in the required fields. I don't believe there is any Universal method of authenticating to an unknown service. If there were we probably would have solved SSO a long time ago. There are a huge number of authentication methods, many of which are custom. So, how could something determine what fields and such a server requires in order to authenticate?
I think if you are asking your users to provide an URL then you by definition require them to know something about how to authenticate to the server. Assumptions could be made, say, if the URL were svn:// or ldap:// or the like...
If you are providing the user with some enumerated set of services to choose from, say in a drop down, then you have the control to try and abstract the interface and hide the authentication details from them.