We have one module which does internal redirection to real aspx pages. He is also in charge for directly serving cached/compressed HTML/txt/cs/js output to client.
Here is how web.config looks like for modules section:
<modules runAllManagedModulesForAllRequests="True">
<remove name="RequestInterceptor" />
<add type="Lib.Request.RequestInterceptor" name="RequestInterceptor" />
<remove name="Session" />
<add type="System.Web.SessionState.SessionStateModule" name="Session" />
</modules>
Basic authentication is turned on on IIS7. When first visitor comes to site login popup shows and he is correctly authenticated, and then pages which he visits get cached.
When next visitor comes authentication pop up doesn't show up, unless he visits a page which was not visited by previous visitor (page that is not cached). Once the cache has expired, authentication works again until the page content gets cached, and so on.
Is there a way to force authentication for every visitor? Maybe we need to add basic authentication module to module section of web.config (how to do that)?
Thanks in advance.
Cheers
While searching for an answer to a related question I came across this post:
Don't use runAllManagedModulesForAllRequests="true" when getting your MVC routing to work
It seems to be common advice to make your modules section of your
web.config say . In
fact this is quite a drastic thing to do to solve the routing problem
and has global effects that could CAUSE ERRORS. ... This highly
recommended fix can cause other problems. These problems come in the
form of making all your registered HTTP modules run on every request,
not just managed requests (e.g. .aspx). This means modules will run on
ever .jpg .gif .css .html .pdf etc.
And, while I'm not using MVC in my WCF REST Service, it did fix my (other) problem and this advice against inappropriate or overuse of runAllManagedModulesForAllRequests may be warranted.
Because httpmodule intercepts each request, server is not able to map appropriate handler for static files, dynamic files, and among others secuirty authentication.
Related
I have an old asp.net (non-core, non-mvc) https webapp which has a number of IHttpHandlers which serve files using a setup in my web.config like so:
<system.webServer>
<handlers>
<add name="DocumentAttachmentHandler"
path="*/Secure/DocumentAttachment/*/*/*/*/*.*"
type="[company].[product].WebApp.AttachmentHandlers.DocumentAttachmentHandler, [company].[product].WebApp"
verb="GET"/>
I want to add a new handler that is localhost only (only accessible internally) and is http instead of https.
This is what I added:
<add name="MyFileHandler"
path="*/Public/My/*/*.*"
type="[company].[product].WebApp.AttachmentHandlers.MyAttachmentHandler, [company].[product].WebApp"
verb="GET" />
But my breakpoint in the handler doesn't hit when I call:
http://localhost:44300/[product]/Public/My/[fileId]/[filename].[ext]
...because my webapp is https. It does hit when I change my entire webapp to http, but I obviously can't leave it like that ;-)
I tried setting path="http://localhost:44300/[product]/Public/My/*/*.*" and adding allowPathInfo="true" ...but that didn't work.
All my web searches return telling me how to make something secure, when I want to make mine less secure (sort of).
Please can someone tell me how I should go about doing this?
IIS Express is producing 403.14 Forbidden errors when a URL that would otherwise be handled through ASP.NET URL routing happens to correspond to a physical folder in my ASP.NET project. (The folder contains only code, and it's coincidental that the folder name happens to match the URL of a page; my URL structure is determined dynamically by a database, and users can edit that structure, so although I could just rename my project folder, in general I can't prevent this sort of collision occurring.)
This seems to be happening because the DirectoryListingModule steps in to handle the request, and then promptly fails it because directory browsing is disabled. I've tried removing this:
<system.webServer>
<handlers>
<remove name="StaticFile" />
<add name="StaticFile" path="*" verb="*"
modules="StaticFileModule" resourceType="Either" requireAccess="Read" />
</handlers>
</system.webServer>
That removes the default StaticFile handler configuration, which has modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule", and replaces it with a configuration that provides just the feature I want. (I want static file serving, but I have no need for directory listing or default documents in this app.) But the effect seems to be that IIS then produces a completely empty (0 byte) response (with a 200 status) when I hit the offending page.
So next, I tried configuring the StaticFile handler to handle only the specific physical folders that I want to make available:
<system.webServer>
<handlers>
<remove name="StaticFile" />
<add name="StaticFileCss" path="style/*.css" verb="*"
modules="StaticFileModule" resourceType="Either" requireAccess="Read" />
<add name="StaticFileScripts" path="Scripts/*" verb="*"
modules="StaticFileModule" resourceType="Either" requireAccess="Read" />
</handlers>
</system.webServer>
But when I hit the offending URL, this then produces a 404.4 - Not found error, with a message of The resource you are looking for does not have a handler associated with it.. (The Detailed Error Information on the error page says that we're in the IIS Web Core module, during the MapRequestHandler notification, the handler is Not yet determined, and there's an Error Code of 0x80070002, which is a COM HRESULT that corresponds to the Win32 ERROR_FILE_NOT_FOUND error.)
The mystifying thing is that it's not even bothering to ask ASP.NET whether it has a handler for it. IIS seems to be deciding all by itself that there definitely isn't a handler.
This only happens when there's a folder that matches the URL. All other resources with dynamically-determined URLs work just fine - IIS asks ASP.NET for a handler, ASP.NET's routing mechanism runs as normal, and if the URL corresponds to one of my dynamically defined pages, it all works fine. It's just the presence of a physical folder that stops this all from working.
I can see it's IIS doing this because I get one of the IIS-style error pages for this 404, and they have a distinctive design that's very different from the 404s produced by ASP.NET. (If I try to navigate to a URL that neither corresponds to a physical folder, nor to a dynamic resource, I get a 404 page generated by ASP.NET. So normally, IIS is definitely handing requests over to ASP.NET, but IIS is definitely getting in the way for these problematic resources.)
I tried adding this inside my <system.WebServer>, in case the problem was that IIS has decided that requests corresponding to physical folders do not meet the managedHandler precondition:
<modules runAllManagedModulesForAllRequests="true">
But that doesn't appear to help - it still doesn't get ASP.NET routing involved for URLs that correspond to physical folders. In any case, it would be suboptimal - I would prefer not to have managed handlers run for the content that I definitely want to handle as static content. I effectively want ASP.NET URL routing to be used as a backstop - I only want it to come into play if the URL definitely doesn't refer to static content.
I don't understand why ASP.NET isn't even asking ASP.NET what it thinks in this scenario. Why is it not calling into ASP.NET during the MapRequestHandler phase if there's a physical folder that happens to correspond to the URL?
When a physical file or folder with the same URL as the route is found, routes will not handle the request and the physical file will be served.
Althrough you can change this behavior by setting the RouteExistingFiles Property from the RouteCollection object to true.
Take a look at the MSDN page Scenarios when routing is not applied
I have a pretty standard asp.net web api set up with get post put and delete. I am hosting on discountasp.net. Works great for all verbs on localhost, when I deploy, only get and post are working. I have read just about every question regarding this topic, I have made sure that WebDav is disabled, and make sure my handler mappings are accepting the right verbs, and I and STILL get a 405 error.
Anyone know what the problem might be? It is mvc4 asp.net web api, pretty much out of the box, and I am using ajax on a single cshtml page to interact with all the verbs. My web server is iis7.
So turns out it was a simple web.config change. Dont know why alot of the walkthroughs had me going into iis and messing with handlers and all that good stuff. I added this to the modules section of web.config and it works like a charm now:
<system.webServer>
<modules … >
<remove name="WebDAVModule" />
……
</modules>
In my ASP.NET app, I have two HTTP modules. One of them is used for rewriting URLs, the other is used for app-specific stuff (custom authentication .. etc). The URL-Rewriting module is executed for all requests, while the other module is only executed for managed file extensions, like .aspx
Here's how the modules are defined in web.config (note that preCondition is blank for UrlRewriteModule. This cause it to get executed for all requests):
<system.webServer>
<modules>
<add name="UrlRewriteModule" type="MySite.UrlRewriteModule" preCondition="" />
<add name="SiteModule" type="MySite.SiteModule" preCondition="managedHandler" />
</modules>
</system.webServer>
In UrlRewriteModule I use RewritePath() to rewrite some URLs (directory-like) into files with query strings. For example, from "/p/5/some-thoughts-about-the-future/" to "/post.aspx?id=5"
Now, I was under the impression that when a URL gets rewritten, IIS7 executes the managed module (SiteModule in this case) if the new URL is for a managed extension (like .aspx). But, this doesn't seem to be the case. I noticed that SiteModule doesn't get executed for any rewritten URLs.
Am I missing something (or doing something wrong) or is this the normal behavior in IIS7?
I came across Server.TransferRequest() which actually solves the problem (behind the scence, it involves creating a new child request). But, this can also cause a lot of overhead esp. under server load, and I generally prefer to avoid it.
So, is there a way to get SiteModule to execute whenever a URL gets rewritten without using Server.TransferRequest()?
Thanks!
I've got a website running under ASP .NET 2/IIS7/Vista. I have a URL rewriting module which allows me to have extensionless URLs. To get this to work I have configured the system.webServer section of the config file such that all requests are forwarded to the aspnet_isapi.dll. I have also added the URL rewrite module to the modules section and set runAllManagedModulesForAllRequests to true.
When I start up the website and visit one of the pages that uses the URL rewriting, the page is rendered correctly. However if I then visit another page the site stops working and I get a 404 not found. I also find that my breakpoint in the URL rewriting module is not getting hit. It's almost as if IIS forwards the first request to the rewriter, but subsequent ones go somewhere else - the error page mentions Notification as being MapRequestHandler and Handler as being StaticFile.
If I then make a small change to the web.config file and save it, triggering the website to restart, I can then reload the page in the browser and it all works. Then I click another link and it's broken again.
For the record, here's a couple of snippets from the config file. First, under system.web:
<httpModules>
<add name="UrlRewriteModule" type="Arcs.CoopFurniture.TelesalesWeb.UrlRewriteModule, Arcs.CoopFurniture.TelesalesWeb" />
</httpModules>
and then, under system.webServer:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add name="UrlRewriteModule" type="Arcs.CoopFurniture.TelesalesWeb.UrlRewriteModule, Arcs.CoopFurniture.TelesalesWeb" preCondition="managedHandler" />
</modules>
<handlers>
<add name="AspNet" path="*" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="None" preCondition="classicMode,runtimeVersionv2.0,bitness32" />
</handlers>
<validation validateIntegratedModeConfiguration="false" />
</system.web>
The site is running under classic rather than integrated pipeline mode.
Does anyone out there have any ideas? I suspect my configuration is wrong somewhere but I can't seem to find where.
This is a bit of a long shot, but have you tried actually making the configuration changes inside of IIS?
I know that the web.config way is supposed to be 100% foolproof, but I've seen a few things where it helps to just configure it in IIS to get it working correctly.
You also may want to check out the new IIS7 rewrite module. you can read more about it here http://learn.iis.net/page.aspx/460/using-url-rewrite-module/, but chances are it will be more solid then your homegrown ISAPI filter
Try http://www.codeplex.com/urlrewriter it supports all the Apache mod_rewrite syntax and also supports Reverse Proxy.
If you're runnning in classic pipeline mode you don't need <system.webServer> section it is required for integrated mode
Enable wildcard script mapping
Open the IIS7 Manager and navigate to your site
Click on Handler Mappings
In the Action panel click on "Add Wild Card Script Map"
In the dialog point to aspnet_isapi.dll
Click Yes on the message box that asks you to confirm your mapping
In the action panel click on "View Ordered List" and move your WildcardScriptMap just before StaticFile Handler
This should bee enough.
I'm ashamed to admit this but it was a simple mistake by me :-(
In my URL rewriting module, the code to rewrite the request path was in the Init method, when it should have been inside an Application.BeginRequest handler. This explains why the rewriting worked only the first time the site was hit.
Sorry to have wasted your time people!