I have two virtual servers from two different hosting companies. Publishing the same MVC3 site on each server produces different results for a folder that is supposed to be protected by forms authentication. The files are of various extensions.
On one server, requesting the file redirects the user to the login page (correct behaviour for our app) but the other allows the downloads.
Both web.config files are the same for everything that's relevant as far as I can see, so where does this get set?
TIA
Is the file type (for example somefile.xyz) mapped to asp.net or are you running an older version of IIS or in classic mode?
if .xyz is not mapped to asp.net then IIS will allow the download (in some cases - unknown extensions depending on the version of iis will result in a 404 for security purposes)
Are they different versions of IIS? If one is setup for classic mode (the worker process) or its an older version of IIS (6 for example) the file request won't funnel through IIS unless you setup a wildcard mapping.
If it is running in integrated pipeline mode, then it will funnel through IIS and you would see the login (assuming users, auth, and forms auth are setup correctly)
Related
I have a few older ASP .Net Framework (web forms and mvc) sites on an IIS server which run in an app pool which uses a custom AD account. Serving any static files (images, js, css) from the Content folder of the site has always worked fine - but this began failing a few weeks ago. All requests for static content return a 500 error. The dynamic content still runs fine. When I switch the app pool to use the built-in ApplicationPoolIdentity, then the static content is returned fine. I verified that the custom AD account has read access to the static files on file system. There are no messages in the event log and the IIS logs only show the 500 response with no details. As this works fine using the built-in account, I am assuming the static file handler is still installed and running as expected.
Any thoughts on what may have changed, what would cause static files to fail for custom accounts only, or where I can look for more details on the error IIS is encountering?
EDIT: After further testing, I find that using my personal AD account for the app pool allows the site to serve static files. So guessing the issue relates to the custom account's privileges in some way?
So, thanks to the link from Lex Li above, I was able to enable failed request tracing and this pointed me to an authentication error - "Either a required impersonation level was not provided, or the provided impersonation level is invalid. (0x80070542)" By adding the custom AD account for the app pool to the local Admin group on the server, the issue was corrected.
I have deployed my ASP.NET web application on IIS (windows 2008 server). I have created a virtual directory (named TestApp) and all the users on local area network are accessing it with the following URL.
http://"SERVERNAME"/TestApp/Default.aspx
My client wants that, it should be accessed as following URL
http://"SERVERNAME"/Default.aspx
There is single application deployed on the server.
Could you let me know how can i implement this thing??
Instead of adding a virtual directory on the existing site, you need to add a new web site
Create a Web Site (IIS 7)
In fact, it's fairly simple.
Remove your current app, including all files and settings in IIS (i.e.: delete everything).
Run the deploy wizard again, BUT be carefull of the path that it's given to your application: by default, you should see "http://SERVERNAME/TestApp/". Remove "TestApp". The wizard will show you a warning message, just continue.
Finish the wizard as usual, and voila!
I did this 2 or 3 times yet.
My host is having issues getting my MVC3 app to work on their server, so I though I'd check it out myself. Until now I've been too busy developing under the built in server to worry about IIS, but today I tried my first deployment to the host with no joy. Then I tried one to my local IIS, with no joy. Then I tried telling VS to use IIS for debugging, to maybe resolve some local issues, with no joy.
What steps and configuration are required to use local IIS 7.5 to debug an MVC3 application?
EDIT: Going through a browser, after clearing up a permission problem for my Windows user on Temp ASP.NET Files, I now site with a I get a HTTP Error 403 (Forbidden), but the occassional basic auth login dialogue. Here I have tried a Forms auth user, my normal Windows user, and my Windows admin user, all to no avail.
When I try and debug under VS, I get a 500, internal error.
THE PLOT THICKENS: When I enable directory browsing on the site, I get a proper directory listing for the site root url. This suggests the the MVC3 routing is not working, but why not?
If you're getting a directory listing that means there's not a default file set (for IIS6). It usually means the request wasn't routed to IIS to deal with. thing are slightly different with II7 & it's integrated pipeline.
Simon
Here's my scenario:
Using SQL Server sessions (due to web farm)
customErrors is On using redirect
There is a membership provider that uses sessions to store user information
In web.config, there are <location> sections that <allow users="*">. This is used for static content (e.g. images)
Whenever I try to access the error page or even static content, the session tries to start up (probably due to membership provider). If the SQL Server is down, that throws an exception.
Is there any way to prevent the membership provider and/or sessions from trying to initialize when I'm accessing certain folders (i.e. static content)?
It turns out most of my problem is because of differences between IIS6, IIS7, and the development server:
http://www.asp.net/hosting/tutorials/core-differences-between-iis-and-the-asp-net-development-server-cs
In IIS 6, ASP.NET only runs for extensions that are configured under Site properties > Virtual Directory > Configuration > Mappings > Application extensions. For example, .aspx points to aspnet_isapi.dll. Static content will not go through the ASP.NET by default.
In IIS 7, it's similar (under Handler Mappings), however thanks to the new integrated pipeline, in the web.config you can also have static content check for authentication. See Performing Forms-Based Authentication and URL Authentication on Static Files with IIS 7 in the URL above.
Also based on the above URL, in the ASP.NET Development Server (based on Cassini):
Every request that comes into the
ASP.NET Development Server, whether
for an ASP.NET page, an image, or a
JavaScript file, is processed by the
ASP.NET runtime.
Today we tried to put an ASP.NET application I helped to develop on yet another production machine. But this time we got a very weird error.
First of all, from all the ASP.NET pages, only Login.aspx was working. The rest just show a blank screen when they should have redirected to Login.aspx. The HTTP response is 200, but no content.
Even worse - when I try to enter the address of some inexistent ASPX page, I also get HTTP 200! Or, when I enter gibberish in some existing ASPX page code (which should have been accessible without login) I also get HTTP 200.
If I enter the name of some inexistent resource (like asdasd.jpg), I get the expected 404.
The redirect to login page is written manually in Global.asax. That's because the application has to use some alternate methods of authentication as well, so I can't just use Forms Authentication. I would suspect that Global.asax is failing, if not for the working Login page.
Noteworthy facts are also that this machine is both a Domain Controller and has SharePoint installed on it. Although the website in question is listed in SharePoint's exception list.
I would check the following:
Is the application within a virtual application or its own site and not just a virtual directory?
Does the application have it's own App Pool? If it does not then is the app pool shared by apps in a different .net version.
Is the .net version of the application the correct one? 1.1 or 2.0?
Do the files in the file system have the correct permissions to be accessed via IIS?
Have you performed an IIS Reset?
Create a stand alone test.aspx page within your folder that just displays the date/time and check it works.
Make this single test.aspx page perform an exception (eg. divide by zero) and see what the outcome is.
More information required.
What Op Sys?
What mode IIS running under?
What version of .Net?
What version of SharePoint?
(Why are you using your DC as a web host?)
Does it work on the other production machines you've deployed to?
If so what is different between this machine and the working ones?
Did you deploy the same way?
Are you sure your hitting the right machine?
Are you sure your hitting the right web site?
What ISAPI components are installed globally and for the web site?
Is .aspx mapped to the ASP.Net ISAPI filter?
Do you have any HTTP Modules or HTTP Handlers configured?
Can you change the global aspx to write out some messages so you can be sure the piece of code you interested in is reaching?
Anything coming up on the IIS log or the event logs?
Addition:
What version of .Net?
By the sounds of it the .jpg request is being dealt with by IIS directly which is why you get the 404, but the .aspx request is being dealt with by something else which except for you login page, is always returning 200.
Assuming .aspx is wired correctly to .Net the the order of processing is based on ISAPI filters (high to low then global before site), then the ASP.Net ISAPI Extension (sorry I said this was a filter earlier but it's actually an extension). Then we get into the ASP.Net pipeline based on your .Net configs, and calls the HTTP Application (which includes your global.asax code), any HTTP Modules followed finally by a HTTP Handler. Your ASP.Net web forms are just fancy HTTP Handlers.
However, the request can be responded to and terminated from any point.
Since your code works on other machines though, I'm tempted to point a finger at SharePoint if it isn't installed on the working machines. Is this SharePoint 2007? That is also an ASP.Net application (I don't think 2003 was).