I have a ASP.NET website where after a specific user action, I have to issue a new AUTH cookie almost identical to the one the user already currently has. I'm having trouble finding out whether the current AUTH cookie is supposed to be persisted or not. Any ideas on how to do this?
If the cookie expiration isn't set, then it's session.
If you are trying to discover it's life via the browser, you can use firebug with the firecookie plugin. Or the web developer tool will also enumerate all the cookies on a page.
Any cookie that is not session will have Expires field. If you send it into feature date - you will get it "permanent" until the time expires. If you want to maintain "permanent" cookie status you would refresh it on next user login and shift it further into the future. One month is usually enough
Related
I am Creating E-Commerece Website For Kirana Using Session Of Data Table But Now I want To Use Cookie To Reduce Traffic With Cloud Is This Safe method Or not? I try to Use Cookie and pass parameter of session id to it to remove (i.e. Clear Session Variable) when Shopping is completed but it is not working still cookies are store in to the browser. Please Specify me the solution?
Cookies are delicious, nomnomnom (XD just kidding). Some clients have their cookies disabled. "Cookies CAN be used for malicious purposes though" -from http://www.allaboutcookies.org/
For me, Sessions are safer
Cookies can be edited by a user.
Sessions are strictly serve based and can be controlled on the server side.
Session is the way to go. That way you can keep information about each user in their own unique session.
I wonder how gmail/Google keeps a user logged in even across sessions. And how (e.g. cookies) and what (e.g. time) do they use to decide to re-prompt the user for the login?
The short answer is that cookies do not have to expire when you close down the broweser or the machine they are on. Depending on constraints configured in the browser, if the server sets an expiry date in the future, the browser will continue to present the cookie until that expiry time.
C.
Well cookies are stored in your local machine, you can see those in totals -content settings -cookies.You can clear the cookies as well.So your information is stored there.More over about the sessions if they have been implemented on the websites...They could be destroyed by two methods ,one is by giving the time for session to expire the another way is when you forcefully want to expire the session then session abandon method is used.You must have seen sometimes if you don't scroll through a page for some time, then its written there your session has been expired. Sessions are executed on the server side and there values can be stored on the client side in the cookies as well.
Hope it would help you to understand William
Is it possible to provide version information to go with an HTTP cookie? I have a cookie which tells the page whether or not to prompt a user for action, based on whether or not the user wants the prompt. On a version upgrade of the page, I need to prompt the user regardless. Can I integrate this into my existing cookie?
A cookie is little more than a string with an expiry time. You can encode whatever information you like into that cookie, including a number representing a version.
I have a large webform, and would like to prompt the user to login if their session expires, or have them login when they submit the form. It seems that having them login when they submit the form creates alot of challenges because they get redirected to the login page and then the postback data for the original form submission is lost.
So I'm thinking about how to prompt them to login asynchrounsly when the session expires. So that they stay on the original form page, have a panel appear telling them the session has expired and they need to login, it submits the login asynchronously, the login panel disapears, and the user is still on the original partially filled form and can submit it. Is this easily doable using the existing ASP.NET Membership controls? When they submit the form will I need to worry about the session key? I mean, I am wondering if the session key the form submits will be the original one from before the session expired which won't match the new one generated after logging in again asynchrounously(I still do not understand the details of how ASP.NET tracks authentication/session IDs).
Edit: Yes I am actually concerned about authentication expiration. The user must be authenticated for the submitted data to be considered valid.
Session expiration is different than authentication expiration - you probably need to determine which you are concerned about.
Sessions expire after 20 minutes of inactivity (by default), and will clear the Session object. When it expires, anything you stashed into Session will be gone.
[Forms] Authentication expires after 30 minutes of inactivity (by default) - though it's only updated every half-life. So, in reality - it can expire after 15 minutes of inactivity (by default). When it expires, the next request will be redirected to your login page.
Session and Authentication aren't really related - you can be an anonymous (non-authenticated) user, and still have a Session - or you can be logged-in (authenticated) but not have a Session. Your Session could expire before your authentication does, or vice-versa.
You could simply crank up the values for expiration for Session and/or Authentication. The problem with Session is that it chews server resources, and keeping Authentication is a security problem.
If you're just concerned about keeping them both alive for the duration of your form, a small bit of JavaScript that hits a server page with XmlHttpRequest or an iframe will reset the expiration for both (because of slidingExpiration).
There's other techniques as well, but it'd be helpful to better define the issue first.
Very nice response #Mark Brackett reading the OP's comment below I believe this is his end goal.
On the button / submit element you want to write a javascript method that via ajax will poll the server to see if they are still authenticated.
If they are auth'd still you want to return true and let the form do it's regular submission, if it returns false you want to not allow the form to submit. At this point you will want to use javascript to display either a "window" inside the browser (think floating div) or to pop up a true new window for them to log in (I'd recommend the first method) that this new window will allow them to login via ajax and then hide/close itself.
Then with that window gone when they click the submit button again they will be able to successfully post the form.
There are many ways of doing this: you may store a cookie on the user's computer, or you can also split the form into smaller forms (i.e.: step 1 - enter your personal information, step 2 - enter billing info, etc.).
Splitting your form makes it faster for a user to enter the data, thus reducing the chances for their session to expire.
Adding a cookie to this makes it so that the person's information is still there, even if you log in afterwards. Just make sure to unset these said cookies at the end.
I've got a site that uses Forms Authentication (with a custom membership provider, but that's not important right now). In the secure part of the website, the customer can purchase goods and pay for them via WorldPay.
Once they come back from WorldPay, if there's a link back into the secure part of the website, can I reasonably expect the forms auth ticket (stored in a session cookie) to have survived (timeout notwithstanding)?
The ticket is set thus:
FormsAuthentication.SetAuthCookie(username, false);
FormsAuthentication.RedirectFromLoginPage(username, false);
The work is part of a redevelopment, and I would rather have a quick "yes/no/maybe" answer before writing lots of code that may not be required - we do not want to have the user log back into the secure part of the site so we recreate their login based on the information returned from WorldPay. Obviously, if the user is going to be remembered, I don't have to write that code - I'm quite lazy ;-)
Thank you for any suggestions,
Mike K.
Forms Authentication uses a cookie.
A session cookie (which is stored in memory) lives as long as the session does not timeout and you do not close the browser.
You may also be able to set the life time of the cookie, then it will be written to disk, and available to all browser instances. In this case you will also be logged out if the session timesout on the server.
If you're calling
FormsAuthentication.SetAuthCookie(username, false);
then the cookie will survive for as long as the value specified in your web.config or until the user logs-out.
If you redirect them to a 3rd-party site during the course of their visit to your site, this cookie will remain. The 3rd-party site won't have access to your auth cookie.
In short, they will still be logged-in on your site when WorldPay redirects them back.
Even shorter: yes.
Hope this helps.
The other answers here seem to point out to this being a non-issue, but I thought I'd just add that if you're posting data to their gateway, any variables which start with MC_ will be returned to you on the other side. I'm not sure if this helps or not!