session issues with Ctrl-N

[sreenath reddy]

Hi all

As everyone knows that IE issues same session Id to the browsers opened through Ctrl-N /going to File --New -->window .

I have a webapplication which has concept of web licensing ...mean to say only 10 clients can operate .......this is done using sesision mech in tomcat ....now the user will be misusing that by using these ways

so how can i avoid this ?? i know that Ctrl-N can be trapped through javascript but not the other option ..........i dont mind even if the effort will be more ........can i think of overwriting tomcats session architecture so that it issues a new session for the Ctrl-N window

I need a complete solution for this ? can any one help me out in this regard

Regards
Sreenath

[William Brogden]

Exactly what is the problem here? If the user has two windows open on the same application, sharing the same session, he will not be able to do two separate operations because there is only one session.
Bill

[sreenath reddy]

Hi william

The problem is that as we have concept of license for this web application , given the user 10 licenses .at a time only 10 windows shoudl be open(i mean 10 user can log in...at the time when the user logs in through number of active sessions we are controlling the license )

but now the user can say Ctrl-N which will bypass the login and he can operate in many windows

hope u got my problem pls let me know if u have any idea reg how to over com e this

[Bear Bibeault]

I still don't get the problem. Are you afraid that someone will Ctrl-N 100 timesa and have 100 of his friends hunched around his keyboard?

[Ben Souther]

I understand the problem.
When you open MSIE in the ways just mentioned, both instances of the browser share the same cookie space and thus won't have their own sessions. You will have the same issue with multiple tabs in Mozilla or FF.

On thought would be to generate a unique token (a timestamp would probably do). Put the token in a session variable (lastPage or something like that). At the same time send the token down with each page as either a hidden form field or as a querystring parameter embedded in each link.

Then with each request, compare the value from the request with the one stored in session if they are different, there is a good chance that they have more than one browser instance open.

The only glitch I can see with this technique would be the back button and the refresh button. You could probably get around this by keeping a queue map of lastPage tokens that you could compare the current one to.

[Bear Bibeault]

Oh, I understand the mechanism of what's happening, I just don't see why it's a concern. I'm sure that the intent of the license limitation is to keep the number of people using the app to the specified limit. Another instance of the browser on a single system isn't likely to have another person using it. (Brings up images of "Hey! Keep your fingers on YOUR side of the keyboard!" or "Come on! It's my turn to use the mouse!")
[ May 13, 2005: Message edited by: Bear Bibeault ]

[Ben Souther]

Firstly, I don't believe that per seat licensing is a good model for webapps.
The internet does not provide a reliable enough connection to implement it properly.
I realize, however that this decision is not always made by people who understand the technology they're working with and the developer may have no say in the process.

The problem that they're more likely to run into than two people sharing a PC to skirt the licensing is one person using this technique to keep from using up two seats and having concurrency problems.

You start working with client A.
Client B calls with a quick question.
You're out of seats so you can either shut down what you were doing with A to get some quick numbers or you can use CTL+N.
You choose the latter, give B the needed information and then continue working with client A.
Now, even though you are looking at a screen with client A's name on it,
you've really replaced all the session data with that of client B's.
You fill out the form and submit it.
If you're lucky the whole thing will blow up in your face.
Otherwise, you've just written A's numbers into B's accounts.
[ May 13, 2005: Message edited by: Ben Souther ]

[sreenath reddy]

Then with each request, compare the value from the request with the one stored in session if they are different, there is a good chance that they have more than one browser instance open.

Hi ben

See even if i have that token in my every url , still the problem wont be solved as pressing the Ctrl-N will open in new window with the parameter still there in that new window also

Then how can i identify this new window as still that will have that parameter ?? hope u got what i am trying to say

Let me know if u have some other sol in mind ...i think there is no way to do this (if even back and refresh should work fine) except overriding tomcats session behaviour

Regards
Sreenath

[Jon Egan]

Sreenath,

The problem isn't with Tomcat's implementation of sessions, it's with the fact that the requests sent by the two browser windows will be indistinguishable by anything on the server, so Tomcat has no hope of handling them separately.

Ben's solution with the timestamps is one I've read about to beat similar problems before - such as "logged-out-then-hit-Back". In this case, you're right, it won't prevent the newly opened window from working... the first time. The "next" request after the new window opens, whether it comes from the first window or the new one, will work. But after that, the other window will stop working. Here's the scenario:

1. User opens page in browser window A, gets a hidden form field, or link URLs, containing timestamp of X.

2. User does File->New Window, or CTRL-N, and gets another window, B, with the same page, out of the cache (hrmmm.. I have a thought on this, see "CACHE", below), with the same timestamp of X.

3. User submits form (or clicks a link) in either window, and the request hits the server - the "lastRequestTime" submitted with the request matches the time stored off in the session on the server, so this access is allowed, and a new page is loaded in that window... with a hidden form field or URLs containing a new timestamp, of Y.

4. If at any time after that, the user tries to do anything with the other window, the timestamp X will be submitted to the server, and it won't match the "lastRequestTime" on the server - which by now is Y, or maybe Z or something else. So that page access is denied, and the user has only 1 working window.

If you do this, the only "problem" you are allowing is the user to have two windows displaying the exact same page. Once the user navigates in one of them, it would also allow them to see both pages (new and old) at the same time, but if this was a problem you would also have to find a way to keep them from printing, jotting down notes on paper, doing screen capture, ....

CACHE

Since the "CTRL-N" or "Start->New Window" page has to come out of the cache, would this problem be solved by sending meta tags (or setting http headers) to prevent the page from being cached? Then, when you tried to open the new window, wouldn't it have to hit the server, which would include either a re-post of the previous form, or a GET of the same URL? Combined with the timestamp thing, could this prevent the second window in the first place, since the re-post or re-get would violate the timestamp, and could be disallowed....?

-- Jon

[sreenath reddy]

Hi john

Thanks for ur reply with tons of patience

Let me ask u one thing regarding that Time Stamp implementation ?? Don't u think after doing this it will create problem for the popups ??

Assume a window has got the timestamp of X and he opens some popup which will update the timeStamp in session to Y and on closing the popup and coming to the parent window , u wont be allowed to work in that as per the above implementation

Am i right ?? Ok assume that if i can over come this can u elaborate how to start with the solution ?? Can i have one variable in session (like lastRequestTime) and then have the same appended to all the URLs r place it as hidden variable in all the JSPs right ??

and coming to the caching , the browser will resubmit the request (POST /GET ) and then the first req works in the window . Its the same as the earlier solution as u explained

Pls let me know ur ideas

Sreenath

[Bear Bibeault]

sreenath, JavaRanch is a community of people from all over the world, many of who are not native English speakers. While using abbreviations like "u" instead of spelling out "you" is convenient when text messaging your friends on a cell phone or in a chat room, it presents an extra challenge to those that are already struggling with English. Additionally, such shortcuts may confound automated translation tools that patrons of the Ranch may be making use of.

I would like to ask for your help in making the content of JavaRanch a little easier to read for everybody that visits here by not using such abbreviations.

Please read this for more information.

thanks,
bear
Forum Bartender

[Ben Souther]

[Jon Egan]If you do this, the only "problem" you are allowing is the user to have two windows displaying the exact same page. Once the user navigates in one of them, it would also allow them to see both pages (new and old) at the same time, but if this was a problem you would also have to find a way to keep them from printing, jotting down notes on paper, doing screen capture, ....

Yes there are some thorns to this approach (again, as I mentioned, the web ins't a good place to implement 'per-seat' licensing).
The exact same page usually isn't a problem and as you've said, as soon as the user actually tries to do something with the new window, they will throw the tokens out of sync.

sreenath reddy,
If your app uses popups, yes that would cause you headaches. You might need to come up with a certain token for those "popup-timestamp" and allow any pages with tokens that start with "popup-".

I'm sure you'll run into other issues as well.
[ May 14, 2005: Message edited by: Ben Souther ]

[James Carman]

You still haven't explained WHY this is a concern for you. What is the nature of your application that it should disallow (or treat as different instances) multiple windows for the same client machine?

[sreenath reddy]

Hi james

I cant tell u in detail why i need this , but the i either should restrict the user not to use Ctrl-N . Restrciting in the sense its okay even if we throw him some error page in the ctrl-n window

[Jon Egan]

Here's what I was thinking in my earlier post about the cacheing, and I can't say for sure this would work properly, but it seems like it should, from my understanding of cacheing.

If each JSP has the headers set to tell the browser not to keep the page, opening a new browser window (either by the menu or CTRL-N) should require that the page is requested again from the server. At least, that's what I would think, and if that's not the case, then forget the rest of this.

So here is how the order of things would go:

STEP 1: User requests a first page (pg1.jsp), and server saves off "lastRequestTime" as X, and sends a page that holds the value (in URLs or hidden form field) named "verifyLastRequestTime", with value X.

STEP 2: User makes another request to get a new page (pg2.jsp), server sees the "verifyLastRequestTime" value of X in the request, verifies it matches the "lastRequestTime" in the session, and allows the request to proceed. It is now time Y, so the server updates "lastRequestTime" to be Y, and sends out pg2.jsp with a hidden "verifyLastRequestTime" value of Y. This page has the cache-control directives in the HTTP headers or meta tags.

STEP 3: User then opens a new window, in which the browser wants to again display pg2.jsp - but it doesn't have the results of that request in a cache (I think this works, even though it definitely has it in memory since it is still displaying the page in the original window). So the browser prompts the user "repost form data?" (or if it was a link, it just sends the URL with a GET request) with all of the request parameter info exactly as it was in the original STEP 2 request (including value of X for "verifyLastRequestTime"). The server now compares the submitted value of X to the value in the session, which is Y, and disallows the request (sends to an error page or something).

So I think that would result in the user getting a failure in the new window, even when the window is first loaded. This would meet the originally stated requirement of preventing the new window from ever working.

But then, if this:

if even back and refresh should work fine

means that you have to allow users to use back and refresh, then this won't meet all the requirements. It gets bigger and more unpleasant as you try to accomodate all of that.


As for how to implement it, you have it exactly right. You can decide selectively which requests to handle each way:

* requests for regular application pages should require that the timestamp was present and match the value in the session, and should cause the server to update the timestamp in the session.

* requests for popup pages (dialogs, etc.) should be required to submit a valid timestamp, but should not reset the time in the session. They should set the timestamp in the page, to be resubmitted when the dialog is submitted or closed.

* requests resulting from a form submission in a dialog should also require a valid timestamp, and also not update the value in the session unless the dialog closing action is also going to reload the main page.

Hope this helps make it clear, and even more, I hope that this licensing model is eliminated so it doesn't matter.

-- Jon

[sreenath reddy]

User then opens a new window, in which the browser wants to again display pg2.jsp - but it doesn't have the results of that request in a cache (I think this works, even though it definitely has it in memory since it is still displaying the page in the original window). So the browser prompts the user "repost form data?" (or if it was a link, it just sends the URL with a GET request) with all of the request parameter info exactly as it was in the original STEP 2 request (including value of X for "verifyLastRequestTime"). The server now compares the submitted value of X to the value in the session, which is Y, and disallows the request (sends to an error page or something).

Hi

I am not able to understand one thing u explained . when the clicks Ctrl-N and opens a new window , the "verifyLastRequestTime" in that page while resubmitting the request will Y (its not X as u stated) and that will make the things work fine in the new window opened . But now if u go to the first window , that page wont work as the "verifyLastRequestTime" might have been changed from Y to Z in the newly opened window .

Hope i am correct and can u tell me one thing ..how to implement this hidden field concept and if i do that , then even my hyperlinks needs submission of the html form right ??

Regards
Sreenath

[icredes]

One way of dealing with this is to user frames

have an outer frame with nothing but javascript in it to do either?

return false on keypress for "ctrl N" - although you can still select file / new window

or

on reload redirect to log out page.

there are still some down falls to this...
1. user will not be able to refresh the page - will log out
2. xp sp2 - our friend! - kills a lot of javascript functions for this..


just something to throw out there
[ May 16, 2005: Message edited by: James Todd ]

[Jon Egan]

Sreenath,

Here are the steps I described before, I'll try to add a bit more detail to see if you can see what I'm saying - or maybe someone else can point out why I'm wrong...

STEP 1: User requests a first page (pg1.jsp), and server saves off "lastRequestTime" as X, and sends a page that holds the value (in URLs or hidden form field) named "verifyLastRequestTime", with value X.

The "verifyLastRequestTime" submitted by the first request would be something like 'W' - it's not X - the request contains 'W', but happens at time 'X'. So the server matches that other value to it's in-memory copy, and then sets the "lastRequestTime" in-memory copy to now be 'X', because that's the time now. The response (pg1.jsp) has this value ('X') in it. When the form in pg1.jsp is submitted, it will have verifyLastRequestTime=X as one of the paramters.

STEP 2: User makes another request (submits pg1.jsp) to get a new page (pg2.jsp), server sees the "verifyLastRequestTime" value of X in the request, verifies it matches the "lastRequestTime" in the session, and allows the request to proceed. It is now time Y, so the server updates "lastRequestTime" to be Y, and sends out pg2.jsp with a hidden "verifyLastRequestTime" value of Y. This page has the cache-control directives in the HTTP headers or meta tags.

So, this time that pg1.jsp was submitted to request pg2.jsp, verifyLastRequestTime=X is in the request, and it matches the in-memory timestamp, because the request previous to this one was at time X. But then, that in-memory value is now set to Y, which is the time of STEP 2.

STEP 3: User then opens a new window, in which the browser wants to again display pg2.jsp - but it doesn't have the results of that request in a cache (I think this works, even though it definitely has it in memory since it is still displaying the page in the original window). So the browser prompts the user "repost form data?" (or if it was a link, it just sends the URL with a GET request) with all of the request parameter info exactly as it was in the original STEP 2 request (including value of X for "verifyLastRequestTime"). The server now compares the submitted value of X to the value in the session, which is Y, and disallows the request (sends to an error page or something).

When the browser tries to open the new window and has to re-request pg2.jsp, it's resubmitting the exact same request as the last time it submitted pg1.jsp to retrieve pg2.jsp (in STEP 2), including the same "verifyLastRequestTime" value of X - but this can't work a second time, because the first time this request was made, the server value was updated to Y.


In case this will help, I'll make a timeline:

                                                          Server          Server
        At         User                    User           Previous        New        Server
STEP    Time       Submits                 Requests       Value           Value      Responds
====    ====       =============           ==========     =========       =======    ==========
          W                                login.jsp
 1        X        login.jsp               pg1.jsp                            X       pg1.jsp, with val = X
 2        Y        pg1.jsp with val=X      pg2.jsp            X               Y       pg2.jsp, with val = Y
 3        Z        pg1.jsp with val=X      pg2.jsp            Y                       ERROR
 

Hope this makes my point easier to understand. Again, all of this would depend on the browser behavior when http headers prevent caching, and user does CTRL-N.

-- Jon

-- Jon

[sreenath reddy]

Hi

Really ur patience is appreciated ..but one thing i observe ....

When first req happens from login.jsp--> pg1.jsp , the url gets updated to pg1.jsp?timeToken=X and pg1.jsp-->pg2.jsp the url should get updated to pg2.jsp?timeToken=Y

so at this time when the user presses Ctrl-N token will go as Y rather than X.

Hope it has something to do with whether u send the timeToken in URL or not ...... and currently i have frames in my application

so can u tell me how much feasibility that has

[Jon Egan]

I wonder if maybe the difference in how we see this scenario is in how the browser submits back a good value for "timeToken". It seems like, from your posts, that you are thinking of the browser dynamically generating a timestamp, containing the time when the form is submitted or the link is clicked.

That is not the case. All of the timestamps are generated on the server when a response is being created (in a Servlet or JSP). To the browser, they are just a fixed hidden text field or a fixed part of the URL. So the browser just submits back to the server the "timeToken" that the server passed to the browser for the previous request.

Here's another way to be sure we are thinking the same way... here's pseudocode for a JSP that would do this check - it has been a while since I've done JSP, so I didn't bother making sure I got the syntax right, but hopefully it will help.

...
<%
    String prevTimeToken = session.getAttribute("timeToken");
    String submittedTimeToken = request.getParameter("timeToken");
    String newTimeToken = null;
 
    if ((submittedTimeToken == null) || (! submittedTimeToken.equals(prevTimeToken)) {
        // jsp:forward to an error page...
    } else {
        newTimeToken = new Date().toString();
        session.setAttribute("timeToken", newTimeToken);
    }
 
    // ... now go on and finish building the page
%>
 
... and then at some point, you would have:
 
<a href="nextPage.jsp?timeToken=<%= URLEncoder.encode(newTimeToken) %>">
 
<form action="nextPage.jsp" method=post>
<input type=hidden name=timeToken value="<%= newTimeToken %>">
 
... or, might even be able to make that
 
<form action="nextPage.jsp?timeToken=<%= URLEncoder.encode(newTimeToken) %>" method=post>
... and forget the hidden variable
 

So then, the generated HTML would be something like this:

<html>
...
<form action="nextPage.jsp?timeToken=Wed%20May%2018%2C%202005%2008%3A52%3A35%20AM%20EDT" method=post>
...
</html>

So, see if that helps my replies make sense:

When first req happens from login.jsp--> pg1.jsp , the url gets updated to pg1.jsp?timeToken=X

The way I saw it, in STEP 1, the request sent by the browser is ONLY to get pg1.jsp - I didn't see the login.jsp as passing any "timeToken" at all. The response from the server would contain "timeToken=X", because that's what time STEP 1 occurred. That value of "timeToken=X" would either be in a hidden form element or embedded in the links that are within pg1.jsp... and that is the value that will be submitted (in STEP 2) when that form is submitted, or that link is clicked.

and pg1.jsp-->pg2.jsp the url should get updated to pg2.jsp?timeToken=Y

This is the step 2 request, which is submitting the form (or link) built when the server responded to step 1 request - so the request sent from the user to the server contains the "timeToken" from the response portion of STEP 1 (which is X). The response to Step 2 will contain timeToken=Y, because step 2 happened at time Y.

so at this time when the user presses Ctrl-N token will go as Y rather than X.

Hope it has something to do with whether u send the timeToken in URL or not ...... and currently i have frames in my application

so can u tell me how much feasibility that has

Again, I still think it will be as I have stated.


-- Jon
[ May 18, 2005: Message edited by: Jon Egan ]