I'm having a very interesting, but frustrating issue. I have an MVC 4 site running with standard ASP.NET Authentication.
In and only in the combination of IE 10 on Windows 8, when I traverse my site and navigate to an http url from an https url (both on the same site), it is generating a different asp.net_sessionid value. In every other browser/OS combo I have tried, this does not appear to be an issue.
I have searched high and low and while I certainly have found people experiencing various authentication issues (usually regarding IIS7 not recognizing IE10 as a browser), I have not found anyone else claiming to have experienced this exact issue. More concerning, I published an 'out of the box' MVC template project and it has the same issue. I can't possibly be the only one who has run across this problem (so I hope).
Anyone else run into this? Or maybe even just have some suggestions?
Thanks
UPDATE
Okay, so there is one more important aspect. I am running this on a load balanced environment. If I push the apps to a single server and test, I have no issues.
You mention that you have had this problem in a load balanced environment, right? I assume you are using the default "In Proc" method of storing session data. If that is the case, then I think I know what could be happening. (for the sake of argument, I will assume 2 servers, but It doesn't really matter if you have more)
You are being sent to ServerA and a session is created. Because this is In Process ServerB has no idea about it. Eventually (and how that happens is a matter of how your load balancer is set up. Sticky session? Cookies? Round robin?) you will be sent to ServerB. Because that server had no idea you already have a session; a new one is created and you are given a new session ID.
So why is it happening under your exact repro steps? Well, my hunch is that given enough time and load, you would see it just navigating from /page1 to /page2. Again - this depends on how your load balancer is setup, but it could be that since you are changing protocol that triggers something and you are sent to the another server in the pool.
How can you fix it?
To start, make sure you have the same machine key in their machine.config. If you don't have access to that I think it will work in the web.config, but I haven't tried it.
Now, set up another way to store session state. In Sql Server perhaps or MySql or Postgres or wherever. If you have SQL Server that will be the easiest since the driver is built it, but if you have another datastore you will either need to build or find a library that will do it. I worked on a project where we used Postgres to store session state.
We used npgsql as the driver to conenct to the server, and built our own PgsqlSessionProvider:SessionStateStoreProviderBase and hooking it up is actually really easy
<sessionState mode="Custom" customProvider="PgsqlSessionProvider">
<providers>
<add name="PgsqlSessionProvider" type="My.namespace.PgsqlSessionStateStore" connectionStringName="connectionStringName" writeExceptionsToEventLog="true" />
</providers>
</sessionState>
Related
Everything was working fine up to yesterday. VS2019. Net.Core 2.2 C#. Today I'm getting "This site cannot be reached" As far as I know I haven't changed any settings other than a routine Windows Update. I've read a fair few articles and nothing seems to work. Even a brand new web project with no changes has the same problem.
I get the same/similar no matter what browser I point at
I'm completely stuck. Does anyone have any ideas what it could be ?
Wierd!
To fix this all I did was connect to a local SQL database (on my machine) as opposed to a remote one (external server) and then delete all the cookies related to the localhost website.
It looks like some cookies get left laying around (from the external SQL) that affect IIS somehow, for any and all sites using SSL. Monitoring cookies I get around 7 created when I use the external SQL and only 3 when using the local.
Anyway, I just deleted all those cookies (localhost) because IIS still refused to work. I don't know why and I've just lost the entire day with this issue I may investigate another time but right now I need to crack on:(
I've inherited an ASP.NET web application written in C#. In many pages throughout the site the hostname is retrieved using:
BaseHost = Request.Url.Host;
Since I am using Visual Studio 2012 Express and it's installed local IIS Express server, I seem to be stuck with a port number appended to the hostname (localhost) when I debug/run locally. The above code does not result in the port number being included and as such breaks links that are generated by code (menu item links, redirects, etc).
I see that I can overcome the issue by changing the code to:
BaseHost = Request.Url.Authority;
This seems to fix it by including the port when I'm running locally (localhost:4652) and when published to my staging server (development.mysite.com).
My question: Is this bad form? Is there a time or a situation in which this is going to cause problems on my live site? It just seems a lot easier to do a quick replace of all these instances. I've considered writing a small routine to append : with Request.Url.Port, but it seems easier just to use Request.Url.Authority. Too easy maybe...
I've tried to research my question online and at MSDN, but I don't see an answer.
According to MSDN Authority includes the port number while Host does not. Another aspect is that Authority will escape reserved characters if need be.
Without knowing your application it is hard to say whether it is a good idea, but in general I would suspect that it won't break anything... so go ahead...
Another option is to run the application IIS instead of IIS Express...
My problem with this is that it ALWAYS adds the port, even when the port is not required. This can cause issues with multiple servers in some cases For example, in a production server environment behind a firewall on a pair of load-balanced web servers, it kept putting the firewall port in place, but that caused the URL to break because the port was tied to a specific web server in the server farm that wouldn't map correctly through the firewall. So I would be very careful with this method if you're using it across multiple servers. It caused a breaking issue with our application and had to be reverted back to using Url.Host. Plus, it made production web URL's look weird with the port number.
I am using the System.Web.Helpers.WebGrid extensively throughout our application, and for the most part it is fine and in fact running locally it is always fine or with a self SSL on the server it is also fine. So I don't know if the problem could actually be with IIS or a firewall, or the actual grid, or what I need to do to fix it.
On all browsers, although the result is slightly different, successive ajax sorting and paging on the WebGrid will eventially cause it to hang, and when I inspect the response in Fiddler I get
[Fiddler] ReadResponse() failed: The server did not return a response for this request.
If I copy and paste the url directly into a browser it will load but if I continually hit F5 I will eventually get a message stating "This webpage is not available" in chrome (with Error 103 ERR_CONNECTION_ABORTED) or "Internet Explorer cannot display the webpage" in IE.
The url is quite long and convoluted, something like http://app.myapp.com/mygrid/9e3b2ae5-cbe1-4a4a-a355-a14f00d26e24?mylayout=true&myid=634982439599769687&readonly=False&search=-&__=634982439708207187&sort=Name&dir=ASC
and this problem seems to go away if an SSL certificate is installed on the server, and doesn't happen at all locally.
Any ideas?
Your last paragraph of your question
and this problem seems to go away if an SSL certificate is installed
on the server, and doesn't happen at all locally.
immediately made me think of possible issues with DEFLATE and GZIP problems, knowing they would be disabled on encrypted connection, and quite possibly also for local connections, as you can't really move the same certificate from the server environment to your local development environment (that would beat their purpose), and would have to create a new self-signed certificate for testing purposes, if that was a requirement.
I also happen to have stumbled across infinite loop may occur in GZipStream or DeflateStream issues before with one of previous .NET 4.0, version 4.0.30319.236 to be precise. These problems have been solved in later .NET 4.0 builds and can be avoided by installing .NET 4.5 on top of you 4.0 installation as well. If that's what was causing your problems, it's still rather difficult to say and some other server-side settings might have caused it, such as now discontinued IIS Lockdown Tool, or even URLScan not accepting lengthy URL requests when the compression for them is enabled.
TL;DR - Either case, the obvious conclusion was to try disabling IIS server's urlCompression for these requests (and/or httpCompression) in your Web.config file, and see if the issues still persist:
<configuration>
<system.webServer>
<urlCompression doStaticCompression="false" doDynamicCompression="false" />
</system.webServer>
</configuration>
This is obviously a hack solution that should be looked into further, by comparing differences between server's and your local environments, if that is at all possible. It is also quite possible that the server wasn't updated with all the latest libraries, and doing so could resolve it as well.
DISCLAIMER: I realize this isn't really a 100% bullet-proof answer, however OP suggested in the comments that it did the trick. I have also posted this question and a possible answer to it on DMZ yesterday, asking if anyone else would know of a better answer and knowing these issues would be immediately recognized by our IT Security wizards, but the St. Patrick's day seems to have taken its toll :)
Cheers!
(Sorry if this is a really long question, it said to be specific)
The company I work for has a number of sites, which have been running for some time with no problems. The applications are a mix of ASP.NET 2.0, 3.5, and 4.0, all using an ADO.NET to connect to a SQL Server Standard instance (on the same webserver) all being hosted with IIS7.
The problem began when we moved to an upgraded webserver. We made every effort to set up the server, db instance and IIS with the exact same settings (except for the different machine name, and the fact that we had upgraded from SQLExpress to Standard), and as far as we could tell, we did. Both servers are running Windows Server 2008 R2 (all current updates applied), and received a default install.
The problem is very apparent when starting up one of these applications. When you reach the login page of our application, the page itself loads extremely fast. This is true even when you load the page from a new machine that could not possibly have the page cached, with IIS caching disabled. The problem is actually visible when you enter your login information and click the login button. Because of the (not great)design of our databases, the login process must access a number of databases, theoretically up to 150 separate DBs, but in practice usually 2. The problem occurs even when only 2 databases (the minimum) are opened. Not a great design, but we have to live with it for now.
When trying to initially open a connection to the database, the entire process stops for about 20 seconds every time, regardless of whether you are connecting to 2 dbs or 40. I have run a .NET profiler (jetbrains dottrace) against the process, and the only information I could take from it was that one or all of the calls to sqlconnection.open() was accounting for 90% of the time. This only happens on first-use of the application, but the problem is compounded by the fact that IIS seems to disregard the recycling settings we have set for it, and recycles the application after a few minutes of idle, causing the problem to occur again.
I also tried to use the SQL Server profiler to see which database operations were the cause of the slowdown, but because of all the other DB activity, (and the fact that I had to do this on our production server, because the problem doesnt occur in our test environments) I couldn't pin down the exact operation that was causing the stoppage. I will try coming in late at night and shutting down the production sites to run the SQL profiler, but I might not be able to do this right away.
In the course of researching the problem, I have tried a couple solutions
Thinking it might be a name resolution problem, I tried modifiying both the hosts file on the webserver as well as giving the connectionstrings an IP address instead of the servername to resolve, with no difference. I have heard of the LLMNR protocol causing problems like this, but I think trying to connect by IP or resolving with the hosts file should have eliminated that possibility, tho i admit I never tried actually turning off LLMNR.
I have increased the idle timeouts, recycling intervals etc in IIS, but this doesn't even seem to be respected, much less solving the problem. This leads me to believe there is a setting overriding the IIS application settings on the machine.
multiple other code fixes, none of which made any difference. Is a SqlServer setting causing the problem?
other stuff that i forgot by now.
Any ideas, experience or whatevers would be greatly appreciated in helping me solve this problem!
I would advise using a non-tcp connection if you are still running the SQL instance on the local machine. SQL Server supports several protocols, tcp, named pipes, and shared memory are the more common.
Named Pipes
Data Source=np:computer\instance
Shared Memory
Data Source=lpc:computer\instance
Personally I prefer the Shared Memory. Remember you need to enable these protocols, and to avoid configuration mistakes I suggest you disable all you are not using.
see http://msdn.microsoft.com/en-us/library/ms187892.aspx
IIS Reset
In IIS7 there are two ways to configure the idle-timeout. Both begin by clicking on the "Application Pools" section and right-clicking the appropriate app domain. If you click the "Recycling..." option there is one setting. The other is in "Advanced Settings..." under the section for "Process Model" you will find "Idle Time-out (minutes)" which set to zero disables the process timeout. This later option is the one that works for us.
If I were you I'd solve this problem first as restarting the appdomain and/or worker process is always painful even if you don't have a 20 second lag.
Some ideas:
from the web server, can you ping the db server and get a "normal"
response, or are you seeing a similar delay?
if you're seeing a delay, run a tracert to see if you can nail down where the slowness is occurring
try using a tool like QueryExpress (http://www.albahari.com/queryexpress.aspx) which doesn't require an install to run. You can download this EXE and run it from your web server. See if you can connect to your db using this and run queries in a normal fashion.
Try something like SysInternals' TcpView (http://technet.microsoft.com/en-us/sysinternals/bb897437) to take a look at your open connections and see what activity is happening on your server and how much data is being sent to and received from your db server.
Just some initial thoughts on where I'd start to look based upon your problem description. I hope this helps. Good luck with things!
With IIS not respecting recycling settings: did restarting IIS/rebooting change the behavior?
I'm quoting myself on a previous question I asked to further explain:
"I'm trying to run a freshly created ASP.NET Website using C#, however when I do so it launches FireFox and attempts to connect to http://localhost:1295/WebSite1/Default.aspx (for example), but after about 10-15 seconds it displays a "Connection Interrupted - The connection to the server was reset while the page was loading." Error.
This issue is also present with older ASP.NET C# pages/Web Services I've built in the past, nothing is actually running off the ASP.NET Development server."
This is the problem that was occuring, that is before I noticed every time I ran the website, the notification for the ASP.NET Server-startup showed one port (1130 for example), and when the website failed to load; it turns out it was attempting to load the site on another port (In this case, 1128). It was suggested that an anti-virus program could have caused this kind of redirection; low and behold uninstalling Nod32 fixed the problem!
So my question is: Has anyone found a way to create an exception or remove this functionality from Nod32?
Within Nod32 enter the Advanced Setup options, and turn off protocol filtering.
It's a known problem with NOD32. Looks like it's IMON module (protocol filter) accidentally does some modifications of TCP packets that go through it.
The solution is to either turn it off, or use a different software.