Access session of another user

  • Thread starter Thread starter Nick Gilbert
  • Start date Start date
N

Nick Gilbert

Hi,

Is it possible to access the Session of an arbitary user from an aspx page?

On an e-commerce site, I am notified of payment success via a callback
from the payment server to an ASPX page on my system. I would like to be
able to access the session of the user that submitted the order, and
clear their basket. I don't really want to store their session in the
database just to facilitate this.

Nick...
 
Nick said:
Hi,

Is it possible to access the Session of an arbitary user from an aspx page?

On an e-commerce site, I am notified of payment success via a callback
from the payment server to an ASPX page on my system. I would like to be
able to access the session of the user that submitted the order, and
clear their basket. I don't really want to store their session in the
database just to facilitate this.
Click to expand...

Why not clear the basket within the user's session, via code on the page
itself?
 
Hi Nick,

From your post, I understand that you're building an e-commerce site which
uses session state to store a user's shopping cart; and you're calling
external payment service asynchronizely with a callback to your server
code. In this callback, you need to clear the payment's user's shopping
cart. Since your callback server code doesn't run in the session context of
the user who is issuing the payment, you want find a way to access the
user's session by a session id or user id, right? Please correct me if I've
misunderstood anything.

I'm afraid the built-in session state manager will not be able to let you
access an arbitrary user's session.

If you're using ASP.NET 2.0, I strongly recommend you to use the Profile
API to store your shopping cart, which can be accessed using a user name.

The major difference between Profile and Session objects are:

1) Profile object is persistent whereas Session object is non-persistent.
2) Profile object uses the provider model to store information whereas
Session object uses the In Proc, Out of Process or SQL Server Mode to store
information. (Refer to
http://download.microsoft.com/download/2/a/e/2aeabd28-3171-4b95-9363-2215062
5a6a5/ASP.NET%20Provider%20Model.pdf for more information about ASP.NET
Provider Model)
3) Profile object is strongly typed whereas Session object is not strongly
typed.

Profile also supports anonymous user, which is a nice feature for letting
your user first surfing your site and adding items to his/her shopping
carts without registering/login; only when he/she wants to check out, then
you can redirect him/her to the registration page and migrate his/her
profile.

I will post some related URLs introducing the Profile feature of ASP.NET
2.0:

#A New Solution to an Old State Storage Problem
http://msdn.microsoft.com/msdnmag/issues/06/04/ExtremeASPNET/

#ASP.NET Articles by Harish Ranganathan: Whidbey: Tired with Sessions? -
Use the new Profile property to store user information.
http://harishmvp.blogspot.com/2005/07/whidbey-tired-with-sessions-use-new.ht
ml

#Walkthrough: Maintaining Web Site User Information with Profile Properties
http://msdn2.microsoft.com/en-us/library/taab950e.aspx

Please reply to let me know whether or not you need further information.
Thanks.

Sincerely,
Walter Wang ([email protected], remove 'online.')
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications. If you are using Outlook Express, please make sure you clear the
check box "Tools/Options/Read: Get 300 headers at a time" to see your reply
promptly.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Walter,

Thanks for your suggestion. However as I was short of time and don't
know anything about Profiles, I found a quick alternative solution:

It seems you can access an arbitrary session if you put their session ID
in the URL - even if cookieless sessions are disabled in web.config (to
me this seems like a massive security hole and cookieless session URLs
should NOT work if it's been disabled in web.config, but at the moment,
I'm not complaining as it really helps me out).

Below are details of exactly how I fixed the problem in case there are
others with the same issue finding this thread. (This solution is for
WorldPay but might work with other payment providers who support dynamic
callback URLs)

You make the callback page URL dynamic. You pass the asp.net session ID
to the payment provider in a custom variable:

<input type="hidden" name="MC_callback" id="MC_callback" runat="server">
Then set it to Session.SessionID.ToString() in codebehind.

Then in Worldpay, you configure your callback to embed the session ID in
the URL:

http://w.com/(S(<WPDISPLAY ITEM=MC_callback>))/callback.aspx

The /(S(<blah>))/ syntax tells .NET that that's your ASP.NET session ID
(cookieless). This seems to work even if cookieless session IDs are
disabled in web.config - which is handy.

That means your callback page executes within the user's current context
and therefore has access to their session and shopping basket.

You can then clear their basket from the codebehind of this page if
their purchase was successful.

However I'm going to implement your solution in my next e-commerce site
as it seems a nicer way to solve the problem.

Thanks!

Nick...
 
Walter,

Thanks for this suggestion..

I previously posted saying you could insert the session ID in the URL,
but have since found out that this doesn't work if the page is requested
from a different IP address. If my previous (deleted) post appears on
any servers - ignore it it's incorrect. I will go with Walter's solution
or perhaps a database driven shopping cart.

Thanks,

Nick...
 
Back
Top