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.
Related
I was just about to follow this tutorial:
http://eureka.ykyuen.info/2011/03/03/rails-%E2%80%93-add-custom-fields-to-devise-user-model/
But then realized that my Devise needed some customizing. I am very new to Rails, so sorry for anything in advance.
What I am doing:
I need to create a site for a Minecraft server a friend and I are making. I set up devise with no extras, just an access level (admin, moderator, developer, ranks, etc.). I am using mongoid for everything here.
What's the problem? I need to make sure that the user really owns their minecraft account! The way I want to do it: In game you type /register [email], you are sent an email with a confirmation link, you click it and done, you are now registered.
What I am asking: Can someone guide me as to: What I need to do in Java, simply what's needed to be done, not the code (in PHP I've done this before, I opened up a connection to a page, I sent username and a hash as parameters), and what must be done in Rails (Change up some views, totally redo the insides of Devise, just what's needed, and some examples). I'm quite new to rails, so please be nice to my brain! Thanks!
I understand it's a big request for help, but if you have some idea of how this can be done, please help. Thank you for reading!
Edit:
Okay... I really am getting desperate here, I will make it as simple as I can:
How do I customize Devise confirmation? I want it like this: from JAVA I can create a user (with only his username and email) who can't log in because he hasn't confirmed yet. When the site gets this request to make an account, I want to dispatch an email with mailer with a confirmation link. From there, instead of just going ahead and verifying, I need them to type their password and reconfirm it, because remember: the account was created without the password, only username and email! After they fill in the form, their account is active!
Please help, I need this done quickly, my app is quickly growing and it will be a hassle to change this all. Until someone can help me, to make things better in user I am using a method to get what display name I want them to use, right now it's set to email, after someone helps me I can finally make it username!
Thank you for reading, please reply if you know the answer or upvote so someone can provide a good answer!
(Assuming that you already added the username field to the User model created by Devise)
What I would do:
Create a simple form, no Devise at all, just a standard form that takes the username and the email.
Email the user. This email will have the Devise form and/or a confirmation link.
If placing the Devise form in the mail is not possible, have it displayed in the page linked by the confirmation email. Of course, you can now auto-complete all the fields except for the password.
With this approach you don't have to dig in the guts of Devise. Use it out of the box, but until the second interaction with the user.
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.
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 :)
I understand that this kind of identification cannot be 100% accurate, but example usage would be internet poll, to detect users that have already voted. Is user detection possible with browser sent details? And what kind of information I can get from browser with every request? If I add IP address or location for example town to this, then identification would be more accurate. Are there any possible downsides I should know about?
You may want to check out the research the EFF has conducted, to identify visitors using default browser-transported information - but no cookies.
Here's the link for Panopticlick.
You should not rely on such information.
As I'm sure you are aware all of this information can be easily forged. As you can specify any request header at will (the request header contains IP, location, browser etc.).
You can use it as a poll, but you should keep in mind that the poll will never be 100% accurate.
If you want to know where the user is from make him authenticate in the site with a valid e-mail and set a cookie on his browser.
Another way to check a user's identity/location is using a paid identity validation service like URU for instance. Even this however is never 100% accurate.
ip + location is not a good thing. Much of internet users are behind firewalls/NAT's/proxy's.
Your best best is long term persistent cookie.