2

I have a custom IHttpHandler, specified in web.config as follows:

<httpHandlers>
  <add verb="*" path="*.html" validate="true" type="PipingRedirectHandler" />
  <add verb="*" path="*.htm" validate="true" type="PipingRedirectHandler" />
</httpHandlers>

In IIS 7 (on Win 2008 R22) I added handler mappings with Path: *.html/*.htm and executable: %windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll.

I also have a virtual directory mapped to a windows share on another machine, Alias: ClientFiles, Physical path: \\othermachine\ClientFiles. I have this virtual directory set to "Connect As" a domain user that has full control access (read, write, execute, etc.) to the share, but everything else about the website, the app pool identity, the connect to physical path of the rest of the site, etc. are all default (ApplicationPoolIdentity).

My IHttpHandler works fine with any local html files on the website, and all my css and images on the ClientFiles virtual directory work perfectly, too. The only problem is when I'm trying to read a html file from the virtual directory. I get HTTP 401 Unauthorized errors when trying to do so.

I figured it was that the local ASP.Net ISAPI was trying to load the file directly and not honouring the "Connect As" setting for the virtual directory, so I changed the app pool's identity to the same domain user that has access, and everything seems to work.

I'm just wondering:

  • Is this normal?
  • Why would it not use the user specified in the virtual directory settings?
  • Have I worked around the problem in an appropriate way?

I believe security is slightly diminished by setting the app pool to use a domain user, and would prefer not to.

mo.
  • 4,165
  • 3
  • 34
  • 45
  • I've been banging my head against this same exact issue all day. Did several searches before this page came up. Posted here on SO and got zero responses, like you. However, changing the AppPool identity was the only solution that let my handler get called. I made sure the connect user had permission, and never would have thought of the AppPool identity. Mille Grazie! – mdisibio Jan 08 '13 at 23:12
  • Cool. I'm glad the information helped. Like I alluded to above, I hope I haven't contributed to there now being a large security hole in your app :O – mo. Jan 09 '13 at 20:12
  • ApplicationPoolIdentity is per machine. So it makes sense that if its requesting from the original server that right won't exist on the UNC load. I'm not sure what PipingRedirectHandler is. My guess is that is either not handling the request or it is but the way it handles it is internal (loading the file itself) instead of sending a client HTTP redirect to the other virtual directory site. What does a client debugger like Firebug or Fiddler show? Is it sending a client redirect or trying to serve the file directly itself? – Jon Adams Oct 28 '13 at 17:45

0 Answers0