IIS Server - Managed ISAPI Extension

Author

Managed ISAPI Extension

Frank Postle

2005-12-24, 2:49 am

My reading appears to indicate that there is a bug in the way that IIS
accesses extensions. A unc path (\\?\) instead of a local path, this results
in some sort of security policy exception.

Is this something that is going to be fixed? If it isn't then does anyone
know of a good work around? I have tried to build an unmanaged wedge in
between IIS and the managed DLL. My first look this didn't work either, but
I am going to look at this again.

I have done this before but I have only used assemblies from the GAC and not
managed classes declared locally. I am not sure what is going on here.

I have tested this a bit with "caspol -s off" and there seemed to be an
issue where the static variables within a managed class weren't scoped the
same between the filter and the extension. I have a combined
filter/extension set of dll's (1 unmanaged dll with ext and filter and 1
managed dll with ext and filter). In the filter a static value of a class
isn't the same value. It is as if that there is some sort of scoping that
generates two separate sandboxes in the same apppool (process).

Any help or guidence would be greatly appreciated.

Regards

Frank

Frank Postle

2005-12-24, 5:56 pm

Okay. I have gotten this to work with a wedge DLL. All of the stuff seems
to be working as of right now with this extra wedge.

I had a code problem where I was throwing an uncaught exception on the
managed code side of things. Something stupid. The static varibles stuff
must have been happening when I ran "caspol -i off" with just a managed dll.

What really makes you crazy with this now is that it is so easy with VS2005
to switch an ATL application to a managed C++ application. A filter works
great but and extension is totally whacked and the error you get isn't very
intuitive.

Regards

Frank

"Frank Postle" wrote:

> My reading appears to indicate that there is a bug in the way that IIS
> accesses extensions. A unc path (\\?\) instead of a local path, this results
> in some sort of security policy exception.
>
> Is this something that is going to be fixed? If it isn't then does anyone
> know of a good work around? I have tried to build an unmanaged wedge in
> between IIS and the managed DLL. My first look this didn't work either, but
> I am going to look at this again.
>
> I have done this before but I have only used assemblies from the GAC and not
> managed classes declared locally. I am not sure what is going on here.
>
> I have tested this a bit with "caspol -s off" and there seemed to be an
> issue where the static variables within a managed class weren't scoped the
> same between the filter and the extension. I have a combined
> filter/extension set of dll's (1 unmanaged dll with ext and filter and 1
> managed dll with ext and filter). In the filter a static value of a class
> isn't the same value. It is as if that there is some sort of scoping that
> generates two separate sandboxes in the same apppool (process).
>
> Any help or guidence would be greatly appreciated.
>
> Regards
>
> Frank

David Wang [Msft]

2005-12-24, 5:56 pm

Nope, the bug is not in the way that IIS accesses extensions.

\\?\ is special syntax understood by NTFS and used by IIS for security
reasons. Perfectly reasonable.

The problem is in that Managed Code does not recognize \\?\ (remember it has
some silly compatibility requirement with Win9x which does not have NTFS and
thus does not understand \\?\ ).

You get into this mess when you write Managed C++ or write code that assumes
\\ means UNC share. But those are not issues in IIS.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

"Frank Postle" <FrankPostle@discussions.microsoft.com> wrote in message
news:16CC3CBD-C1E1-4D5B-88E8-7FACF9240EC9@microsoft.com...
> My reading appears to indicate that there is a bug in the way that IIS
> accesses extensions. A unc path (\\?\) instead of a local path, this
> results
> in some sort of security policy exception.
>
> Is this something that is going to be fixed? If it isn't then does anyone
> know of a good work around? I have tried to build an unmanaged wedge in
> between IIS and the managed DLL. My first look this didn't work either,
> but
> I am going to look at this again.
>
> I have done this before but I have only used assemblies from the GAC and
> not
> managed classes declared locally. I am not sure what is going on here.
>
> I have tested this a bit with "caspol -s off" and there seemed to be an
> issue where the static variables within a managed class weren't scoped the
> same between the filter and the extension. I have a combined
> filter/extension set of dll's (1 unmanaged dll with ext and filter and 1
> managed dll with ext and filter). In the filter a static value of a class
> isn't the same value. It is as if that there is some sort of scoping that
> generates two separate sandboxes in the same apppool (process).
>
> Any help or guidence would be greatly appreciated.
>
> Regards
>
> Frank

Frank Postle

2005-12-24, 5:56 pm

Okay that makes sense. I thought that \\?\ was something related to UNC paths.

I think more folks are going to have problems like this given that you can
run some of the atl and managed DotNET stuff in the same set of files (at
least the compiler doesn't complain).

The error you get when trying this isn't very helpful and it took a while of
looking to find the posts you have made about this previously.

Regards

Frank

"David Wang [Msft]" wrote:

> Nope, the bug is not in the way that IIS accesses extensions.
>
> \\?\ is special syntax understood by NTFS and used by IIS for security
> reasons. Perfectly reasonable.
>
> The problem is in that Managed Code does not recognize \\?\ (remember it has
> some silly compatibility requirement with Win9x which does not have NTFS and
> thus does not understand \\?\ ).
>
> You get into this mess when you write Managed C++ or write code that assumes
> \\ means UNC share. But those are not issues in IIS.
>
> --
> //David
> IIS
> http://blogs.msdn.com/David.Wang
> This posting is provided "AS IS" with no warranties, and confers no rights.
> //
>
> "Frank Postle" <FrankPostle@discussions.microsoft.com> wrote in message
> news:16CC3CBD-C1E1-4D5B-88E8-7FACF9240EC9@microsoft.com...
>
>
>