So, my web application has been authenticating by user identity only. But I just receive a dll which required the user to login to get token, then use the token to call other functions in dll. So, what's the best choice for saving the token? After looking around, this seem like a session thing but they may need to use it for a few hours, would session end if they keep the page open?
Why not save/store the token in cookie (client machine). Then for every dll call pass that token along with the call. You can as well set the expiry of the cookie.
Yes You can as well store it in session and can set the session timeout (default is 20 minutes if not wrong)
Related
In a sample/default MVC 4 project, I can see that when the User logs in with Remember Me checkbox on, the persistCookie parameter of the WebSecurity.Login method is set to true.
How exactly does that work? Where exactly is the value of persistCookie is saved? I looked through the tables that are created for the Security feature and do not see anywhere that the user is set to persist login.
What mechanism enables the user to log in? Is it simply the presence of the .ASPXAUTH cookie? Or does it actually compare the cookie value to something that I am not seeing.
How exactly does that work?
By creating a persistent cookie.
Where exactly is the value of persistCookie is saved?
As a file on the client machine so that it survives browser restarts.
What mechanism enables the user to log in?
This mechanism is called persistent cookie. A cookie is considered persistent if when being set the Expires property is being set to some date in the future. In this case the browser will store the cookie on the client computer as a file instead of keeping it in memory.
Here's an example of how creating a persistent cookie looks like in terms of the HTTP protocol:
Set-Cookie: CookieName=CookieValue;Path=/;Expires=Wed, 12-Oct-2016 21:47:09 GMT;
And here's how a setting a session cookie looks like which will not survive browser restarts:
Set-Cookie: CookieName=CookieValue;Path=/;
Now go ahead, download Fiddler and inspect the network traffic to see the difference.
The identity is stored in the cookie and decrypted upon each request.
Persistent cookie means that the cookie will be automatically attached to requests by the browser for some period of time.
No magic and also no need to store open sessions at the server side. As long as a cookie decrypts correctly, it is accepted as the server assumes that no one is able to forge a cookie on its own. This requires that the cookie value is encrypted or at least signed.
We have a website that has a 20 minute session timeout and our users want a 10 minute session expiry warning. At the moment we're using a control which kinda does the job but it isn't AJAX aware and so pops up even if the user has been doing stuff.
I have an idea to get around this by just polling the server every 2 minutes to find out how long the user has left on their session. But after research i can not find out if its possible to say "This request shouldn't refresh the timeout", which is crucial as the act of polling would inadvertently refresh the session timeout.
Is this possible, or am I going about it the wrong way?
I think the only reliable way you can do this is to modify your ajax javascript to extend the timeout on your existing script.
You could use the disable session state for a page then modify your app to store the last access time for a user in the db. poll the session-less page to find out when the user last did something.
Either way you'll have to make extensive changes across your app.
If your session has a fixed 20 minute expiry, then it won't get extended by refreshing a page. However, if you want to have a script on your page to alert users of their imminent session expiry, then you'll need to set a client side script (presume Javascript) and kick it off on page load?
<script type="text/javascript">
function alertSessionTimeout(){ alert("Your session is about to expire. Please refresh the page.") }
window.setTimeout('alertSessionTimeout', 10*60*1000);
</script>
what about TWO web applications accessing the same database? in the first, the main, application you write last access time to database, and the second application is polled via ajax to get inactive time base on last access time...
In polling the server you see how long is left you would be resetting it back to 20 minutes. You would need to make sure the request does not attach the session cookie to prevent this. In doing so you create another problem in that you can't access the user session.
An alternative is just do in JavaScript page load using SetTimeout.
It seems that some people are confusing Session state with Forms Authentication ticket expiration. Session state has an automatic sliding expiration - if session is set for 20 minutes and after 19 minutes of talking to your friend in the office, you request a page, you get another 20 minutes.
This is an old question, but I have a similar problem and had this idea for a solution.
Upon each page request that uses the session, your session gets refreshed. Into the application cache, put key=sessionId and value=DateTime.Now.
Create a web service (.ashx or what have you) that does NOT use session state, but ideally is authenticated using Forms Authentication or some other authentication scheme. Your javascript, which is counting down the time until session expiration, will call this web service shortly before the session expires to see if the session is really going to expire.
I'm thinking the web service should return something simple like a 2 if the session is expired, 1 if the session is about to expire, or 0 if not. Return random [0,1,2] if the service is called by a user with an unknown or invalid SessionId cookie -- this would hopefully prevent valid sessionId discovery by an attacker who gets a Forms Auth cookie.
I investigated decompiling the built-in SessionProvider to see if I could access the session to discover the expiration without triggering a refresh. But doing so is dependent on the type of session provider being used, so if you ever move from, say, SQL Server session provider to Redis, you have to rewrite it.
I would like to know can we delete cookie from cookies collection what we have created in asp.net website.I tried & find Expiration Logic.It works but it shows in browser cookie.
Response.Cookies["UserID"].Expires = DateTime.Now.AddDays(-1);
Is there any other way by this we can delete cookies from collection so it will not show in browser cookies.
Please help me to solve the issue.Thanks in advance.
From the documentation:
You cannot directly delete a cookie on
a user's computer. However, you can
direct the user's browser to delete
the cookie by setting the cookie's
expiration date to a past date. The
next time a user makes a request to a
page within the domain or path that
set the cookie, the browser will
determine that the cookie has expired
and remove it.
So, your strategy is the right one, and the cookie should disappear from the browser once the response is received.
I'm not sure you can delete the cookie since you don't have access to delete anything on the client computer. All you can do is basically what you are doing, that is invalidating the cookie for your application. I think it is up to the client software to decide if the cookie should be deleted or not, all you can do is set the timestamp as you are doing and that means that you will no longer accept that cookie.
Guys, I am trying to make a website that keeps a cookie active, so long as the user is active in the site. My idea was to create a cookie on the main page of the site, like so:
HttpCookie cookie = new HttpCookie("KeepAlive","1");
cookie.Expires = DateTime.Now.AddMinutes(20);
Request.Cookies.Add(cookie);
If I have this code in my Page_Load event on every page, this should keep refreshing the cookie. If, after 20 minutes, the cookie expires, it will kick them back to the main screen. I just want to make sure I am going about this the right way.
Thanks
I think you should look at using session for that. With Session, you can set a timeout (20 minutes by default), and the rest will occur automatically (updating the active status, etc).
EDIT (more on Session):
By using session, the site user can be identified throughout their experience. This happens automatically, without any need for the developer to code for it or to test that it works.
Session is stored on the server, and is therefore safer (users can modify their cookies)
You can run code at the start, or at the end of any session (using a global.asax file)
Sessions can be setup as cookieless (users may have cookies disabled)
You can store c# objects in session variables so that they are available through the active session (stored in server memory).
I can't think of any more advantages in this case. I invite others to leave comments with their thoughts.
If you really want to use cookies for this, Yes, You are going the right way.
You need to add the cookie to the Response object, not the Request object.
What is the difference between a Session and a Cookie?
What circumstances should each be used?
Sessions
Sessions are stored per-user in memory(or an alternative Session-State) on the server. Sessions use a cookie(session key) to tie the user to the session. This means no "sensitive" data is stored in the cookie on the users machine.
Sessions are generally used to maintain state when you navigate through a website. However, they can also be used to hold commonly accessed objects. Only if the Session-state is set to InProc, if set to another Session-State mode the object must also serializable.
Session["userName"] = "EvilBoy";
if(Session["userName"] != null)
lblUserName.Text = Session["userName"].ToString();
Cookies
Cookies are stored per-user on the users machine. A cookie is usually just a bit of information. Cookies are usually used for simple user settings colours preferences ect. No sensitive information should ever be stored in a cookie.
You can never fully trust that a cookie has not been tampered with by a user or outside source however if security is a big concern and you must use cookies then you can either encrypt your cookies or set them to only be transmitted over SSL. A user can clear his cookies at any time or not allow cookies altogether so you cannot count on them being there just because a user has visited your site in the past.
//add a username Cookie
Response.Cookies["userName"].Value = "EvilBoy";
Response.Cookies["userName"].Expires = DateTime.Now.AddDays(10);
//Can Limit a cookie to a certain Domain
Response.Cookies["userName"].Domain = "Stackoverflow.com";
//request a username cookie
if(Request.Cookies["userName"] != null)
lblUserName.Text = Server.HtmlEncode(Request.Cookies["userName"].Value);
sidenote
It is worth mentioning that ASP.NET also supports cookieless state-management
Cookie is a client side storage of your variables. It stored on client machine by browser physically. It's scope is machine wide. Different users at same machine can read same cookie.
Because of this :
You should not store sensitive data on cookie.
You should not store data that belongs to one user account.
Cookie has no effect on server resources.
Cookie expires at specified date by you.
Session is a server side storage of your variables. Default, it stored on server's memory. But you can configure it to store at SqlServer. It's scope is browser wide. Same user can run two or more browsers and each browser has it's own session.
Because of this :
You can save sensitive data in session.
You should not save everything in session. it's waste of server resources.
After user closes browser, session timeout clears all information. (default is 20 minutes)
A cookie is an identifaction string stored by a server (who has a domain) in the browser of the user who visits the server/domain.
A session is a unit of maybe variables, state, settings while a certain user is accessing a server/domain in a specific time frame. All the session information is in the traditional model stored on the server (!)
Because many concurrent users can visit a server/domain at the same time the server needs to be able to distinguish many different concurrent sessions and always assign the right session to the right user. (And no user may "steal" another uses's session)
This is done through the cookie. The cookie which is stored in the browser and which should in this case be a random combination like s73jsd74df4fdf (so it cannot be guessed) is sent on each request from the browser to the server, and the server can assign and use the correct session for its answers (page views)
The cookie allows the server to recognize the browser/user. The session allows the server to remember information between different page views.
Sessions are not reliant on the user allowing a cookie. They work instead like a token allowing access and passing information while the user has their browser open. The problem with sessions is that when you close your browser you also lose the session. So, if you had a site requiring a login, this couldn't be saved as a session like it could as a cookie, and the user would be forced to re-login every time they visit.
Its possible to have both: a database primary key is hashed and stored in a lookup table: then the hash is stored on the client as a cookie. Once the hash cookie (hahhahaha :) is submitted, its corresponding primary key is looked up, and the rest of the details are associated with it in another table on the server database.
The main difference between cookies and sessions is that cookies are stored in the user's browser, and sessions are not. This difference determines what each is best used for.
A cookie can keep information in the user's browser until deleted. If a person has a login and password, this can be set as a cookie in their browser so they do not have to re-login to your website every time they visit. You can store almost anything in a browser cookie.
Session is a server side object,
which transfer or access data between page call.
Cookies is a object which is client side/client machine which store some text information of browser and server.
There appears to be some confusion regarding what a session cookie is.
Firstly, when we are talking session cookies - it has nothing to do with ASP.Net sessions. Likewise, session cookies have nothing to do with server side processes or caching.
A session cookie is nothing more than a cookie that expires when the browser session expires. To create a session cookie - don't put an expiration date on it. Doing this stores the cookie in memory and is disposed of when the browser is disposed.