10

I have set simple cookies using classic asp e.g. <%response.cookies("user")="A"%>. As I read in this Q/A, such cookies just rely on domain name and nothing else.

I have tested when I stop and start SQL server in my server, the logged in users are signed out. Also I had same experience when I have upgraded SQL server from 2012 to 2014. (I don't use ASP session and only set cookie to identify users).

My exact question is what parameters has the effect on the cookies lifetime? IIS? Application pool? Domain Name? SQL SERVER? IP address? and if it depends on these factors, how should I create a cookies which just relies on URL address?

EDIT after 1 year: I don't face the same problem when I restart SQL server after 1 year that I wrote this question. I mean this was not a permanent problem. It might depended on a special error as Jeroen said in comments or a special configuration on the server. So if you want to answer this question you may just guess what was the problem and I can not test it anymore to accept an answer as the exact answer to this question. With regards.

Ali Sheikhpour
  • 10,475
  • 5
  • 41
  • 82
  • Curious...to know the answers – Shakeer Mirza Jun 17 '18 at 15:55
  • 4
    Are you perhaps also using SQL Server tempdb for session state? In that case all sessions will be lost when SQL Server is restarted. – Dan Guzman Jun 17 '18 at 15:59
  • No. I don't know what is `SQL Server tempdb`. I just use `response.cookies` to save username in a cookie and later I read cookie to load some data of user from database again. @DanGuzman – Ali Sheikhpour Jun 17 '18 at 16:01
  • Maybe the transaction is never committed? At restart it gets rolled back and the data inserted is gone. – sticky bit Jun 17 '18 at 18:24
  • There is no data loss in database. Users can login again after sql server restarts. @stickybit – Ali Sheikhpour Jun 17 '18 at 20:15
  • 2
    Hypothesis: this is specific to your ASP application. When SQL Server is restarted, it encounters an error somewhere that causes the app pool to be recycled. Alternatively, the SQL Server restart causes a temporary memory or CPU spike that triggers IIS to do a recycle. You can check for app pool recycle events in the event log. In any case, there is no direct relationship between SQL Server and IIS session state, unless of course you've explicitly configured session state to be stored in the database (per Dan). – Jeroen Mostert Jun 18 '18 at 15:13
  • So you say that the lifetime of cookie created by `response.cookies` relies on the server IIS and application pool state? Aren't cookies stored in client side? What about user those are disconnected from server and have valid cookies on their machine? How they know if the IIS is recycled in next time they visit the same URL? @JeroenMostert – Ali Sheikhpour Jun 18 '18 at 15:21
  • Cookies are persisted client side, but it's up to the application to process them. It depends entirely on your application how this is done, but if your application uses the IIS session state to record a user's login state, and the app pool is recycled, this login state is lost and must be recreated. To avoid this, the application needs to use the cookie data to verify the user, and (possibly) log them in again. – Jeroen Mostert Jun 18 '18 at 15:27
  • I don't use session state. I have only a single cookie that is compared against the ID of user profile in database. @JeroenMostert – Ali Sheikhpour Jun 18 '18 at 15:41
  • 1
    Then you'll have to clarify how you detect that "logged in users are signed out". Because if the cookies are sent with each request, and your site uses this data to query the user profile in the database, and that profile is not erased when the database server restarts, then restarting SQL Server cannot have any effect on the workings of the site, no? "When you have eliminated the impossible, whatever remains, however improbable, must be the truth". There's something left in the realm of improbability that you haven't investigated yet. – Jeroen Mostert Jun 18 '18 at 16:42
  • Are you using the SQL Server sessionState mode? The default configuration for this does leverage TempDB for objects so you would lose the session state data any time SQL Server restarts. You can see this in the InstallSQLState.sql file in the .NET framework directory. This is the default install script. MS has a different set of scripts you can download for persisting session state in SQL Server mode. – GreyOrGray May 01 '19 at 21:54
  • I dont use asp sessions. Is there a relation between browser cookies and SQL server sessionState? @GreyOrGray – Ali Sheikhpour May 02 '19 at 06:43
  • So let's rule out the TempDB possibility. If you connect to your SQL Server instance and look inside TempDB do you see ASP* tables? There would also be an ASP* stored proc in Master and likely an ASP* job on the instance. – GreyOrGray May 02 '19 at 13:24
  • No there are no items about ASP* in TempDB. I am still confused what relation is between COOKIES and SQL Server? Aren't cookies a physical file on visitors devices? why should they exipre when something (e.g. SQL restart or IIS pool recycles) happens on the server? @GreyOrGray – Ali Sheikhpour May 02 '19 at 21:35
  • As part of a login scenario, cookies are a client side persistence mechanism that should accompany some form of server side persistence mechanism. Many of the server side options are temporary and will cause an invalidation of your state when the dependent service cycles. Using a database to persist the session information is a common solution, but the default option for SQL Server stores that information in TempDB which, itself, won't persist beyond the service restarting. – GreyOrGray May 03 '19 at 14:30

2 Answers2

1

In an asp.net web-application, you can set the session provider in the web.config file:

<sessionState 
            mode="SQLServer"
            sqlConnectionString="data source=127.0.0.1;user id=<username>;password=<strongpassword>"
            cookieless="false" 
            timeout="20" 
    />

Check if that isn't set to go onto a tempdb.

Other than that, SQL-server CANNOT have an influence on your cookie-lifetime, unless starting and stopping sql-server somehow clears the cookie-files on the machine sql-server runs on, which would be odd.

It's possible you use session-cookies, which get deleted every time you close the browser, in which case this is just a coincidence...

Cookies are a client-side technology.
They don't depend on anything on your server.
Cookies depend on the browser supporting cookies (and having them activated), the http-domain (and path, were set, and the subdomain, where set). Other than that, there can be HTTP-only cookies, session cookies, and normal cookies.

HTTP-only cookies can only be read or set on the server-side, it cannot be read by client-side scripts.

Since your repsonse is server-side, this can't be.
So the two remaining options are session-cookies (when you close your browser), or the cookie-timeout, which is either set in the cookie, or in the web.config file with forms-authentication: 

<authentication mode="Forms">
  <forms loginUrl="~/Account/Login" timeout="40320" />
</authentication>
Stefan Steiger
  • 78,642
  • 66
  • 377
  • 442
0

You can take a look into: https://stackoverflow.com/a/3855874/11442461. I'm not sure, but Machine Key should influence cookies and could depends on an SQL Server installation.

Mario
  • 278
  • 2
  • 15