Either that, or you are shipping ASP pages to customers and you don't just
want to hand them all your ASP source code (so you want to encode it and
give the them a license key to decode). That was where the "Encoded ASP"
suggestion came from.
Also, note that I didn't say this was impossible... just not in the manner
you were describing with CreateFile. Your new approach is doable with
SF_NOTIFY_URL_MAP, but is not without it's own set of hurdles.
Finally, note that performance is going to be absolutely horrible in this
security-induced case since you *cannot* cache the unencrypted file content
anywhere (doing that defeats the purpose of you encrypting the files on disk
in the first case).
--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Wade A. Hilmo [MS]" <wadeh.RemoveThis@microsoft.com> wrote in message
news:%23Ya0t7dxDHA.2116@TK2MSFTNGP11.phx.gbl...
Hello,
What you want to do is technically possible.
First off, though, you do not want to use a raw data filter for this. The
best approach would be to use a filter on SF_NOTIFY_URL_MAP. In that
notification, you have access to the request URL and the physical path
associated with it. You have the opportunity at that point to change the
physical path to your desired file.
Our compression filter in IIS 5.0 works like this for static file
compression: Basically, the compression filter builds a compressed version
of the static file and caches it in a special directory. Then, when
requests for the original file come in, a URL_MAP filter points the physical
path to the compressed file.
There are a number of caveats with this approach, though.
First off, as Jerry says, you need to be careful to account for the fact
that you can have many requests all for the same URL. I guess that a very
simple approach would be to write your filter such that every request
generates a unique physical file. A more complex approach would be to
attempt to cache the temp files and attempt to reuse them. I don't know how
dynamic you expect to be, though, so I don't know if this is feasible for
your application.
Also, you should expect that the performance will be abysmal. This is
because you are forcing IIS to write to the file system for each and every
affected request (twice actually, if you really intend to clean up the temp
file at the end of the request.) Also, you are defeating most of the major
performance optimizations of ASP, since it's going to be wasting resources
by storing these pages in the template cache, etc. Neither of these
performance issues is a problem for the compression filter, since it only
writes to the file system once per URL, and the result is cached. I would
guess that this would be acceptable for a low load intranet server. I would
not recommend doing this on the internet, though, as it would be trivial for
a hostile client to DoS your server by hitting you with hundreds or
thousands of requests per second, each forcing your filter to create a file.
I am assuming that you are doing this because you want to make sure that
your ASP pages conform to some standard, and you are trying to implement a
technical solution instead of having the page authors do it. I would
strongly recommend against this. Rather than pursuing a filter, you should
investigate using includes or some other ASP feature.
Thank you,
-Wade A. Hilmo,
-Microsoft
PS: If you have any further questions on this or any other ISAPI topic,
please feel free to post them to
microsoft.public.platformsdk.internet.server.isapi-dev, which exists for
this purpose.
"Jerry III" <jerryiii.RemoveThis@hotmail.com> wrote in message
news:eS9vymdxDHA.2436@TK2MSFTNGP09.phx.gbl...
> Of course you can. But think about what would happen if you get two
requests
> for the same page at the same time.
>
> Jerry
>
> "Servé Lau" <i.RemoveThis@bleat.nospam.com> wrote in message
> news:brt66n$13v$1@news3.tilbu1.nb.home.nl...
> > "David Wang [Msft]" <someone.RemoveThis@online.microsoft.com> wrote in message
> > news:%23LYLjCZxDHA.2084@TK2MSFTNGP09.phx.gbl...
> > > What you are asking is not possible in that manner. IIS does not
> provide
> > > any provisions to open filestreams on behalf of a script parser, hence
> it
> > > cannot decrypt their contents (i.e. ASP makes the CreateFile call and
> > reads
> > > it itself). This removes any IIS modifications via ISAPI as possible
> > > solutions.
> > >
> > > I've heard of "Encoded ASP scripts", but I know nothing about it.
> >
> > Ok, I'll check that.
> > But can I process an incoming request to see what asp page is requested,
> > then open that file, decrypt it, write it to disk with another name,
pass
> > that new name on to asp and in the end throw the file away?
> > I'm having a hard time finding examples of how to use
HTTP_FILTER_RAW_DATA
> > by the way, is there a good resource for it?
> >
> >
>
><!-- ~MESSAGE_AFTER~ -->
>> Stay informed about: isapi decryption filter