robert ginsburg

I have an interesting problem and am looking for some insight. I have been
working on a c# HTTPModule that "assists" forms authentication, with the
specific goal of handling authentication for Windows SharePoint services.
Most of the problems are fairly routine and easy to solve, however there is
one that has completely got me stumped. Several of the SharePoint functions
post data directly back to ISAPI extensions. In order to get IIS to run the
HTTPModule for the request being sent to the ISAPI extension, I have to map
the .DLL extension to the asp.net ISAPI extension. When this mapping is in
place, the HTTPModule runs fine, but IIS does not appear to pass the right
reference to the original ISAPI extension. I have a workaround, where all
calls to the DLL are actually passed through a server request proxy that
calls the original extension in another virtual directory; however the
overhead is obviously huge. I am thinking that I should be able to call the
original ISAPI DLL directly, but I cannot figure out how (using c# inside a
running request) to capture or create the correct control block (ECB), nor
how to pass in the correct references for the call back routines to access
the request and response. I understand that this work is more suited to an
ISAPI filter, and have already got that working, but the solution seems more
elegant if it is ".NET".

Thanks

Robert Ginsburg (robert.ginsburg@ver3.com)

olaf lueder [mvp]

Hallo Robert,


Not sure if it would work as expected and probably you'll get some better hints here...

.... but IIRC the only problem is that the SharePoint filter rejects
'invalid' requests.

As a workaround you could use two simple filters, the first one
(executed before stsflt) would rewrite the original url (of your
specific request) to a (allowed) dummy url (and store the original in an
additional header), the second one (executed after stsflt) could restore
this url from the header.

--
Regards, Olaf
MS MVP ASP

david wang [msft]

What you are asking for is currently not doable with ASP.Net. .Net is not
controlling the HTTP Pipeline of IIS.

The feature you're talking about is to use ASP.Net to filter incoming
requests using a .Net HTTP Module by scriptmapping ASP.Net to handle
particular extensions.

Prior to IIS6, the underlying mechanism for a handler to tell IIS to
"re-execute" the URL is not available, so this is not possible on those IIS
versions.

IIS6 exposes a native mechanism to allow a handler to tell IIS to
"re-execute" any URL (with some caveats). A feature called "wildcard
application mapping" can take advantage of this mechanism to filter incoming
requests using a ISAPI Extension DLL (cannot be a .Net DLL, including
managed C++ [due to a CLR bug]). However, ASP.Net does not take advantage of
this, so .Net HTTP Modules can't do this.

If we're talking about prior to IIS6, your solution needs an ISAPI Filter.
If we're talking about IIS6, then your solution can be mostly implemented in
an ISAPI Extension configured as a wildcard application mapping.

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//


I have an interesting problem and am looking for some insight. I have been
working on a c# HTTPModule that "assists" forms authentication, with the
specific goal of handling authentication for Windows SharePoint services.
Most of the problems are fairly routine and easy to solve, however there is
one that has completely got me stumped. Several of the SharePoint functions
post data directly back to ISAPI extensions. In order to get IIS to run the
HTTPModule for the request being sent to the ISAPI extension, I have to map
the .DLL extension to the asp.net ISAPI extension. When this mapping is in
place, the HTTPModule runs fine, but IIS does not appear to pass the right
reference to the original ISAPI extension. I have a workaround, where all
calls to the DLL are actually passed through a server request proxy that
calls the original extension in another virtual directory; however the
overhead is obviously huge. I am thinking that I should be able to call the
original ISAPI DLL directly, but I cannot figure out how (using c# inside a
running request) to capture or create the correct control block (ECB), nor
how to pass in the correct references for the call back routines to access
the request and response. I understand that this work is more suited to an
ISAPI filter, and have already got that working, but the solution seems more
elegant if it is ".NET".

Thanks

Robert Ginsburg (robert.ginsburg@ver3.com)

robert ginsburg

Thanks, that was what I was afraid of. I have the ISAPI filter working so
the solution works fine, however you mentioned that there is a "re-execute"
instruction I can give IIS6. Where can I find additional info on that, MSDN
does not seem to list it.

-Robert

more

david wang [msft]

MSDN does have do***entation on it. It is called HSE_REQ_EXEC_URL , and it
is available for ISAPI Extensions only. Its overhead is probably quite tiny
in comparison to your current solution. How you configure this ISAPI
Extension to pick up all incoming requests is via another IIS6 feature,
multiple Wildcard application mappings, where the ISAPI Extension registers
to handle .* extension (i.e. everything)... and chooses to handle what it
wants, and HSE_REQ_EXEC_URL the rest back to IIS to continue processing.

ISAPI Filters cannot do this "re-execute" because the only thing ISAPI
Filter can do is change the URL -- it cannot change the HANDLER for the URL
after SF_NOTIFY_PREPROC_HEADERS (well, without doing a little
proxy/new-request sort of thing like yours). HSE_REQ_EXEC_URL is a logical
re-execute of the URL on the server, including rewriting any portion of the
URL/headers/entity body plus impersonation token and *_USER server variables
for the child request (i.e. it's what most people want to do when they start
writing that ISAPI Filter...).

However, the current do***entation on MSDN is quite old and
incomplete/inaccurate (FEB 2003, prior to IIS6 shipping); I'm looking at the
revised versions of the do***entation that should be going out in either
OCT2003 or JAN2004

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//


Thanks, that was what I was afraid of. I have the ISAPI filter working so
the solution works fine, however you mentioned that there is a "re-execute"
instruction I can give IIS6. Where can I find additional info on that, MSDN
does not seem to list it. -Robert
"David Wang [Msft]" <someone@online.microsoft.com> wrote in message news:OYwos8cvDHA.2440@TK2MSFTNGP12.phx.gbl...

more