On Feb 15, 4:54=A0am, banesong <banes...@gmail.com> wrote:
> Let me preface my problem with the statement that we are in the
> process of migrating from W2k/IIS5 to W2k3/IIS6 and I [an old Perl
> hack] am having to try and make an ISAPI filter work on the new
> platform. =A0The ISAPI approach might not even be the most efficient/
> best approach to the situation, but it _used_ to work.
>
> The background:
> We have a web app that has been hosted on W2k/IIS5 for many years, and
> have finally been forced to migrate to a shiny new OS and web server.
> The web app has an integrated/proprietary authentication schema
> requiring that every user hit a login page which then opens subsequent
> pages through itself through a series of frames. =A0The problem that we
> had in the past was that users figured out that they could browse
> directly to internal scripts and would have access without user
> identification and security controls being supplied. =A0The short
> solution was to implement a site ISAPI filter that would deny access
> to the page and redirect them to the logon page. =A0This ISAPI filter
> was implemented in C++, and compiled into a DLL. =A0The filter keys off
> of some hardcoded script names and http referrers using
> GetServerVariable "SCRIPT_NAME" and GetServerVariable "HTTP_REFERER"
> respectively to ensure that they only come in via a small subset of
> appropriate scripts.
>
> The problem:
> When I initially installed the ISAPI filter in IIS6, it failed and
> failed hard. =A0Turns out that there was a missing MFC dll required,
> which I then dropped on the server and the filter came up. =A0But then
> comes the real mystery. =A0When I access the site with Firefox,
> everything acts as normal and the site comes up right fast. =A0But when
> I access the site with IE, after the logon page (which comes up
> quickly), the following script will take up to 15 minutes to load a
> simple HTML file! =A0If I remove the ISAPI filter, the follow-on script
> comes up very quickly.
>
> The question:
> This should be broken into two parts, one dependent on the other.
>
> 1. =A0Is the approach that we took (ISAPI filter to prevent direct
> access) the best one and most efficient that we could? =A0We have to
> rely on our integrated security schema for various and sundry obscure
> reasons, but we _must_ make sure that users do not have the ability to
> directly access specific scripts without running through the logon
> page and it's frames.
>
> 2. =A0Any ideas/suggestions as to why the ISAPI filter has such abysmal
> performance when accessed in IE when it performs perfectly in Firefox?
>
> Thank you very much for any help you provide to a very confused
> person.
>
> Thomas