I have a web application that is stuck in an infinite loop, and I have no idea where to look next. This is an intranet site, so there is no link I can share, but I've listed as many details as I can think of below. I would appreciate any ideas or suggestions. Anyone has.
The details:
IIS 7
.Net 4.0
Windows 2008
Default document is Login.aspx
No HTTP redirect set on app or Login.aspx in IIS
Fiddler shows Login.aspx using status code of 302 and redirecting to Login.aspx
If I open my site, it points to Login.aspx and gets stuck in a 302 loop. If I open the site but point to register.aspx, Fiddler shows register.aspx going to Login.aspx which of course redirects to Login.aspx.
What I've done:
Run the webapp from Visual Studio -- everything works fine
Check web.config for redirect commands -- there are none
Check IIS for redirect commands -- there are none
Look at Fiddler for another page in the loop -- there are none, just Login.aspx to Login.aspx
Check Login.aspx for redirect commands -- there are none
Check Login.aspx code behind for redirect commands -- there are none
Run the app on my box using the web.config from the server -- everything works
Check Login.aspx for redirect commands -- there are none
Cleared Cache -- problem still persists
Republished -- problem still persists
Republished and cleared Cache -- problem still persists
Disabled Default Document in IIS
Will share this just in case it is an answer, as it sounds like a problem we had.
ASP.net MVC site with [RequiresHttps] attribute on our login action.
Behind a load balancer that was doing SSL acceleration (resulting in the request that actually hits the server side code being already decoded and effectively under http).
Server code thinks this is an issue and redirects back to itself using https.
Rinse and repeat.
Been quite a long time since this was answered, and my comment below here to 'not use RequireHttps' is probably a bit out of date.
Anyone looking at this answer and thinking that it answers their problem would probably be well advised to look into configuring their load balancer to use X-Forwarded-Proto headers:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto
And then setting up their MVC site to be able to read these and still think they are under HTTPS at the border of your environment:
https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer?view=aspnetcore-6.0
Found the problem. Found this logic in the MasterPage:
Dim strPage As String = Request.Url.AbsolutePath.Replace("/", "")
'Check that user is logged in
If Not strPage = "Login.aspx" And Not strPage = "Register.aspx" Then
If Session("intUserId") Is Nothing Then
Response.Redirect("~/Login.aspx", True)
End If
End If
Evidently, strPage does not equal Login.aspx when browsing to Login.aspx on the server.
I should have cought this when I was investigating it. Thanks Ross for your comment, it helped me to find this!
I had encountered a similar bug. But mine was a typo with two
Response.Redirect back to back.
If (conditon1){
Response.Redirect("Page1.aspx");
}
If (conditon2){
Response.Redirect("Page2.aspx");
}
And the fix was to simply put the other if in the else block.
Related
I have an Asp.Net app running under IIS with two backend servers with Loadbalancing + machinekey configured. Once I've activated a CDN (Varnish with caching disabled), I'm redirected to login page every time I navigate between pages.
I believe that the postbacks are cached somewhere and the app logs don't help.
I've seen similar answers like here, but none of them suggested a solution.
Any idea how to track this down without changing the App config?
On the browser, this is what I see :
https://example.com/
302 redirection to https://example.com/login.aspx?ReturnUrl=%2f
successful login redirects to https://example.com/accueil.aspx with some errors (see attached)
selcting https://example.com/pages/module.aspx?PAGEID=-00000001 reurn a 302 redirection to loginn page https://example.com/login.aspx?ReturnUrl=%2fpages%2faccueil.aspx%3fMSG%3dIdentification+obligatoire
enter image description here
We have an ASP.NET webforms web application running on IIS 6. There is a permanent redirect in place, for one of its pages: https://www.deurengigant.nl/content/voorwaarden.htm to https://www.deurengigant.nl/content/voorwaarden.
This redirect isn't happening on our local testing version, nor is it happening on a live test version, using the exact same code (including web.config, which has the database connection string): http://test.deurengigant.nl/content/voorwaarden.htm. (Yes, we don't have https on the test version.)
I've already checked the URL rewrite section in IIS Manager for the web site, but there is nothing there. (Pretty sure it simply shows what's defined in web.config rewrite rules anyway.) The HTTP Redirect section shows nothing either.
I've gone through the code looking for redirects, but couldn't find the problem there; also, the test version and our local version use the same code folder.
I've also checked the URL in a Chrome incognito session, to make sure the permanent redirect isn't pulled from cache.
What could I have overlooked? Where else could the 301 Permanent Redirect be set up?
The redirect is in applicationHost.config, which is located in C:\Windows\System32\inetsrv\config.
I think it's unwise to put it there, since that file is usually not in source control, nor copied to developer machines for local debugging.
As for why the test version on the live server doesn't have the redirect… I still don't know! They both use applicationHost.config, so they should have them both! That said, check the "error pages" section of IIS Manager. For me, it gives an error for the test version, stating: "cannot add duplicate collection entry of type 'error'". This refers to the error nodes in the httpErrors section of web.config and applicationHost.config, so I think it might be related to that. Maybe a nice conundrum for a rainy day.
We have a website which has a Virtual Directory containing the secure portion of the website.
If users come to http://www.mydomain.com, they should get directed to default.aspx of the main site, but if they go to https://www.mydomain.com, they should go to default.aspx of the virtual directory.
The default page for the main site works fine, as does the secure page if I navigate to it using the full name, however I can't figure out how to set the default page for https traffic that doesn't specify a specific page.
http://www.mydomain.com - Works
https://www.mydomain.com - Page Not Found
https://www.mydomain.com/myvirtualdirectory - Page Not Found
https://www.mydomain.com/myvirtualdirectory/default.aspx - Works
What do I need to do to make links 2 and 3 load the default page show in 4?
My website is running on IIS 6.0 in Windows Server 2003
Overall, this is an anti-pattern as you state the entire behavior of the site changes based on the port. I am not stating definitively you are doing this, but consider the following:
If you are redirecting due to a user needing to see other things, you can make conditional controls that display only when in HTTPS. The same can be done for authenticated and authorized versus not.
If you are redirecting because an HTTP user needs to log in, the more consistent pattern is to have them click a log in button. And, you can force HTTPS at this point without breaking the pattern.
If you really need to redirect for some reason, there are a couple of ways of handling this:
In IIS
HTTP Handlers
URL Rewrite - requires the URL Rewrite bits for IIS 7
I imagine there are some other ways to solve this.
I finally figured out my issue. In my case, it turns out the problem was an old URL Rewrite rule I wasn't aware of that was transferring all https traffic that didn't have a file name specified to index.php, which of course didn't exist.
I found this out by viewing the IIS error logs, which was telling me the 404 was being caused by index.php
I'm developing an ASP.NET web site with VB. My web site is work perfectly with Firefox. But, with IE, it's redirect automatically to null.
When I try
http://localhost/mysite/Default.aspx
IE6/IE7 automatically redirect to
http://localhost/mysite/null
But, there is no problem with pages inside sub folders. When I try with
http://localhost/mysite/forum/
It's work perfect. I just can't browse pages in root folder.
What should I do? I'm using IIS7 and .net framework 2.0.
Thanks
Huh... that's strange. "null" isn't really a normal place for web traffic to get redirected. Can you think of anywhere in your code/IIS settings that might redirect to a page called "null" Also strange is the firefox/ie difference.
Does it have something to do with authentication? IE might have automatic Windows authentication causing your application to behave differently because it thinks you are logged in. Try turning off Windows Authentication in IIS.
Alternatively, can you debug your code? Does any code execute on your home page before the redirect occurs?
First uncheck the show error frinedly message in the internet explorer in tools->Internet OPtions->Advance then see.
Another thing if you are redirecting with some dynamic link? And that is casuing it to redirect on null.
Check your code. I think that there may be some problem in your code.
I'm using the ASP.NET Login control and have been doing so for a couple of years on a particular site with success. Out of the blue, in the dev environment, this control has stopped working and is now bouncing me back to the login page.
Using source control I've reverted recent changes that might have been the cause but no luck. I've stepped through the code and have checked that the e.Authenticated property is correctly being set to true and that the ReturnUrl is correctly specified on the params.
Any ideas about where to look next to try and figure this out?
After logging in are you being redirected to a page that you don't have authorisation for?
I would check the following...
Cookies still set in the browser
SSL settings in conjunction with http
not forwarding onto https
Cert issues (old, new, expired)
Changes in the domain that the user
is authenticating to
Essentially, check everything except
your code, it works like you said.
;-)