Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > ASP General > limit internal users open just one browser from the server

Reply
Thread Tools

limit internal users open just one browser from the server

 
 
c676228
Guest
Posts: n/a
 
      02-09-2007
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.
--
Betty
 
Reply With Quote
 
 
 
 
Bob Lehmann
Guest
Posts: n/a
 
      02-09-2007
How would you tell which browser window they were connecting from?

Bob Lehmann

"c676228" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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.
> --
> Betty



 
Reply With Quote
 
 
 
 
Mark McGinty
Guest
Posts: n/a
 
      02-11-2007

"c676228" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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



> Is there any better way?
> Thank you.
> --
> Betty



 
Reply With Quote
 
Steven Cheng[MSFT]
Guest
Posts: n/a
 
      02-12-2007
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/subscripti...ult.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/subscripti...t/default.aspx.

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



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

 
Reply With Quote
 
c676228
Guest
Posts: n/a
 
      02-13-2007
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 [i].split ("=");
if (pairs [0].indexOf ("OrderId") != -1)
{
OrderID = pairs [1];
}
}
...
// Check if OrderID is within the acceptable range
if (nTISLength < 15 || nTISLength > 1
{
...
OrderID = CCFormatDateTime(dNow); // Create New Order ID
sDateAndPath = "path=/;expires=" + dExpire.toUTCString();
document.cookie = "OrderID=" + OrderID + ";" + sDateAndPath;
}
document.formname.order_id.value = OrderID;
--
Betty


"Mark McGinty" wrote:

>
> "c676228" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > 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
>
>
>
> > Is there any better way?
> > Thank you.
> > --
> > Betty

>
>
>

 
Reply With Quote
 
c676228
Guest
Posts: n/a
 
      02-13-2007

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]" wrote:

> 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/subscripti...ult.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/subscripti...t/default.aspx.
>
> ==================================================
>
>
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>

 
Reply With Quote
 
Steven Cheng[MSFT]
Guest
Posts: n/a
 
      02-14-2007
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.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
The Web server reported the following error when attempting to create or open the Web project located at the following URL: 'http://localhost/822319ev1'. 'HTTP/1.1 500 Internal Server Error'. chanmm ASP .Net 2 09-07-2010 07:37 AM
Pix 506e w/5 static outside IPs - How to create a rule to allow ALL tcp/udp traffic from one outside IP to an internal IP (for an internal router/NAT with it's own subnet) kyoo Cisco 22 04-12-2008 03:37 PM
837. Unable to see internal web server from internal server. eric the brave Cisco 0 03-05-2006 01:52 PM
c program, file size limit, how to solve? 2G bytes limit. guru.slt@gmail.com C++ 1 06-27-2005 11:05 PM
Internal Client Accessing Internal Server Via Public IP Address GeekMarine1972 Cisco 1 01-15-2005 02:49 AM



Advertisments