I've got two web portals that are almost identical in architecture. One requires that I add the following to my web.config and enabling the state server, as the logged-in user sessions expire after 2-5 seconds:
<sessionState mode="StateServer"
stateConnectionString="tcpip=localhost:42424"
cookieless="false"
timeout="20"/>
I'd like to know what some of the root-causes are that will cause this issue in one web portal but not the other.
This is a C# ASP.Net v3.5 app sitting on Windows 2008 R2.
Strangely enough, on my local dev box (Windows 7), I don't need to enable this, and the sessions last just fine.
Any discussion on this would be appreciated.
You also need to make sure that you define a machine key, in your servers in the machine.config files, or in your web.config.
I've implemented this scenario successfully on my work servers in a web farm scenario, most recently last week, and it has definitely helped maintain my sessions.
As to why you need to do this ---
The client needs a way to track their session ID. In a farm scenario, depending on traffic, they can be bounced from Server #1 on one page request, to Server #2 on another page request, then back to Server #1 on yet another page request.
This link is pretty helpful.
Related
I have more than one site on iis. Some sites working on another machine also but they are using same database.
Sites have caching mechanism. One of the site using for making customization about sites. Customization are saved on DB.
I want to reset caching for sites which are effected from customization. I can found two thecnique for this.
I want to asking for another solution.
Technic 1: adding restart endpoint for sites in web.config file and calling them when change made by user.
Technic 2: using db events for catching changes (in asp.net application may be I can't get changes because of sites dying after idle time)
Both of the techniques listed in your question have drawbacks. Technique 1 restarts the entire server, which is over-kill. Technique2 has the drawback you list, and is relatively complex to implement.
The approach I use is to provide a controller action that invalidates caches. That action requires authentication, and can be accessed either via an administrative web page on the server (single instance server), or can be invoked by accessing the URL of the controller action and providing appropriate credentials (server farm, invoke e.g. https://ServerNameOrIp/Admin/InvalidateCache once for each server/IP in the farm).
I am running into this strange issue where few users of my app plug out their laptops from dock and move to WIFI network while using the application, Now after changing the network when they click on any navigation in the application it takes them back to the login page mentioning the session has expired.
Background: The server where the application is hosted have the load balancer which dynamically routes the incomming request, hence when user goes of from one network to another the old session maintained by the web browser stays open but load blancer identifies it as a fresh request and hence allocate to next available server which requires a login, now if user is fortunate to be routed on the same web server where he was before then all works fine otherwise he is redirected to new web browser.
Please help me resolving the rare scenario issue.
Thanks in advance.
Vishal
This issue depends mostly on your load balancer and the persistence of stickiness.
Some balancers handle the sticky persistence internally, so they have a table between client IP and route. Your case sounds like that.
Now, if you shift the persistence from the internal table to a cookie (or URL appendix), you can tackle the case. By using a cookie, the client will send the cookie on every request and the load balancer can check, whether the requested route is still valid and then serve the request. There is a non-IIS example for Apache (http://httpd.apache.org/docs/2.4/mod/mod_proxy_balancer.html#stickyness_implementation), how they approach stickiness, but the feasibility depends on your balancer.
Since you have load balancing in-place then it is just a questions of whether to store the sessions in Jsession or Cookie, to avoid this issue I suggest your configuration the server to use Cookies. As by default Tomcat 7 (and I believe Tomcat 8) are configured to use Jsession
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
Our operator has implemented a Round Robin load balancer on our web portal and it seems to be causing some problems I can't get to the bottom of.
I'm able to identify which server we're on and as we navigate around the site we stay on server A. If I leave it for 5 minutes and try another page I'll get pushed to server B, logged out and shown the log in page.
I've got them to make sure the MachineKey in the machine.config is the same on both servers and I've tested locally that the session isn't being used - I can turn the session off completely locally and it still works. I've verified on both servers it is creating an ASPXAUTH cookie on the domain so we should be classed as authenticated on both servers - but keep loosing my authentication every time I change server.
Any ideas on what could be causing the logging out? I'm guessing it's my misunderstanding about how ASPXAUTH works.
Sessions are handled separately from Forms Authentication. There is a good explanation of this here.
The most common reason for Forms Authentication failures on load-balanced environments is lack of synchronization of the MachineKey element. You've stated that you've got the server operators to ensure that the MachineKey is synchronized, but have you verified this yourself in some way? Is this the case on ALL the web servers? From previous dealings with a couple of commercial web hosts, I've found that it is (unfortunately) difficult to take their assurances at face value.
Another thing to check is if the FormsAuthentication configuration (timeout, path, name, etc.) is the same on all of the hosts.
Are the patch levels the same on all of the hosts? You might want to see if the compatibility switch mentioned here is applicable in your situation.
Assuming that the hosting setup is correct, maybe you have initialization code on the page that logs you out if some condition is not fulfilled?
Try to take a look at the server logs and trace the sequence of HTTP requests involved during a failed page request. That might produce a clue.
Edit: This guide to troubleshooting Forms Authentication problems is detailed, and quite helpful: Troubleshooting Forms Authentication
Check for any other application functionality which depends on cookies. The web server on Server B will not recognize cookies that came from Server A. If any part of your authentication depends on cookies being populated, then that could cause your problem.
You have probably already ensured that the domain used for cookies is the same on all of the load balanced servers, but I thought I'd mention that. If the domains aren't compatible, then the browser will simply not send cookies to the server.
I got this error when i access my hosted web application(in VS2008 C# ASP.NET 3.5 Framework)
Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.
The interesting thing is that there is no problem if we continue after login process. If you logged in and do nothing for 15 or 20 minutes, then click any menu...this error will be generated. So I doubt that it is related to session out. In my webconfig file I have written session time out as follows.
<sessionState timeout="15" />
How can I correct this error?
There are a few ways to fix this issue, but some solutions are better than others. The fastest way is usually to add the following to the web.config:
<pages enableEventValidation="false" viewStateEncryptionMode="Never">
The problem with the above solution is that you sacrifice some security. The next "quick fix" is to add the following to the web.config, but there are drawbacks to this as well:
<pages enableViewStateMac="false">
If this application is hosted by a web farm or is otherwise distributed across multiple web servers, you should probably steer clear of that option.
In my opinion, the best overall solution is offered here.
I believe that your problem is in App Pool "Idle timeout" field.
You have to ask to your provider to change it to something greater... say 20mins
Take a look here.