Hi Ken, Jimmy!
Here are some good links I found discussing the issue, which stood out: http://forums.iis.net/t/1119896.aspx (see last reply) http://www.unfocus.com/projects/2009/04/01/responseencoding-in-iis7-for-static-html-files-in-webconfig/ http://learn.iis.net/page.aspx/508/wildcard-script-mapping-and-iis-7-integrated-pipeline/ This is what I’m led to believe For performance critical applications, Static files, public, no auth/author: * No processing or custom MR routing needed, serve using <add name="StaticFile" path="*" verb="*" modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule" resourceType="Either" requireAccess="Read" /> from %windir%\System32\inetsrv\config\applicationHost.config * Remove non-static modules using http://learn.iis.net/page.aspx/136/install-typical-iis-workloads/ and have a bunch of server for ONLY static. * Use StaticCompressionModule <add name="StaticCompressionModule" lockItem="true" /> * Alt. use a light web server (for ONLY reading the static file), say apache http://en.wikipedia.org/wiki/Comparison_of_web_servers Beware the IIS buffers a few of the static requests before flushing [“IIS7 will by default buffer responses for most content types, including ASP.NET, ASP, static files, FastCGI/PHP, etc.”; Mike Volodarsky] , so it doesn’t flush early (see http://www.amazon.com/dp/0596529309?tag=stevsoud-20 <http://www.amazon.com/dp/0596529309?tag=stevsoud-20&camp=14573&creative=327641&linkCode=as1&creativeASIN=0596529309&adid=1S1KP4EV129EN37422C0&;> &camp=14573&creative=327641&linkCode=as1&creativeASIN=0596529309&adid=1S1KP4EV129EN37422C0& and http://www.stevesouders.com/blog/2009/05/18/flushing-the-document-early/ ) This is something I’ve felt like looking into for MR, too. For performance critical applications, Static files, authorized: * http://learn.iis.net/page.aspx/142/understanding-iis-7-url-authorization/ * You can use the FileAuthorizationModule in IIS7. * For IIS6 I’m much less sure; I think because it only maps to file extensions, it will serve static files unless something like this is specified: <location path="config"> <system.web> <authorization> <allow roles="Administrator"/> <deny users="*"/> </authorization> </system.web> </location> * If you need to authorize using a custom security framework, e.g. Rhino’s version, then you can build something similar to this as a httpmodule which, under integrated mode in IIS7 will work the same way; with caching of permissions/operations/users/usergroups/entitykeys this should be fairly quick as well, and you might as well remove the fileauthorizationmodule using <remove …/> imo, because the url parsing can be made to cover it. * Place this in IIS 7, at the very bottom, below MR handler and default/fail to find a handler with MRHHF: “If I understand TheDean's requirements correctly, he wants to handle requests that are rejected by 404 on the server. This typically cannot be accomplished in PreBeginRequest or any other event prior to ExecuteRequestHandler, which is where a handler normally makes the determination of whether the needed resources exist / can be served” – So having MR fail with a module in IIS7 here, would probably cause static content to be served (given the static handler is below and for path=”*”, MRHHF. * There will be problems if you catch (many different types of) static requests yourself and have your own static file handler when it comes to mime-types, unless you either manually read the already registered mime-types from applicationHost.config or is very diligent in mapping them out. Generally: * Doing testing on the web dev server myself, it’s enough to a module (not http handler factory) to choose not to write to the response for it to be noted as “dormant” or not having consumed the request. There’s a problem here if you want to serve static files yourself with your own static file handler because you 1) bypass the static compression in IIS7 and 2) can bypass security measures unless you’re careful, 3) managed can here be slower than IIS7’s native. You can specify this sort of stuff in IIS7: <requestFiltering> <fileExtensions allowUnlisted="true" applyToWebDAV="true"> <add fileExtension=".asax" allowed="false" /> Which would allow you static file handler serving all requests not served from the MRHHF. Again though, I haven’t tested this enough. * Personally, I would like the ability to route requests for static files. The routing in MonoRail allows for this, because the routing module catches all requests (unless another module handles it first), so we can route them/rewrite the url for them or even rewrite some of the contents. If MRRouting rewrites the url (with or without client url being rewritten), the static file handlers won’t catch it (it’s now rewritten), so in my case, my derivative of MRHHF handles those using the subclasses of BaseRouteMatch and can provide the accurate handler. * For ASPX files, I use this code: if (match.IsAspx) { return PageParser.GetCompiledPageInstance(url, pathTranslated, context); } Allowing me to rewrite static files or override them in the routing specification. * There’s a new routing module in IIS7 but I haven’t checked that out extensively. I added regex routes though, which works nicely with the programmatic interface for System.RegularExpressions. Dynamic files: IMO, to your security concern; I don’t think it’s so bad to bypass MR logic since it doesn’t provide much for authorization anyway besides filters on actions, contrary to httpmodules which tie into not only ASP.Net apps, but also e.g. PHP apps should you go that way, in integrated pipeline mode. Here’s a better place to put the authentication and authorization if you’re writing it custom. A case could also be made, that if you’re uploading you’re probably doing so into a specified folder, where if that file was requested and its path known and it is not caught in an authorization http module talked about above, would be sent to the client browser. Potentially you can break the app by having the script upload to similar paths as the controller.action notation, gives you (instead of /), but would this introduce holes? I don’t really understand your concern here; would you care to explain a bit more on it, please? I’m going to read a bit more about this so I know exactly what’s going on with both IIS 7 and IIS 6. Also, I’m going to do some profiling on the routing with different options to check out what’s best. Also, I’m not happy with my current API, so I’m going to improve on that. Regards, Henrik From: [email protected] [mailto:[email protected]] On Behalf Of Ken Egozi Sent: den 20 maj 2009 19:37 To: [email protected] Subject: Re: robots.txt and sitemaps with routing 1. isn't it better to have static files not reach MRHHF at all? 2. I really don't like the "if there's a real file, do not process MR logic". on many occasions, when server is not secured correctly, a loophole allows an attacker to upload files (not change or delete, but add) to the site. now if you have a url that triggers an MR action under "someurl.anextension", and you use the "if there's a file bypass MR", all an attacker needs to do is to upload a malicious markup file named someurl.anextension, and you're in really big trouble. This kind of attack have happened to me and to people I know on several shared hosting scenarios. Usually the attacker adds the common default documents (index.htm) for that, and I solved that problem by removing all default documents from the IIS. however the said scenario will open up a whole new bunch of attack surfaces. On Wed, May 20, 2009 at 9:06 PM, Henrik Feldt <[email protected]> wrote: Yes, it's a part of it, but if monorail also has a hit on the url which has a static file, you can override the static file with the routing. I moved a lot of knowledge from the http handler to the routing module. Currently, routingmoduleex: if (File.Exists(request.PhysicalPath)) { return; // Possibly requesting a static file, so we skip routing altogether } But path="*" on mrhttphfac means it will try to find a controller for it anyway. Instead of doing this in routingmoduleex I'm returning a route with a property isstaticfile which then the mrhandler delegates to a static file handler. Because the handler fac originally was written under the assumption it won't get static requests, it tries to find a controller/action for this, which obviously fails causing this annoying exception you mailed about before. I'm still in the testing stages for this, because what I'm after is the dynamic content compression in iis7 and I'm not sure how returning a custom handler for static files affects this. I extended the classes with a base class and different types of routing matches. Regards, Henrik -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jimmy Shimizu Sent: den 20 maj 2009 14:54 To: [email protected] Subject: Re: robots.txt and sitemaps with routing What do you do when matching a static file? Do you explicitly check the filesystem for existance? I think I'd still keep my static-folder for content that always will be static (to avoid unnessecary processing of files through MR), but for certain root-files this approach isn't applicable. Henrik Feldt wrote: > Hello Jimmy, > > What I did, was to modify the routing in the routing module and also > add a property "IsStaticFile" on the RouteMatch, so that the routing, > which is responsible for rewriting the url, checks for static files, > rather than letting MRHttpHandlerFactory do it. What MRHHF does is to > check if the route is for static. > > I also made the routing aware of the controller tree, because in my > opinion there's no use in routing to mr handlers if there's no > controller/action for the route anyway; then we might fail with > ASP.Net's error handling (+ being able to set 404 pages through web > admin API in IIS7, or error handlers in web.config in iis6) like > default and save ourselves the trouble of mapping every single file extension manually in Web.config. > > Regards, > Henrik > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Jimmy > Shimizu > Sent: den 20 maj 2009 12:22 > To: [email protected] > Subject: Re: robots.txt and sitemaps with routing > > > I'm using RoutingModuleEx, basic MonoRail routing that is mapped like this: > > <add name="MonoRail" path="*" verb="*" > type="Castle.MonoRail.Framework.MonoRailHttpHandlerFactory, > Castle.MonoRail.Framework" preCondition="integratedMode"/> > > I was under the impression that with this approach, static files are > never handled correctly. If that is not the case, I'd love to hear > about the solution :) > > I get Url smaller than 2 tokens if I try to request a static file. > > Jokin Cuadrado wrote: > >> What routing are you using? >> >> the one i use check if a file exist before handling the dynamic url, >> so just put a static robot.txt in the root and it will work. >> >> >> On Mon, May 18, 2009 at 12:01 PM, Jimmy Shimizu >> <[email protected]> >> > wrote: > >> >> >>> How do you guys solve the issue with files that are supposed to be >>> found directly under the siteroot when using advanced routing >>> (meaning, catching * with Monorail)? >>> >>> I was planning on using a specific controller that servers >>> robots.txt and sitemaps dynamically, but when someone needs to >>> verify for example domain-ownership with analytics or webmastertools >>> or such, how do you handle that? >>> >>> >>> >> >> >> > > > > > > -- Ken Egozi. http://www.kenegozi.com/blog http://www.delver.com http://www.musicglue.com http://www.castleproject.org http://www.gotfriends.co.il --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en -~----------~----~----~----~------~----~------~--~---
