Why Outlook creating Different SessionId for a single session

[rayala]

Hi all,

I am having very weird problem in my Outlook

I am running my web application from with in Outlook.I found a strange
problem that it is creating different sessionId if i open a new window
using window.open from with in my application.I am pulling my hair all
along but no solution so far.Hope you guys can help me out.

my application works fine when i run this in IE.It is Outlook2003
causing the problem



Thanks

 

[Anthony Jones]

Hi all,

I am having very weird problem in my Outlook

I am running my web application from with in Outlook.I found a strange
problem that it is creating different sessionId if i open a new window
using window.open from with in my application.I am pulling my hair all
along but no solution so far.Hope you guys can help me out.

my application works fine when i run this in IE.It is Outlook2003
causing the problem



Thanks

See thread entitled: 'Asp and Session Variables' posted here on 1 Apr 2006

basically window.open doesn't guarantee to open the new window in the same
process as the current one. In my experience I've only ever seen this
behaviour in outlook,a page launched from outlook which then launches
another window will sometomes start a fresh IE process or create a window in
an existing IE process rather than the one which in some way is parented by
the outlook application.

Sessions are managed by an in memory cookie which cannot be shared across
processes.

Anthony.

 

[rayala]

Thanks Anthony for the reply

I don't understand why my application works differently when running
from Outlook.I think Outlook is also using the same Internet explorer.

But why when i run my application in a IE browser by typing the URL in
the address bar it just works fine.

i have gone through msdn articles which saying it is a problem in IE4.0
And 5.0 and they fixed this in later browsers(which dynamically sets
this flag based on RAM).I have tried with these settings and i have
gone through the aspfaqs.com link.But none of them seems of any help to
my cause.

Are you sure it is this way Ourlook handles sessionId when you open a
new window using window.open


Rayala

 

[Anthony Jones]

Thanks Anthony for the reply

I don't understand why my application works differently when running
from Outlook.I think Outlook is also using the same Internet explorer.

Basically IE is a set of controls and objects. If you find the IExplore.exe
you will find that it is quite small. IExplore is simply an exe dedicated
to hosting the IE 'control' which does all the actual work. Many
applications and applets supplied by MS use this 'control' to present some
of their UIs. Outlook Today is an example.

An up shot of Outlook hosting the IE 'control' and being kind enough to
supply an address bar you can navigate the web from with in Outlook.

If you ensure all other IE windows are closed and check task manager you
will see there is no IExplore process. Now use Outlook to navigate to your
web site. You will still see no IExplore process outlook is just hosting
the 'control'.

Now do something that uses window.open. A new window is opened but your
session info is lost. Check the task manager and you will see a new
IExplore process has been started.

Now do something else in your outlook hosted page that also uses
window.open. A new window is opened in the now existing IExplore process si
it shares the session info with that other window.

But why when i run my application in a IE browser by typing the URL in
the address bar it just works fine.

i have gone through msdn articles which saying it is a problem in IE4.0
And 5.0 and they fixed this in later browsers(which dynamically sets
this flag based on RAM).I have tried with these settings and i have
gone through the aspfaqs.com link.But none of them seems of any help to
my cause.

Are you sure it is this way Ourlook handles sessionId when you open a
new window using window.open

Yep just been testing it myself. My guess would be that the hosting
application is being involved in the request for a new window and outlook is
saying some thing like 'not on my turf go create you're own process'.

 

[rayala]

Excellent Anthony.Thanks for the explanation.
I am cooling now.But That's a bit pain for me to change my application
to not to use session as i need to find another way to prevent the user
from logging in from different places using the same loginid
simultaneously.

Raghu

 

[Anthony Jones]

Excellent Anthony.Thanks for the explanation.
I am cooling now.But That's a bit pain for me to change my application
to not to use session as i need to find another way to prevent the user
from logging in from different places using the same loginid
simultaneously.

Raghu

there would be nothing stopping them starting a fresh IExpore process anyway
so session wouldn't help. I would also guess you would want to prevent them
from using another machine to circumvent your single login requirement.

As I see it you really only have two choices. Review the requirement to see
if it is necessary OR invalidate any other session that has the same user
logged in.

You could implement the session invalidation by adding a GUID to a table of
users. When a user logins allocate a GUID and store it in the table and the
session object. Subsequent requests on the session compare the session GUID
with the table GUID. If they don't match they have logged in elsewhere so
clear the session and respond with the logon screen plus appropriate
message.

Anthony.

 

[rayala]

Anthony,

I am right back on track.

one approach i though is creating SessionId at login and pass to all
the pages using Query String with some sort of encryption.


i am sorry i did not follow the solution you have suggested, here is
what i understood base on your suggestion.Correct me if i am wrong.

we should store the GUID in the users table for each user as soon they
login

for each new login we should check whether any GUID exists for this
user or not.If one exists then he has logged in some where else, so
tell the new user to either go and clear that user session and login
back.

what is your sessionGUID mean then.


Thanks for your replies, i hope i am not bothering you with my queries.



Thanks
Raghu

 

[George Hester]

That is not the way it works. ASP is stateless. You need to use cookies.

 

[Anthony Jones]

That is not the way it works. ASP is stateless. You need to use cookies.

Uh huh? and tell us again what is the ASP Session object for?

 

[George Hester]

For the Session that is started. But you cannot be sure that Session will
hold throughout the application. Use cookies written to disk. The issue is
gone.

 

[Anthony Jones]

For the Session that is started. But you cannot be sure that Session will
hold throughout the application. Use cookies written to disk. The issue is
gone.

Well that depends on your application. The point is ASP is not stateless as
you stated. ASP has a session object designed to maintian state between
requests within a session.

For some applications the lifetime of the session is sufficient for others
it is not.

 

[Anthony Jones]

Anthony,

I am right back on track.

one approach i though is creating SessionId at login and pass to all
the pages using Query String with some sort of encryption.


i am sorry i did not follow the solution you have suggested, here is
what i understood base on your suggestion.Correct me if i am wrong.

we should store the GUID in the users table for each user as soon they
login

for each new login we should check whether any GUID exists for this
user or not.If one exists then he has logged in some where else, so
tell the new user to either go and clear that user session and login
back.

The problem with this approach is that user may not know where else they are
logged in or worse their browser crashed before they were able clear their
log in. What do they do now?

A better approach is to allow them to login and make sure any other
outstanding logged in session is unusable.

what is your sessionGUID mean then.

I mean store the GUID in the Session object.

When user logons on create a unique ID and store it against the user in a
database.

Store this same unique ID in the Session object as well.

When any page is requested (use an include page) have it compare the unique
ID stored in the session object against the unique ID in the database for
the user. They should match. If they don't it means they have logged in
somewhere else. In that case clear the session and redirect them to the
logon page.