We have recently moved our webserver to a new machine (IIS based) and in the asp.net mvc application I am working on, I have noticed that in the firebug console each request fails twice with a 401 error before finally succeeding on the 3rd try. This did not happen previously and the application seems to be running slightly slower than before, though that could just be my perception.
What might be causing this issue and what might I be able to do in order to avoid it?
I ran into a similar problem couple weeks back and the below post saved my day...
https://serverfault.com/questions/137073/401-unauthorized-on-server-2008-r2-iis-7-5
I hope this may help you...
Consider trying to check your IIS pool. Or maybe a timeout expiration?
Related
At my work, we are finally upgrading our old Identity Server 3 to 4. We just got a very weird problem doing so. Everything works fine in all major browsers, but we also need to support some Electron clients. Here is where the weird part begins. All very old clients using Electron version 3 still work. All newer clients starting at Electron 9 also work. The only clients that don't work are the ones using Electron 6 (Chrome 76).
I already found this very helpful article written by Sebastian Gingter which helped to get the login working. But it only got me one step further. Now the client gets stuck at the connect/authorize/callback endpoint using the response_mode = form_post.
I already found some articles/stackoverflow questions pointing out to check the redirect URIs and to downgrade the CSP to version 1. The redirect URIs are configured correctly since the other clients work. The CSP does not help since I don't even get that far. It seems that the response body is never even loaded by Electron/Chrome.
Devtools Timing Screenshot
The request never finishes. On the server-side, it does though. I debugged through the IS 4 code and the dynamic HTML is written to the response like with all the other clients. I even called CompleteAsync() on the response manually and it still did not finish.
I researched and debugged for quite some time now and am out of ideas. Does anyone out there know this issue and more importantly also knows how to fix it?
I have an MVC 4 app and am using the default authentication provider. I'm not using persistent cookies.
I don't have any problems in development but when hosted at HostGator, I SOMETIMES get logged off when I try to create a new item (HTTP POST). When this happens, I end up at the log on page like I wasn't authenticated.
HostGator does NOT have the app on multiple web servers so I'm thinking I shouldn't have to worry about machinekey stuff. Am I wrong?
When this happens, I just log in again and create the item again and it will succeed. Once this happens, I can't recreate the issue. I try reopening the browser and even different browsers but creating items will always work. It only seems to happen again if I try much later.
Some additional info, the timeout is set to 2880 (the default for an MVC project), which I know is long but I can't see how it would be related. Still, thought I'd mention it.
So I can't look at IIS logs or event viewer to get any idea what could be happening but I can add more logging to the app. Can anyone provide ideas for what to check or what logging to add to diagnose?
Thanks
EDIT
I realized that I could get to the IIS logs so I compared the POST that succeeded and the one that failed and immediately noticed something.
When I first did the GET to load the Item/Create page/view, the cs-username was populated but when I did the POST to create the item, it was gone. I can see that when I logged in again and was able to successfully create the item, that POST did have the cs-username populated.
Why would it disappear between the GET and the POST? There was a 7 minute delay from the GET to the POST but I can see I logged on 1 minute before the GET so the session was only 8 minutes old when the post happened. I've double checked that I don't have sessionstate explicitly configured so the default should be 20 minutes. I feel like I'm onto something but not sure exactly what.
Might be worth adding Glimpse, although running that on deployed code is kinda risky. It would have the benefit, though, of letting you see what's actually happening on the server. I've never used HostGator, so I can't say for certain, but if they recycle app pools aggressively, that would invalid your login, and explain why the logoff seems to happen randomly.
Someone changed my admin password that I use to login to my website. I changed it back, and I can now log in to the MVC site on localhost. However, it won't log in on the server when I publish the site out. This happened yesterday, too, but eventually the production server started letting me log in again. They both use the same database. There seems to simply be a a time delay or some sort of caching going on here. Does ASP MVC do something like this? Does anyone know how to refresh it so that I can log in to both sites again?
Thank you.
Entity does have cache of it's own. But I think your problem depends on whether you enable it.
So I suggest you learn more about the cache and check if you enabled it or not~
You can find more about Entity's cache here
The answer to this question, as stated by Mike McCaughan, was this:
The server will cache connections in a connection pool. To refresh,
restart your application pool in IIS.
We currently have a set up with a load balancer carrying out SSL offloading, an http server and a websphere app server. Having got over the initial hurdle of the offloading preventing CAS from thinking it was running under https (which we got around by using the httpsIndicatorHeader variable), we now have another issue. Despite the fact we can see CAS redirecting to the target application, the 'handshake' seems to fail, showing a loop of tickets being generated and tried, but never actually validating, and the target application is never reached. There do not seem to be any errors being generated however.
Has anyone experienced anything similar before?
Cheers,
Rob
After investigation, the problem was that the application redirect url set up in websphere was pointing to the original url, rather than suffixing /j_spring_cas_security_check. This caused the circular loop to occur without any attempt to validate the ticket.
I've got a site that's currently in beta and thus password-protected (sorry, can't show yet). Most of my users access the site no problem and able to interact with it, upload files, ..etc. There's one guy, however, who seems to have a persisten issue with access. Whenever he accesses the site, the connection times out and Heroku sends back an app-not-available response. Better yet, that screws access to everyone else at that time and I have to wait for the service to restart. Heroku logs show no sign of any issues. New Relic logs are also fine.
Do you have any suggestions on how I could troubleshoot , what tools I could use to monitor?
I have also had issues like this with heroku from time to time, and they have blamed in on EC2 when I contacted them. However, this has only happened to me twice and hasn't happened in months.
I tweeted #heroku and #salesforce with the problem when I got a snarky remark, and it got me in touch with someone who was actually able to help me. Sometimes they can be quite standoffish :)