i have a very simple question
I m using State Server for storing Session in my application. The problem is that, when i hit my site and login in my site and after i login if i close my browser and reopen again thne my session is lost. I have to login in again. What is minimum do i have to do for making session alive even aftre closing browser.
My state server configuratin is below
<sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424" />
and in my globel.aspx file on sesion_start i m doing this
// set the session timeout 20Minutes
Session.Timeout = ConfigurationManager.AppSettings["SessionTimeOutTimeInMinutes"].ToInt32Safe();
What is minimum do i have to do for making session alive even aftre closing browser.
Here is image of my settings on sever
ASP.NET Session state uses non-persistent session cookies that (by design) do not survive when you close your browser. If you want persistent session state you need a means of making the ASP.NET session cookie persistent.
There are some examples out there. For example:
Create Persistent ID Cookies
Persisting Session Between Different Browser Instances
This SO question has some useful comments and links too
Related
I'm a beginner in ASP.NET and just a question on session state. I was reading a textbook which says:
the session state will be lost if the user closes and restarts the browser and the session actually remains in memory on the web server, because ASP.NET has no idea that the client has closed the browser or changed windows. The session will linger in memory, remaining inaccessible, until it eventually expires
I don't quite understand what does "remaining inaccessible" mean, because a cookie called "ASP.NET_SessionId" will be created for the first time when the session collection is used on client's machine, so even when the users close and then restart their browsers and access the page again, so the cookie contains session id will still get sent to the server, if the session still remains in memory on the web server, why it is inaccessible?
ASP.NET_SessionId cookie is created as "session cookie" (not "persistent" one - How do I create a persistent vs a non-persistent cookie?) and when browser closes completely (rarely happens now days) browser will drop all "session" cookies. Since value of the cookie is cryptographically secure random number there is no practical way to reconstruct the value of the cookie and hence retrieve value of old session from the server. Data associated with the value of the cookie will sit in server's memory (or SQL if you use SQL session state) but there will be no requests that can ask for it. Eventually the data will be cleaned when server side expiration happen (or server IIS process shuts down in case of in-memory session state).
Note that most modern browsers don't actually "close session" when you close all instances so you rarely see such case in practice. You can always "clear all cookies" to see it happening.
First of all, I'm new to MVC, but I managed to create a simple custom login using Entity Framework, MVC 5 and C#. ( I do not want to use Identity because the idea is to get to know the functions behind it).
I'm currently doing this with Session Variables, so when the user exist in the DB, I store the info like Role, Name, etc. in Session Variables, but when the user closes the browser or I restart the app the session is lost so the user has to login again, how can I prevent that from happening and keep the user logged like Identity does?
There seems to be some confusion about how authentication and sessions actually work here.
First, sessions utilize cookies. That's how they work. A cookie is set with the session identifier so that the server can retrieve the appropriate session with each subsequent request. The only alternative is what's referred to as "cookie-less sessions", where the session identifier is passed around as a query string parameter. However, these are generally discouraged because inevitably the URL leaks and its far too easy to hijack user sessions this way.
Second, sessions on the server are not the same thing as a browser "session". The server-side session does not expire when you close your browser. That's just patently false. You can however, have the cookie containing the session identifier be set as a "session cookie", which causes the cookie itself to expire when the browser session ends. The server session still exists, only without the cookie, there's no way to look it up. However, you can just as easily have the cookie expire after a period of days or weeks. The fact that it's a cookie used to maintain a session doesn't necessitate that it be a "session cookie".
Third, there's different mechanisms of session storage. The default, because it requires no configuration, is what's called "in-proc". That means the session data is stored in memory by the web server process. When the web server process is terminated, its memory block is freed, along with your session data. Persistent sessions require persistent storage, meaning something like a database.
Long and short, there's nothing wrong with what you're doing, you just don't have your sessions configured properly. Refer to the MSDN docs on the <sessionState> Web.config element. You'll need to add something similar to:
<sessionState mode="SQLServer"
cookieless="false"
timeout="3600"
sqlConnectionString="[Connection String Here]" />
I ask to my friend, where is session stored? At Server or Browser?
He said, at the server.
Then I said "I think things saved at server called cache".
Then, I go to google search reading article, but I found no specific correct answer, at MSDN too, no specific answer.
Usually it is saved in the server's memory, but you can also have a database backed cache. It is never cached on the client, since it can contain information that shouldn't be available to the user, like the password to your database.
The full list of places where you can save the session state can be found on MSDN:
InProc mode, which stores session state in memory on the Web server. This is the default.
StateServer mode, which stores session state in a separate process called the ASP.NET state service. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
SQLServer mode stores session state in a SQL Server database. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
Custom mode, which enables you to specify a custom storage provider.
Off mode, which disables session state.
Session itself is stored on the server side.Each browser accessing the server will get from the server unique Session ID. This Session ID browser sends to each page requested to the same server.
Session
So on client (browser) side, only Session ID is stored in the browser cookie.
(this is default behavior, when session cookies are enabled in the browser settings... there is also a technique called "URL rewriting" to embed Session ID as URL query parameter, each time the server is called, enabling the application to work even if browser session cookies are disabled)
For more information go through this http://ejvyas.blogspot.in/2010/02/where-is-stored-is-it-in-browser-or-at.html
Quick answer: on both sides.
Previously, the session was stored on a server side. This approach implies that you have to go to a server side each time you create or validate session. The session also have to be replicated for all the web-servers. These things can sufficiently harm the performance.
The another one oldschool way to store the session data as a cookie (as it is mentioned in answers). The obvious flow is that cookies has 4kb limit.
In order to overcome it, the World Wide Web Consortium defined the client side sessionStorage, that can be instantly added or validated and does not demand to replicate the data between web-servers.
It can be seen in browser's Dev Tools / Application tab. For example, this is how the session for my Facebook page looks like:
I have an asp.net application in which i redirect from one page to another. I'm validating the SessionID in the second page to make sure both requests are of the same session. Now, my problem is the SessionID changes whenever a Postback is happened.
Now, I added the Session tag into my web.config
<sessionState mode="InProc" cookieless="true"/>
Now, the problem with the session was solved and a new issue started appearing. Whenever i make a call with Cookiless="true" in my web.config file, my URL shows a junk address
http://localhost:10766/(S(ojbcobj0aw0wiosttgpknwby))/registration.aspx
If I remove the Cookieless tag the session will be lost in the next page?
Do anyone know why is this coming and if any fix is there for this problem?
I went through lot of threads but i couldn't find a proper fix for this.
EDITED:
I Set my cookieless="false" and now its working fine.
.NET Framework has 05 (five) session state modes:
InProc mode, which stores session state in memory on the Web server. This is the default.
StateServer mode, which stores session state in a separate process called the ASP.NET state service. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
SQLServer mode stores session state in a SQL Server database. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
Custom mode, which enables you to specify a custom storage provider.
Off mode, which disables session state.
Now i need to know exactly what does your application do to recommend the better solution:
Do you store something in Session?
Are you using multithreading?
How many servers your farm will have (when the application go live)
Does your app connect to database?
If you keep your original web.config, by default your application will use InProc mode and will store session id on cookie, unless your browser or local server denied it.
I'm waiting to the answers to complement my post.
Reference:
http://msdn.microsoft.com/en-us/library/ms178586.ASPX
I am developing and intranet web application. In Global.asax file's session_start event I get the domain identity using user.idenity and put it into session value. Now I have a master page where I am accession that session value to show the user name.
I am using windows authentication and identity impersonation true. But after publishing it the user name who first logins in the system gets displayed to everyone.
I am not able to find out the cause. Please suggest.
It's hard to determine the problem without some sample code, but I can guess what's happening.
Are you understanding that opening a new Web browser tab, or just opening the same URL in the same tab may start a new session?
Session state is persisted as a cookie in the client-side (Web browser) and any tab or window within the same browser session (that would end if you close and re-open the browser) shares it. In other words: all tabs or same browser session windows will share the same session state in the server-side.