httpd-cli-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: [cli-users@httpd] Using Cookieless Session States
Date Mon, 13 Dec 2004 21:38:53 GMT
At 03:37 AM 12/13/2004, Manuel Reyes wrote:
>Hello all,
>This is a repost, but I am not 100% the list was working correctly the first time I sent
>I have encountered an interesting feature that I can't find a solution to, so I am interested
to learn whether it is a known issue or something I am missing.
>I have a series of pages that for various reasons use Cookieless Session States using
the following settings in the Web.Config :
>    <sessionState 
>            mode="InProc"
>            stateConnectionString="tcpip="
>            sqlConnectionString="data source=;Trusted_Connection=yes"
>            cookieless="true" 
>            timeout="20" 
>    />
>This means that the session key is not retrieved from a cookie on the client, but it is
passed to the web server using the URL.  For example, a request to :
>When I attempt to use this with the asp net module apache fires back a page not found
error, after looking at the logs it seems that Apache is attempting to located the file using
the session key as part of the path.  For example, this came from my Apache error.log
>[Fri Dec 03 14:58:38 2004] [error] [client] File does not exist: C:/Program
Files/Apache Group/Apache2/htdocs/aspnettest/(e1dufuizdrvrvl55z4w2yb45)
>If I set the Web.Config to use cookieless="false" in the section mentioned above the page
is served correctly.

Here is the essential problem; and what we are considering
for a future release...

The handler has a couple rules to enforce security that
may cause more hassles than they solve;

* The file is required to exist.  This filters some forms of
  nefarious attack against the ASP.NET host, but prevents you
  from accessing 'virtual' resources.

* We check Options ExecCGI to verify that dynamic content should
  be served for those <Files >, <Location > or <Directory > sections. 

A better solution (because the Options directive can't be extended) 
is to add and AspNetOptions directive.  We could both AllowVirtual,
as well as some On|Off option, which would cover both issues.

It's been on the back of my mind, over the holiday break I can
hopefully add this AspNetOptions directive.

One issue in that SessionID scheme is that we would not be able to
normalize the path names (e.g. turn applic~1/ into 'Application'
as named on disk.)  So all of these files would be virtual.  This
scheme entirely trusts that ASP.NET handles paths securely.  If
you had filtered on <Directory '*/Application'> or some such, then
the user would walk around those restrictions by passing applic~1
for the directory name.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message