Is it possible to use TempData when cookies are disabled? I have a redirect check that depends on a TempData key, but when cookies are disabled, that key is always null.
TempData is a way to persist something between HTTP requests. Because HTTP is inherently stateless, you can't persist something without having a way to identify the client.
TempData uses the Session as storage, which by default uses cookies to persist a user's session between HTTP requests. A cookie is included in every request with a key to that particular user's session.
If you want TempData to work without cookies, you can set the cookieless="true" attribute of the sessionState tag in your web.config file. That appends a query string parameter to every link in your site to achieve the same result. However, it's not recommended and you will have issues if you're using MVC 4.
If you want it to work without using cookies, include a query string parameter on the target URL instead if possible.
It depends on the TempDataProvider of the Controller. the default provider is SessionStateTempDataProvider which relies on the regular Session State Storage.
That basically means that if Cookies are disabled, you won't have neither Session or TempData unless you'll implement Cookie-less Session.
Related
I'm exploring cookies and sessions [I'm using them with respect to ASP.NET C# microsoft framework]
Learnt how sessions and cookies work here and here.
My take on it is like,
Once a user logs in and establishes a session, he or she is given a session id to track them further.
Also, this sessionId can be stored on a Server, like SQL Server or a InProc, meaning it is stored on the issuing server or on a cache, Redis Cache.
My question is like,
I can understand that the sessionId is stored in a memory and being sent with every request (since HttpSessions are stateless) as HttpHeaders.
When we talk about storing sessions in a memory, which memory are we talking about ?
If we are storing them in a cookie, what If I go and modify the cookie ?
If I can modify them, what If I change the sessionId and supply in a new sessionId ?
1. When we talk about storing sessions in a memory, which memory are we talking about ?
Ans: InProc mode, which stores session state in memory on the Web server (RAM). This is the default.
2. If we are storing them in a cookie, what If I go and modify the cookie ?
Ans : Only session id is stored in cookie. If you don't want to use cookies for session tracking, asp.net framework also supports it by appending it in the URL. If you change the cookie value, the server will not be able to identify the request with the stored session data. You need to understand the http is a stateless protocol, sessionid is the identifier of a browser for the request during roundtrips. If you change the cookie value, server will not be able to identify the request.
By luck if you supply a valid sessionid, server will serve the content stored in session against that id. This is called session hijacking
https://en.wikipedia.org/wiki/Session_hijacking
3. If I can modify them, what If I change the sessionId and supply in a new sessionId ?
Ans: If you are taking about the SessionId of System.Web.SessionState. It can't be changed as it is readonly. But you are free to change anything at the client side (Cookie or URL)
Namespace: System.Web.SessionState
Assembly: System.Web (in System.Web.dll)
public string SessionID { get; }
The session data is stored on the server, either in memory or in a database. This data is looked up with a sessionId that is stored in a cookie.
2/3. Modifying the sessionId is known as session hijacking, and allows you to "be" that user. This is commonly exploited with attacks like cross-site scripting (XSS).
To protect against hijacking make sure that:
The cookie is encrypted. There are ways for ASP.NET to do this for you, but this way it cannot be tampered with
The cookie is set to HttpOnly. This ensures that the cookie can only be sent over http requests and things like javascript - and thus XSS attacks - don't have access to the cookie.
If you are using something like ASP.NET Session State, change the default name of the cookie so it is not easily recognizable
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.
I get that regular ASP finagles statefullness using viewstate, but MVC doesn't try to perpetuate the bold-faced lie of statefulness. So how is it able to maintain sessions?
By default it stores a randomly generated number in a cookie and stores that in memory. If the browser says it doesn't support cookies, asp.net will then instead add the session key in the url, it will show up like http://myurl.com/(S(rpfa4y3c5oe2c555ljanprek))/Controller/Action
It is using a Session ID to identify a user, stored in Cookies. Spoofing is possible if your know the victim's ID, and if other security measurements won't interfere (e.g IP based authentication).
well i mean, that as u will see in my posts, i am getting problems because of caches
so i think cookie less try out
how to declare a cookie less session variable without making the whole website cookie less
meaning,
website should be cookieless=FALSE
vairable cookie less true
I'm not sure exactly what you're asking, but if I parsed the question right, here are a few things that may be useful:
The values stored in the session state object are not stored in cookies -- the only cookie sent to the browser is a session identifier, which will tell the server which session state it should fetch when responding to subsequent requests. The actual session state data is stored on the server.
If your goal here is to prevent the session cookie from being sent to the browser at all, but still allow sessions to work, you can enable cookieless sessions. You can read more about that, the pros and cons as well as how to do it, on the Cookieless ASP.NET page on MSDN.
basically, if cookeis are disabled on the client, im wondering if this...
dim newCookie = New HttpCookie("cookieName", "cookieValue")
newCookie.Expires = DateTime.Now.AddDays(1)
response.cookies.add(newCookie)
notice i set a date, so it should be stored on disk, if cookies are disabled does asp.net automatically store this cookie as a session cookie (which is a cookie that lasts in browser memory until the user closes the browser, if i am not mistaken).... OR does asp.net not add the cookie at all (anywhere) in which case i would have to re-add the cookie to the collection without the date (which stores as a session cookie)... of course, this would require me doing the addition of a cookie twice... perhaps the second time unnecessarily if it is being stored in browsers memory anyway... im just trying not to store it twice as it's just bad code!! any ideas if i need to write another line or not? (which would be)...
response.cookies.add(New HttpCookie("cookieName", "cookieValue") ' session cookie in client browser memory
thanks guys
This MSDN article seems to indicate that there is no built in mechanism for compensating with the user disabling cookies. It also indicates that session state does not work without at least some level of cookies being enabled.
I thought that there was a mechanism for passing a query variable for the session id but skimming the article (quickly) I did not see this.
Hope that helps.
EDIT: It does say that you can use cookieless sessions (I thought you could). They use a separate mechanism to embed session ID in the pages and url links.
To follow up on GrayWizardx's reply, much of what was said is completely accurate.
If you are using a Cookie'd version of Session, and cookies are disabled then you are out of luck. But you have the option to have a cookieless version of the Session, which adds a string to the URL that shows the users session id. This is very ugly looking, and has always concerned me from a security perspective.
So you have three options (that I can think of off the top of my head):
1. Require cookies. This is not a bad thing, especially if your site is one that would have requiring cookies as normal.
2. Use ViewState.
3. Pass information from page to page within the URL. This, again worries me from a security perspective.