I'm experiencing an odd behavior on ASP.NET <sessionState> configuration.
I'm trying to use mode="SQLServer".
When I put cookieless="true" everything works happily as it should be and the ASPStateTempSessions table get filled as expected.
When cookieless="false" ASP.NET simply ignore my configuration and host the sessions in its process (nothing on ASPStateTempSessions).
I have no idea why the cookieless configuration is yielding such unexpected behavior.
Anyone know why this happens or how do I solve it?
By the way here's my configuration:
<sessionState mode="SQLServer" allowCustomSqlDatabase="true" sqlConnectionString="MyConnectionString" />
P.S.:
I've double checked my browser cookies, it's definitely nothing to do with my browser.
I also tried to use a custom implementation just to for the sake of testing.
The exact same behavior happens, only works with cookieless="true".
When cookies are used in the web.config the session will not be created on first use until something is persisted to the session object. This means that the database will not be updated and the cookie will not be written to the server. You can test if this is the case by writing some dummy value back to the Session object and then checking to see if the database record has been created and the cookie written to the browser.
Related
I have differing behavior between a test server and a dev server - on my dev server everything works fine but on the test server the ASP.NET_SessionId cookie disappears after a flow of events and hence so does the servers session. Testing was done in the same browser on the same machine & the code bases are virtually identical. The only significant difference is that the pages are being served from two different pcs.
The flow of pages (all https) that causes this is such:
Load page from domain A that contains an iframe (session cookie exists at this point).
Domain B is loaded into the iframe.
A second page from domain B is loaded into the iframe triggered from the first page.
The second page does a form post to back to domain A where the session cookie is now absent.
EDIT
Forgot to say - we're using SqlInMemoryProvider as our session state.
You could share the session state between two servers using the below ways:
1)Using SQLServer Session:
In this mode of session state, the session objects are stored into SQL Server.
The benefit of using this technique is that all the data in the session will be stored together in a different location or you can say a centralized location in SQL Server, to get it working we just need to configure the SQLServer to store session data.
2)Using the StateServer Session:
In this mode of session state, the session objects are stored in a separate server handled by a Windows Service running on that server.
The benefit of using this technique is that all the data in the session will be stored together in a different location. In this case, the server to be handled by the Windows Service is named "aspnet_state"; this will become the centralized location for session data. To get it working we just need to configure the StateServer to store Session data.
when you share the session state between two servers make sure ASP.NET state service is installed on all the servers and the settings are as below:
Also, the service cannot be accessed remotely by default. To enable that option you need to set the value of the following registry key to 1: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\AllowRemoteConnection. Don’t forget to restart the asp.net state service after the registry key change.
You need to declare the session management options within the system.web node. Example:
<sessionState mode="StateServer" stateConnectionString="tcpip=machinename:42424">
</sessionState>
If you want to use the SQL Server type then this section may look like the following:
<sessionState mode="SQLServer" allowCustomSqlDatabase="true"sqlConnectionString="the connection string name to the server">
</sessionState>
Where SQL connection string refers to the name of the connection string in the connectionStrings section of web.config which holds the details of the state table. The connection string itself may take up the following format:
<add name="ASPStateConnectionString" connectionString="Data Source=[DB machine name where state DB is stored];Initial Catalog=ASPState;User ID=[db admin user name];Password=[db admin password]"providerName="System.Data.SqlClient" />
we also need to add a machine and a validation key within the system.web node, that may look something like this:
<machineKey
validationKey="some long hashed value"
decryptionKey="another long hashed value"
validation="SHA1"/>
The default setting for the validation key is AutoGenerate which does exactly what the name applies: the key will be generated automatically by IIS. The default generation mode for the decryption key is IsolateApps. It generates a unique key for each application by using the application ID.
We need this common machine key as we want to run this on several machines so we don’t want the machine key to be automatically generated.
For more information you could refer this below links:
https://dotnetcodr.com/2013/07/01/web-farms-in-net-and-iis-part-5-session-state-management/
https://www.c-sharpcorner.com/UploadFile/25c78a/load-balancing-session-state-configuration/
It's because cookies are not stored if domains are different.
It's treated as 3rd party cookies.
You need to use same domain as parent site to iframe site.
Or else you need to use cookieless session.
I have recently gone through this problem and come across the concept of cross-site cookies. If you want to share and use the cookie across the different domains then you have to set your cookie samesite attribute to None (SameSite=None). It must be secure otherwise it will be ignored and not send back to the server by browser (Chrome). To use a secure tag for your cookie you have to enable the HTTPS for your website.
For more detail you visit: https://web.dev/samesite-cookies-explained/
CASE 1: StateServer
<system.web>
<sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42626" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20" />
...
</system.web>
CASE 2: SQL Server
<sessionState mode="SQLServer" stateConnectionString="tcpip=127.0.0.1:42626" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20" />
Question:
1. In case 1 and 2 appropriate location of sql or state server have to be configured in web.config for each of the web server in farm.
Can we have some servers configured as state and some as sql?
Can we have some cookieless and some as withcookie
Suppose if we use only <sessionState cookieless="true" />, then by default which of the modes is used? Can this be done in a multiserver farm, or is it necessary to specify the IP?
1.) Can we have some servers configured as state and some as sql?
No, you should not. Suppose when a user makes a request, then one of the server from your Web Farm will store the session in a StateServer. now in case the same user makes another request ( by clicking some links etc...), then image what will happen if your load balancer send this request to the 2nd Web server ? There will be NO session for the same user as you configured SqlServer mode for the same and the session for the user was stored on a state server on First request.
2.) Can we have some cookieless and some as withcookie ?
Again NO, for a very similar understanding as pointed above. One of the server will use cookies to track the session and the other one Cookieless ( hence URI ) to track the same session and thus, if the request gets forwarded to different servers, NO session will be detected.
3.) Suppose if we use only <sessionState cookieless="true" />, then by default which of the modes is used? Can this be done in a multiserver farm, or is it necessary to specify the IP?
Understand that this setting: cookieless="true|false", is just used to TRACK the session for a Particular user between the Client side and server side.
The Actual session DATA is there stored on SqlServer/State Server, which is defined in your mode settings as:
<sessionState mode="StateServer|SqlServer" ... />
if you don't specify any mode setting, default value of InProc is used.
Additional Note:
The Cookie or the URI have a SessionID associated with them. SessionID is a unique string, used to TRACK individual visitor between visits to website.
As a result of cookieless="true", SessionID will be embedded in all page URLs. The drawback is that you'll end up with ugly URLs, which are not so good for SEO (search engine optimization) and visitor definitely will not remember it. Here is an example URL of website which uses ASP.NET cookieless sessions:
http://samplewebsite.com/(45f8c4zyybphaw2mt3dfgnjk4j)/Home.aspx
Bolded part represents session id, which is used to recognize a visitor.
Your question is a bit vague. If you're hosting one app across multiple servers I would recommend sticking to one method. What if one user first connects to a server with one mode, and the next request is handled by another one? The session state would not be accessible/known to the other server.
As to your questions, the documentation is really quite clear.
cookieless does not affect mode. If you don't specify mode, the default is InProc. If cookieless is true, ASP will use the query string.
1.-I'm using reporting services and sometimes I get this error ASP.NET session has expired or could not be found when I try to load a report.
2.-I realized that I get this error when the Session.SessionID property changes even though the user is the same. If it does not change, the report is loaded. I mean, if I refresh the report a number of times, whenever the Session.SessionID is the same than the last one, the report is loaded.
3.-Microsoft Documentation says:
When using cookie-based session state, ASP.NET does not allocate
storage for session data until the Session object is used. As a
result, a new session ID is generated for each page request until the
session object is accessed. If your application requires a static
session ID for the entire session, you can either implement the
Session_Start method in the application's Global.asax file and store
data in the Session object to fix the session ID, or you can use code
in another part of your application to explicitly store data in the
Session object.
If your application uses cookieless session state, the
session ID is generated on the first page view and is maintained for
the entire session.
The point is that I can not use a cookieless session state because I need cookies.
What could I do to avoid this error? Or What could I do to avoid the Session.SessionID to change on every request?
You are probably storing your session InProcess. Try changing it to session state server. You can find more details here.
I'm using report viewer 11.0.0; in your web config on system.web section, put the next configuration:
<sessionState timeout ="120" mode="InProc" cookieless="false" />
When you are generating the report (C# code bellow) in the reportviewer object change the KeepSessionAlive property to false and the AsynkRendering property to false, and that's all
this.rvReporte.KeepSessionAlive = false;
this.rvReporte.AsyncRendering = false;
(rvReporte) is a ReportViewer control located on my asp.net Form
This solution work for me, i hope that work for other people.
Regards
<httpCookies httpOnlyCookies="false" requireSSL="false"/>
Solved the problem.
Thanks to :
http://www.c-sharpcorner.com/Blogs/8786/reportviewer-Asp-Net-session-has-expired.aspx
I had the same issue on report viewer page when the web site was accessed from outside intranet. hardvin's suggestion saved the day for me which is to set
this.rvReporte.KeepSessionAlive = false;
this.rvReporte.AsyncRendering = false;
I changed the property on the control itself. I am using report viewer on a user control which raises a custom event for supplying parameters programmatically at the host page instead of prompting the users.
I solved this issue by setting AsyncRendering to false on reportviewer server control
Having the reportviewer being displayed in iframe was giving us this error. If displayed outside of iframe it works nice.
The reportviewer object has this configuration, AsyncRendering = false and KeepSessionAlive = true.
The webapp that has the reportviewer and set the session cookie in the browser was compiled with .net framework 4.6.1. We upgrade to 4.8 and put this in web.config
<sessionState cookieSameSite="None" />
<httpCookies requireSSL="true"/>
Só the solution is from https://learn.microsoft.com/en-us/aspnet/samesite/system-web-samesite#:~:text=The%20updated%20standard%20is%20not%20backward%20compatible%20with,SameSite%3DStrict.%20See%20Supporting%20older%20browsers%20in%20this%20document.
The answer given by Alexsandar is just one of the solution to this problem.
This link clearly explains what is the root cause for this problem and possible solutions:
http://blogs.msdn.com/b/brianhartman/archive/2009/02/15/did-your-session-really-expire.aspx
In case of Brian, the way he has descrived the problem, if he had just a single IIS server, using a session object in his code would have solved the problem because in that case, the SessionID which is passed in the request from browser to the server will get mapped to a corresponding sessionID on the server and hence the session expiry message will not come.
Setting the mode may only work in case of a server cluster where Brian had multiple IIS servers handling the same request. In that case an out of process mode will help to retrieve the session object from the Session Store irrespective of the server hit.
So based on this observation, I would conclude that Brian's problem was not related to cookies but to a server cluster. The information provided by Brian in his question and the subsequent solution misled me and hence this clarification. Hope it helps anyone looking for a similar problem.
Thanks,
Vipul
I have added the below-mentioned line on the web config file and it is working fine for me.
<sessionState mode="InProc" cookieless="true" timeout="3000" />
<pages enableSessionState="false" />
<customErrors mode="Off" />
Try removing SessionState="somevalue" tag from the top of your calling ASPX page. I'm using a custom SessionState and refuse to use InProc since I have multiple instances on Azure. You can even use AsyncRendering=True if you desire. Let me know if this did the trick for you.
For me, it turned out to be having more than one worker process for the app pool.
For me Azure hosted web app turning ON - ARR Affinity fixed the issue.
ARR Affinity ON
My site allows anonymous users.
I saw that under heavy load anonymous users get sometimes profile values from other users.
I first delete my cookies and get a valid unique value in the cookie value .ASPXANONYMOUS. After a couple of requests I get a new value for .ASPXANONYMOUS which is already used by another user. I see in my loggs that there are always a couple of users who share the same value in .ASPXANONYMOUS.
I can see in the my logs that 2 or more users realy get the same cookievalue for .ASPXANONYMOUS even if they have different IP.
Here is the htttp traffic. In the second image the changing cookie is shown (You have to display the image full size do be able to read the log):
One of the many requests that work ok:
alt text http://img413.imageshack.us/img413/2711/log1.gif
Then there is this one request that changes the cookie
alt text http://img704.imageshack.us/img704/8175/log2.gif
Then the new cookie is used
alt text http://img704.imageshack.us/img704/3818/log3.gif
Just to be safe I removed dependency injection.
I dont use OutputCaching.
My web.config has this setting for authentication:
<anonymousIdentification enabled="true" cookieless="UseCookies" cookieName=".ASPXANONYMOUS"
cookieTimeout="30" cookiePath="/" cookieRequireSSL="false" cookieSlidingExpiration="true" />
<authentication mode="Forms">
<forms loginUrl="~/de/Account/Login" />
</authentication>
Does anybody have an idea what else I could log or what I should have a look at?
UPDATE
I saw now that the http-traffic I showed is perfectly valid. A changing value in .ASPXANONYMOUS is something that happens because the cookie gets refreshed. The value contains AnonymousID and a Timestamp.
This does not lead to users having the same value in .ASPXANONYMOUS under normal conditions.
The problem realy is, that whenever the cokies get set from the AnonymousIdentificationModule, then there is a chance that a couple of user get this cookie. Setting a cookie in my application doesnt have this strange sideefect.
I had the same problem and solution was to turn off output caching for the responses where you call SetCookie. Below are several links describing this
Don’t let your cookie being cached by accident!
ASP.NET Session Mix-up using StateServer (SCARY!)
Integrated Pipeline and the kernel-mode cache
Are you declaring any static variables in your code at all? I had this similar issue, and narrowed it down to that; at least for my situation.
I have a really strange problem to do with session variables.
I have an asp.net page that sets a few session variables. On my development machine (localhost), I do a postback and the session values are still populated.
When I Reload the page by clicking on the url bar and pressing enter the session variables are still there.
However when i deploy this page to a webserver, the page still retains the session values when doing a postback, but as soon as i click the url and press enter the session values are lost (where the ispostback = false)
But when i press the refresh button the session variables are present (but i do get a popup warning me that the page data needs to be resent!)
i am running IE 7, and the webserver is iis6 what am i doing wrong?!
please help x
What session state provider are you using? The default is InProc, whereby sessions are stored in the asp.net worker process. This means session state can be lost if the application pool is recycled or the webserver is low on memory. You could try using StateServer mode, whereby sessions are stored in a separate service running on the server. You can change the mode in web.config eg.
<system.web>
<sessionState mode="StateServer" />
</system.web>
See http://support.microsoft.com/kb/307598
Sounds like the webserver is not configured to use session state.
Make sure your web.config has the correct <sessionState> section, with the mode being InProc:
<sessionState mode="InProc" />