404 error after a successful publish

Question

User977421240 posted

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 publish.

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.

Ken...

Answer 1

User475983607 posted

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?

Answer 2

User977421240 posted
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.

Answer 3

User475983607 posted

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.

Answer 4

User1967761114 posted

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.

<configuration>
  <system.webServer>
    <defaultDocument>
      <files>
        <clear/>
        <add value="index.aspx"/>
      </files>
    </defaultDocument>
  </system.webServer>
</configuration>

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.

Best Regards

Even

Answer 5

User977421240 posted

Even,

 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.

Thanks,

Ken....

Answer 6

User475983607 posted

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.

Answer 7

User977421240 posted

https://10.118.164.30/VulTrack/Account/Login?ReturnUrl=%2FVulTrack%2FAccount%2FLogin%3FReturnUrl%3D%252FVulTrack%252FAccount%
252FLogin%253FReturnUrl%253D%25252FVulTrack%25252FAccount%25252FLogin%25253FReturnUrl%25253D%2525252FVulTrack%2525252FAccount%
2525252FLogin%2525253FReturnUrl%2525253D%252525252FVulTrack%252525252FAccount%
252525252FLogin%252525253FReturnUrl%252525253D%25252525252FVulTrack%25252525252FAccount%
25252525252FLogin%25252525253FReturnUrl%25252525253D%2525252525252FVulTrack%2525252525252FAccount%
2525252525252FLogin%2525252525253FReturnUrl%2525252525253D%252525252525252FVulTrack%252525252525252FAccount%
252525252525252FLogin%252525252525253FReturnUrl%252525252525253D%25252525252525252FVulTrack%25252525252525252FAccount%
25252525252525252FLogin%25252525252525253FReturnUrl%25252525252525253D%2525252525252525252FVulTrack%2525252525252525252FAccount%
2525252525252525252FLogin%2525252525252525253FReturnUrl%2525252525252525253D%252525252525252525252FVulTrack%252525252525252525252FAccount%
252525252525252525252FLogin%252525252525252525253FReturnUrl%252525252525252525253D%25252525252525252525252FVulTrack%25252525252525252525252FAccount%
25252525252525252525252FLogin%25252525252525252525253FReturnUrl%25252525252525252525253D%2525252525252525252525252FVulTrack%2525252525252525252525252FAccount%
2525252525252525252525252FLogin%2525252525252525252525253FReturnUrl%2525252525252525252525253D%252525252525252525252525252FVulTrack%252525252525252525252525252FAccount%
252525252525252525252525252FLogin%252525252525252525252525253FReturnUrl%252525252525252525252525253D%25252525252525252525252525252FVulTrack%25252525252525252525252525252FAccount%
25252525252525252525252525252FLogin%25252525252525252525252525253FReturnUrl%25252525252525252525252525253D%2525252525252525252525252525252FVulTrack%2525252525252525252525252525252FAccount%
2525252525252525252525252525252FLogin%2525252525252525252525252525253FReturnUrl%2525252525252525252525252525253D%252525252525252525252525252525252FVulTrack%252525252525252525252525252525252FAccount%
252525252525252525252525252525252FLogi

That's what it is pointing to ^^^
Which would typically indicate a triple hop on the pass through authentication but that isn't the case because the other apps on the same site are going to the same server.

Answer 8

User475983607 posted

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?

Answer 9

User977421240 posted

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
• Basic Authentication

Detail:

ASP.NET Impersonation: Set to 'Authenticated user'.

Basic Authentication: Set default domain to our corporate domain.

That is it!

Ken...

Answer 10

User475983607 posted

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 forms authentication.

Answer 11

User977421240 posted

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.

Thanks!

Ken...

Answer 12

User1967761114 posted

Hi Ken Carter,

According to your description, that is a redirect loop exception.

Might the login action in account controller using [AllowAnonymous] such like the following code.

[AllowAnonymous]
public ActionResult Login(string returnUrl)
{
    ViewBag.ReturnUrl = returnUrl;
    return View();
}

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.

 

If you have any other questions, please feel free to contact me any time.

Best Regards

Even

Answer 13

User977421240 posted

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 credentials.

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.