I need to save login/password for my authenticated user. It seems that LoginForm component is deprecated. How else can i make the client's browser to save entered login & password? Can the SubmintButton class help me somehow?
Thank you.
I would suggest to use cookies and implement a remember me function.
That means more or less, you create a cookie with a unique identifier of the user (never! store the user credentials in the cookie). This unique identifier is also stored in your application and should usually have lease time, which expires after a certain time, for security reasons. Every time the user enters your application, the system checks if the cookie still exists and is valid, if so go directly to the application, if not go to the login form.
Perhaps the following link gives you an idea:
http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/
The only way I know is to use cookies. I use for this purpose Spring Security with remember me functionality.
https://docs.spring.io/spring-security/site/docs/current/reference/html/remember-me.html
The LoginForm in the core indeed is currently deprecated as it is incompatible with most modern browsers. There is a patch in review to fix this issue, but in the mean time you can use an excellent add-on from the Directory called LoginForm.
Related
I am using this answer here to log unique page views in my app: https://stackoverflow.com/a/15174466/1235816
I am using a cookie to check for unique visits. As far as I am aware, because the site will be hosted in the UK, I should have a message which asks the user to accept cookies or if they don't... it asks them to leave the site.
I want it to work like this... If a user wishes to accept cookies, then the 'app-name-visited' cookie should then be downloaded, otherwise if they just exit the site without clicking accept, no cookies are downloaded to the clients machine...
Is this:
1/. a correct way of thinking?
2/. possible?
The cookie law has since been modified, so this is not quite necessary any more, you only need to let the user know that they you will be using cookies.
The organisation that enforces this is the ico, which doesn't ask for permission for cookies on their site:
http://www.ico.org.uk/
Suggest you follow this pragmatic approach.
If you are wanting to comply as per your question I did some work on this a while back for rails projects which should be a decent starting point:
https://github.com/yule/threepwood
In may Rails web application, I need to enable more control in user authentication like if a user after registration will have specific credentials to login. So he/she should be able to login from a particular system(PC) only. This can prevent other users from logging in even if they know the particular users' credentials. Can we use Cookies for this purpose? Will Cookie always be unique if we access a particular web app from a particular PC? Help me to have a better solution.
Thanks in adv :)-
In my opinion, use cookies with caution, when you have no other options.
In this particular case (i.e. identify a unic computer), I think you can identify it by 2 solutions :
A stupid cookie with a value you know. The problem of a cookie is that a user can simply copy/paste the cookie value to another computer to have same access.
A unic key computed from computer data. You can create it with some accessible informations from this computer : browser, browser plugins, browser version, operating system, etc. This key can now be stored as a cookie. You have to check if this key is valid, regarding your identification function. Copy past have no effect because source informations are not the same. The main problem of this solution is it's 'too' secure : if the user change its browser, add a plugin, change its browser version, the function to compute key will not work at all.
This is the second solution I use, with this informations for example Rails Browser Detection Methods or https://github.com/josh/useragent
You can store secuirity token (md5 hash or something else) in the cookie, and check it for access.
I've got a ASP.NET MVC web app which uses forms authentication.
I'm using ActiveDirectoryMembershipProvider to validate users against our domain.
if (Membership.ValidateUser(m.Username, m.Password))
{
FormsAuthentication.SetAuthCookie(m.Username, true);
....
This means the user gets validated only when they log in.
Problem with that is ofcourse that if the user's password changes they still remain logged in. Or worse, user leaves our company with a grudge, and they still have access.
I would have thought such a simple use case would have an obvious answer but I've been stuck on this for a while now.
I could put the users password in the session and then validate it every time, but that doesn't feel right.
What is the suggested/correct way of handling this?
The typical solution is to force log out when users unsubscribes from the service or less commonly when they change password. Use this method:
FormsAuthentication.SignOut();
FormsAuthentication.RedirectToLoginPage();
If the user can be deactivated outside of the app (i.e. Active Directory), the typical practice is to rely on the session time-out and perhaps ask for the credentials once more for critical operations. If you absolutely cannot allow the deactivated user to work while the session is still active, then yes, you'll have to check the credentials on every request. Since storing the password in the app is a very bad idea, it means you'll have to ask for credentials on each request which arguably is an even worse idea.
As for the password change, it normally doesn't modify the user's permissions so it should be harmless to allow for them to continue working.
The answer is to periodically (every 30 minutes or so) check User.IsApproved and User.LastPasswordChangedDate to make sure the users credentials are still valid.
To do this you need to manually create the FormsAuthenticationTicket and cookie, rather than using FormsAuthentication.SetAuthCookie.
Put the date you validated the user inside UserData and compare this against LastPasswordChangedDate.
I've implemented this and it works perfectly.
More information here
Check if Active Directory password is different from cookie
Scenario:
Upon starting a session on my site, I generate a rand token that is shown to the user that once. Say they “store” it away for later use.
I then, INSERT the md5(token) into SQL with timestamp.
When the user visits other pages like login, they would have to pass the token via URL as part of the validation process. I would check to see if the token exist and maybe UPDATE userid to this token.
So. Even if someone steals a user’s PHPSESSID cookie, wouldn’t it do ANY good to the hacker since they can’t access any of these pages without knowing the token?
You are right that they won't be able to access the pages without the token, but as an added point, sometimes I'd like to use IP tracking or browser tracking used concurrently as well.
The rationale being that even if someone gets a PHPSESSID cookie and the token, he would have to be coming from the same IP source as well as use the same browser. Then again these are just means of security by obscurity.
I recommend if you are really concerned about security, you can try looking at using a HTTPS connection. Hope it helped. Cheers!
We are attempting to integrate an ASP.NET MVC site with our client's SSO system using PingFederate. I would like to use the built in FormsAuthentication framework to do this. The way I've gone about it so far is:
Set up my Web.config so that my FormsAuthentication LoginURL goes to my site's "BeginAuthentication" action on a "Security" controller. From this action, I set up some session variables (what URL was being accessed, for example, since Ping won't send this info back to me), and then redirect to our client's login page on an external site (www.client.com/Login for example).
From here, the authentication takes place and a cookie is generated on the same domain as the one that our application is running on which contains the unique identifier of the authenticated user, I've set it up so that once this happens, the Ping server will redirect to my "EndAuthentication" action on my "Security" controller.
In this action, I call my membership class's "ValidateUser" method which takes this unique identifier from the cookie and loads in the user on our application that this ID refers to. I save that logged in user in our Session (Session["LoggedInAs"], for example) and expire the cookie that contains the id of the authenticated user that the SSO system provided for me.
All of this works well. The issue I'm wondering about is what happens after our user has already authenticated and manually goes back to our client's login page (www.client.com/login) and logs in as another user. If they do that, then the flow from #2 above to number 3 happens as normal - but since there already exists an authenticated user on our site, it seems as though the FormsAuthentication system doesn't bother kicking off anything so I don't get a chance to check for the cookie I'm looking for to login as this new user. What I'd like to do is, somewhere in my Global.asax file (probably FormsAuthenticate_OnAuthenticate), check to see if the cookie that the SSO system sends to me exists, and if so, sign out of the application using FormsAuthentication.SignOut().
Another issue that seems to be related is that if I let my Session expire, the FormsAuthentication still seems to think I am authenticated and it lets me access a page even though no currently logged in user exists in my Session, so the page doesn't render correctly. Should I tap into the Session_End event and do FormsAuthentication.SignOut() here as well?
Basically, I want to know when the authentication ticket created by
System.Web.Security.FormsAuthentication.SetAuthCookie(..) gets checked in the flow of a request so that I can determine whether I need to SignOut() and force revalidation or not.
Thanks for any help. Sorry for the length of this message, trying to be as detailed as possible.
Mustafa
Welcome to the small section of Hades that is mixing session with formsauth.
If your needs are as complex as presented, you would get more sleep if you implement a full provider stack to share amongst the participating sites. Easier said than done, I know.
But to address your question:
from http://www.codeproject.com/Articles/39026/Exploring-Web-config-system-web-httpModules.aspx
On the way in....Check ticket and set identity #
app.AuthenticateRequest += System.Web.Security.FormsAuthenticationModule.OnEnter-->OnAuthenticate
On the way out... set the ticket and redirect as necessary
app.EndRequest += System.Web.Security.FormsAuthenticationModule.OnLeave
Reflector is your friend. ;-)
I don't know about a specific event for when the cookie is checked, but you could place the appropriate logic in Application_BeginRequest() and check the user's authentication state there.
Another issue that seems to be related
is that if I let my Session expire,
the FormsAuthentication still seems to
think I am authenticated and it lets
me access a page even though no
currently logged in user exists in my
Session, so the page doesn't render
correctly.
The life of the cookie (how long until ASP.NET feels it needs to ask for a password again) and how you are managing state are unrelated. The ASP.NET authentication is cookie based so that, should a developer want to, he could turn off viewstate, session, use no query strings or hidden fields and authentication still works.
If you want to tie the interval at which you request the password to how you are persisting data, then you will want your session expiration to be roughly the same as the cookie expiration, but they will never quite match up. It would be better to have two policies (one for how fast you throw away a users session data and one for how long you are willing to wait before you need to reask for a password)