Session ID in Query Parameter?

  • Thread starter Thread starter Uwe
  • Start date Start date
U

Uwe

Howdy!

I've googled and googled for this without success, and either it's so easy
that nobody has ever asked, or there is some serious reason nobody would do
this. But I'm going to ask anyway.

I'd like to move my ASP.NET session ID from the default cookie into the URL.
I tried the "cookieless" approach and it doesn't work for me for two
reasons:

1. I have FrontPage-based forms that posts to my ASP.NET application, and a
cookieless ASP.NET session apparently cannot be started with a POST. I
believe there's a redirect in there somewhere.

I don't want to convert these forms to webforms because there are others
that can create and maintain FP forms, but I'm the only one who can write
ASP.NET code.

2. All my Javascript code (i.e. rollovers) is screwed up because the Jscript
uses relative paths to get at the various button images but the cookieless
directory is one extra level down in the tree.

What I would like to do is to modify my ASP.NET application to retrieve the
session ID from either a query parameter or a hidden form field if this is a
postback. When the app starts up, I can obtain the session ID and put it
into a form variable or somehow append it to the URL used for the postback.
When the postback occurs, I'd like to get control before the session is
established, query the form or the query parameter collection (assuming it
exists before the session is established), establish the session and
everybody's happy. If the session ID is not valid, I can just let ASP.NET
create a new one.

Ideally, I could even check the form field, query parameter, and cookie for
a session ID (using some uniquely named key value).

So can someone point me in the right direction? Ideally, there will be a
virtual function I can override somewhere (maybe global.asax), something
like GetSessionID().

Thanks in advance...

--- Uwe
 
Hi Uwe,

Thanks for posting in the community!
From your description, you'd like to use the cookieless session in
ASP.NETweb app. And the problem is that you've some non-ASP.NET/normal html
pages. So when posting from such normal html page the session state will
lose(a new one start). Also, you'd like to looking for some certain
appraches to resolve such problems, yes?

As for this question, the ASP.NET buildin cookieless session support does
lose some features that cookie-managed application provides. Those
functions such as Form-based authentication, neat/custom urls, problems
with mobile applications, or the ability to POST data from an html page
become a thing of the past. Though the ASP.NET buildin hasn't provide some
certain approachs on this, some other thiry-party members have tried some
custom means to workaround this, here are some certain weblinks discusing
on such topics:

#Enabling POST in Cookieless ASP.NET Applications
http://www.developer.com/net/asp/article.php/2216431

#Cookieless data persistence is possible
http://web.zdnet.com.au/builder/webdesign/scripting/story/0,2000040414,20273
890,00.htm

Also, since it's not the build in mechanism, it can't be guarantee that it
won't work into any problem some time. In addition, I still think it better
to convert most pages into ASP.NET page (at least add mapping ) so as it
also possbile to be handlered by ASP.NET runtime so that we can do some
operations on those reponse stream.



Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Get Preview at ASP.NET whidbey
http://msdn.microsoft.com/asp.net/whidbey/default.aspx
 
Hi Steven:

Thank you for your reply. My comments are interspersed below.

Steven Cheng said:
Hi Uwe,

Thanks for posting in the community!
From your description, you'd like to use the cookieless session in
ASP.NETweb app. And the problem is that you've some non-ASP.NET/normal html
pages. So when posting from such normal html page the session state will
lose(a new one start). Also, you'd like to looking for some certain
appraches to resolve such problems, yes?

As for this question, the ASP.NET buildin cookieless session support does
lose some features that cookie-managed application provides. Those
functions such as Form-based authentication, neat/custom urls, problems
with mobile applications, or the ability to POST data from an html page
become a thing of the past. Though the ASP.NET buildin hasn't provide some
certain approachs on this, some other thiry-party members have tried some
custom means to workaround this, here are some certain weblinks discusing
on such topics:

#Enabling POST in Cookieless ASP.NET Applications
http://www.developer.com/net/asp/article.php/2216431
Click to expand...

I had previously looked at this article, but it's a complex solution--not
from the implementation point of view, but I am concerned that there is
still a redirection involved. The browsers that I am supporting have
cookies disabled for security concerns, and I am concerned that they may
also have Javascript disabled. This solution uses Javascript to repost the
form data before the redirection.
#Cookieless data persistence is possible
Click to expand...
http://web.zdnet.com.au/builder/webdesign/scripting/story/0,2000040414,20273890,00.htm

Unfortunately, this article doesn't tell me how to use the ASP.NET Session
object in a cookieless way. I am trying to convert an existing "shopping
cart" ASP.NET program that is populated through the POST from various other
forms on the website. It uses the Session object and I really don't want to
change that.
Also, since it's not the build in mechanism, it can't be guarantee that it
won't work into any problem some time. In addition, I still think it better
to convert most pages into ASP.NET page (at least add mapping ) so as it
also possbile to be handlered by ASP.NET runtime so that we can do some
operations on those reponse stream.
Click to expand...

Long-term, ASP.NET is the way to go. But like I said, others maintain the
HTML order forms in FrontPage that POST to the ASP.NET application. Less
work for me!

So, to restate the problem: there must be code in ASP.NET that takes the
session ID, looks for an existing session object and if found, connects to
it. If not found, it creates the object and session ID. I want to provide
the session ID string, rather than have the existing code read the session
ID string from the cookie.

Is there a place I can hook or subclass the code that creates/connects to
the session object?

--- Uwe
 
Hi Uwe,

Thank you for the response. From your further comment, I've got that the
existing solutions seems not work for your situation. Currently, I am doing
further research on this to see whether there're any other approachs
and I will update as soon as posible.


Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security(This posting is provided "AS IS",
with no warranties, and confers no rights.)
 
Hi Uwe,

After some further researching and consulting some other experts on this.
It seems that there isn't any means
we can hook or subclass the code that creates/connects to the session
object. All these operations are internal protected by the ASP.NET. So I'm
afraid currently we haven't any better solutoin other than those mentioned
in the former messages. Maybe you need to detect those browsers which not
support cookie or javascript, i think most browsers won't disable
javascript since most web apps need to reply on it. Any way, if you have
any other ideas, please also feel free to post here. Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Get Preview at ASP.NET whidbey
http://msdn.microsoft.com/asp.net/whidbey/default.aspx
 
Hi Steven:

Thank you for checking. I guess this explains why I couldn't find any
information about this at all. I hope subclassing/hooking session creation
is something that can be considered for a future version of ASP.NET. I can
certainly imagine scenarios where a developer has their own scheme for
persisting sessions IDs but wants to use the nifty ASP.NET session object.

I did find a work-around for the specific problem I was having last night --
it turns out that the AOL v9 installation defaults to a very restrictive
cookie policy. I was able to simulate that in IE by setting the security
slider to "medium high". Sure enough, my ASP.NET pages stopped working and
put up the "lost session information, please enable cookies exception". I
then used an IBM tool to create a "compact privacy policy" that matches my
site's privacy policy (very restrictive), uploaded it to my server and lo
and behold, IE started accepting cookies again--even on the "high" setting.
I don't have AOL 9 installed, but apparently it uses IE internally and I'm
hoping that it works the same way and respects the policy. So far so good
anyway.

So thank you for taking time to research this issue.

--- Uwe
 
Back
Top