limit internal users open just one browser from the server

[c676228]

Hi all,
I am thinking about doing this since I got several cases that some of our
internal users open more than one browser at the same time from our server.
When one of the transactions was not completed finished, the second browser
jusk pick up some session variables from the first browser and process right
after that. It messed up everything.

I was thinking about use remote_addr, but it seems not working since we are
behind the firewall and every user's IP inside the company network to the
internet is the same.
It seems that I have to use internal userID and record this in the database
and when any page is requested, I have to check in the database to see if the
user is connected then decide if the page should be display or not.
Is there any better way?
Thank you.

 

[Bob Lehmann]

How would you tell which browser window they were connecting from?

Bob Lehmann

 

[Mark McGinty]

Hi all,
I am thinking about doing this since I got several cases that some of our
internal users open more than one browser at the same time from our
server.
When one of the transactions was not completed finished, the second
browser
jusk pick up some session variables from the first browser and process
right
after that. It messed up everything.

Sounds to me like poor design, like maybe an entry point script that posts
to itself one or more times to perform successive segments of a
transactional process, while trying to use session data to track the
current/determine the next segment.

Session data is not a workable option for that purpose. Aside from the
multiple open browsers problem you're seeing, what if the browser is closed
after the first, but before the last segment? What if something holds-up
the flow between segments, and the session expires before the next segment
is executed?

If the process is transactional in nature, you should generate an ID value
for each one when you construct the page from which the user will launch it,
and then pass that ID to each segment as a URL parameter or hidden form
input. Use that ID to facilitate isolation logic, i.e., a positive
mechanism to prevent unrelated requests from the same user from interfering
with a transaction in progress.

You might also want split some segments of the process to separate script
files, but if not, pass the value that determines which segment to execute
as a hidden input, rather than storing that value in the session from one
segment, and reading it back from the session for each request, and
branching to a segment based thereupon.

I was thinking about use remote_addr, but it seems not working since we
are
behind the firewall and every user's IP inside the company network to the
internet is the same.

Even if that were not the case, multiple requests from a single given client
system will have the same client IP, and even if *that* were not the case,
identifying the client system does nothing to identify whether/if multiple
browser windows are open on that client.

It seems that I have to use internal userID and record this in the
database
and when any page is requested, I have to check in the database to see if
the
user is connected then decide if the page should be display or not.

Again, even if there is a flawless way to do this, in the purest sence, it's
irrelevant. Why does every incoming request from a given client need to
pertain to a single transaction in progress? (In absence of bad design, the
answer is: there is no reason.)

From a user's perspective I have to tell you, I litteraly despise sites that
impose such limits on my session. Case in point, the amtrak.com site.
Booking travel on amtrak.com is a text-book example of a multi-segment
transactional process, but in many cases the list of trains available to
service some segment of your desired itinerary is artificially limited -- it
doesn't give you a big-picture view. There may be multiple ways to reach
point B from point A, not all are equal to say the least!

The site used to allow the user to have multiple browsers interactively open
at once, which allowed "what if" queries, viewing route maps/schedules, etc,
without sacrificing all your input so far in your "real" reservation
process -- what if I left on Monday instead of Sunday? What if I travel
early in the morning instead of afternoon? It can make a huge difference.
(Example: San Diego, CA to San Luis Obispo, CA. One route takes 6 hours on
a single train; another takes 14 hours with 4 lay-overs and two connecting
bus segments -- and you can't check your baggage, *and* it costs $20 more!
Option A: fast, comfortable, stress-free; option B: trip from hell!)

In any case, before I ramble on forever, after they re-factored the site,
opening a new browser on the site blows any reservations in progress. Worse
yet, when reserved seats were selected in a reservation that gets blown-out,
those reserved seats are somehow encumbered for some irritatingly long
timeout...


For whatever it's worth...


-Mark

 

[Steven Cheng[MSFT]]

Hello Betty,

Mark has posted many suggestion on this.

IMO, there are two things you need to consider here:

**How do you distinguish the client requests. I don't think distinguish
client through browser a good idea. Is your web application required to get
the user/account info from client(the operation is based on per user
specific)? If so, you need a approach to correctly assocate each request
with a certain user. (one way is simply rely on session state to
distinguish client users).

** After you've determined which user each requests belongs to, you can
define how you will control the concurrent access to the resource(to
perform the certain operation). For example, you can store a session
variable for given user to indicate whether the operation is currently
being processed and not available. And when this operation has begun on a
given user, you set this flag variable to "false"(indicate that this
operation is unavailable) on this user. Then, any sequential requests
(associated with the same user) which want to perform the same operation
will be denied(based on checking that flag variable)

How do you think of this? Please feel free to post here if you have any
other questions or concerns.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



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.

 

[c676228]

Mark,
Thank you very much for your detailed message and sensible comments with a
good exmaple, that definitely helps. I agree with you that we should not pose
that kind of limit. I will present my understanding in details below. You can
check if I get your points.
First of all, we did have some holes in our initial design. for example, our
ID is created by Javascript, which probably is not a best choice, I would
prefer server side script. Besides there is a big bug there which I think is
one of the reason how come the server pick up the same data. As you can see
when the first browser created the first Order_ID and if the second browser
was opened, it looks for the order_id in the cookie. So what I will do is
remove that part of the code and will enforce whenever a new page is opened,
a new order_id will be created.

2) The initial motivation to use session variables is before many of our
customers complained about the data disapearing problem after a form was
submitted and they click back button and the data they entered disappeared.
So I used the session variable to maintain the data in the data entry fields.
In this case in order to avoid second browser to pick up session data from
the first browser(traveling date), I always need to request field data
first(i.e., probably different traveling date) and then set session
variables. Is that good enough? I don't know how other companyies dealing
with the case if the page is in the middle of program segment and somehow is
expired, my program is just ask the user starts from the beginning.
If the user abandon a page in the middle, is there a good to clean the
resources likc object and database connection?

asCookie = (document.cookie).split (";");
for (i = 0; i < asCookie.length; i++)
{
pairs = asCookie .split ("=");
if (pairs [0].indexOf ("OrderId") != -1)
{
OrderID = pairs [1];
}
}
...
// Check if OrderID is within the acceptable range
if (nTISLength < 15 || nTISLength > 18)
{
...
OrderID = CCFormatDateTime(dNow); // Create New Order ID
sDateAndPath = "path=/;expires=" + dExpire.toUTCString();
document.cookie = "OrderID=" + OrderID + ";" + sDateAndPath;
}
document.formname.order_id.value = OrderID;

 

[c676228]

Hi Steven,
Thank you for your suggestions. I believe both ways are doable.
Based on Mark's comment, maybe I should have reconsider it again. I just
posed a message to reply him and when I submitted it just gave me a blank
page, I have to check to see if I need to rewite that one.
Thank you so much.
Betty

 

[Steven Cheng[MSFT]]

Thanks for the reply.

No problem. Please feel free to post here whenever you've got any further
questions to discuss.

Good luck!

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


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