Last post Jun 13, 2017 06:34 PM by Ken Carter
Jun 08, 2017 08:25 PM|Ken Carter|LINK
I'm Scratching my head here because after doing an update to a web app that sits in the sub structure of one of our internal sites, I'm getting a 404 errot. Despite verifying and making sure that I was following the same process I had used prior to this
This illustrates the above:
Now, to make sure I've provided as much insight into things that are unique in this publish vs others that were successful and rendered the expected results consistently till now:
1.This server (a dev/test box) was moved to a new domain week before last along with it's production counterpart and the database server that each web server talks to for the web applications hosted on them.
2.For expediency this server was cloned to the production site as we had a clean, current, and successfully tested deployed version of the core site on the dev/test box.
3.While it wasn't a change, I am unsure if it would have a certificate that was on the box would have an impact on the ability to successfully publish future updates on the same server in the new domain.
4.In addition to item #3 I'm further baffled that if this is being caused why is that that existing apps on both the production server and this dev/test box continue to function as they would be expected to. It was only the act of publishing the update that resulted in this behavior. So this would seem to suggest to me that the issue has something to do with changes made during the publish (which has not been altered from prior publishes).
Any thoughts on this that can aid me in getting this resolved greatly appreciate.
Jun 08, 2017 10:03 PM|mgebhard|LINK
A 404 is a file not found error and has nothing to do with authentication.
Have you verified the file exists? If the URL is does not specify a specific file, do you have a index.htm or defualt.aspx file in the directory?
Jun 08, 2017 10:11 PM|Ken Carter|LINK
Jun 08, 2017 11:44 PM|mgebhard|LINK
As I stated, the publish was successful and yes I verified the files were there. Unfortunately the 404 does not tell me what file it is looking for.
The URL in the browser's address bar shows the requested URL.
Jun 09, 2017 01:55 AM|EvenMa|LINK
Hi Ken Carter,
According to your description, your site occurred 404 error, I think in your case, might that’s mean the site couldn’t find the default document.
1:check web.config whether specify default document.
If yes, make sure the default document had been exists in your site.
2:Check default document in your IIS.
Open IIS, in the feature view of site, then double click on "Default Document", make sure the file in default document list had been exists in your site.
3:if you used authentication, make sure the login path which you specified had been exists in your site
If you have any other questions, please feel free to contact me any time.
Jun 09, 2017 02:22 PM|Ken Carter|LINK
Went down through your check list and still have the same results. Default.aspx is in the folder where it belongs. I modified my web.config per your direction to point to it. Then checked my IIS configuration for the web app to see what was in default
documents and default.aspx was the only thing there. So I reverted to the parent so as to duplicate what is the configuration of my other web apps on this site.. Still 404'd.
Surely there is a way to identify what file/folder it is 404'ing on so that I'd have that to investigate. I'm doing some searches now to see if there is a way to modify the 404 to be more verbose.
Jun 09, 2017 02:31 PM|mgebhard|LINK
Are you using a browser to view the site? If so, just look in the address bar. Or open developer tools (F12) and look at the request. You can see the URL the browser is sending to the site as well as any 302 redirects.
Jun 09, 2017 04:28 PM|Ken Carter|LINK
Jun 09, 2017 05:41 PM|mgebhard|LINK
You are stuck in a redirect loop due to the authentication configuration. In my experience this does not cause a 404 it causes an redirect error so you must have changed something.
Maybe you really want forms authentication and not basic authentication? What authentication does your site use?
Jun 09, 2017 05:58 PM|Ken Carter|LINK
This app is set exactly like the other ones I have published and the way this one was setup as well (prior to attempting to update it):
Two Authentication elements are enabled -
ASP.NET Impersonation: Set to 'Authenticated user'.
Basic Authentication: Set default domain to our corporate domain.
That is it!
Jun 09, 2017 06:13 PM|mgebhard|LINK
Your explanation does not sound right. As far as I know,
Basic Authentication and
ASP.NET Impersonation are two different frameworks.
Basic Authentication uses base-64 encoded header that gets populated though a credential modal window that the browser displays when the header does not exist.
Impersonation is based on IIS Authentication where the context of the app is run under a user account.
However, you have a login page? A login page is used in
Jun 12, 2017 03:37 PM|Ken Carter|LINK
It sounded screwy to me too but what I found was the only way that pass through authentication would work was to set it up in that manner. Bare in mind that THIS WORKS on the production apps I have deployed and in all but this app on my dev/test box. It
was only when I went to update this app that any problem took place.
Now, I've been informed that they are going to make another major change that will impact my web servers this week as part of our domain separation project, so I'm not going to force this for a few days till that has taken place. Otherwise, might likely
find myself refixing the same web app later in the week. I'm opting for one fix vs two. I'll update more when I get to that point later this week.
Jun 13, 2017 08:17 AM|EvenMa|LINK
According to your description, that is a redirect loop exception.
Might the login action in account controller using [AllowAnonymous] such like the following code.
public ActionResult Login(string returnUrl)
ViewBag.ReturnUrl = returnUrl;
And you was disabled the Anonymous Authentication in IIS(see the picture in your first post), they will conflict.
At first, when you open the site in browser, the site will redirect to the login page, the login page is allow anonymous, and in IIS, you was disabled the Anonymous Authentication, then the site couldn’t get the anonymous user, and then redirect to the login
page again, so there will be the infinite loop.
So in your case, you could enable the Anonymous Authentication in IIS.
Jun 13, 2017 06:34 PM|Ken Carter|LINK
I turned on Anonymous but that resulted in another error (authentication to the SQL box), so I'm working to see about clearing that. The thing is we didn't want to have to filter people as this app (and my others) are all authenticated using Active Directory
But this is giving me things to look into to try and correct it.
What really doesn't make sense to me (I get what you're saying about the loop) is that I have other apps configured and deployed exactly the same setup and they work flawlessly. This one did as well until I went to update it with some new features.