limit internal users open just one browser from the server

Discussion in 'ASP General' started by c676228, Feb 9, 2007.

  1. c676228

    c676228 Guest

    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
     
    c676228, Feb 9, 2007
    #1
    1. Advertising

  2. c676228

    Bob Lehmann Guest

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

    Bob Lehmann

    "c676228" <> wrote in message
    news:...
    > 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
     
    Bob Lehmann, Feb 9, 2007
    #2
    1. Advertising

  3. c676228

    Mark McGinty Guest

    "c676228" <> wrote in message
    news:...
    > 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
     
    Mark McGinty, Feb 11, 2007
    #3
  4. 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.
     
    Steven Cheng[MSFT], Feb 12, 2007
    #4
  5. c676228

    c676228 Guest

    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;
    --
    Betty


    "Mark McGinty" wrote:

    >
    > "c676228" <> wrote in message
    > news:...
    > > 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

    >
    >
    >
     
    c676228, Feb 13, 2007
    #5
  6. c676228

    c676228 Guest

    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/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, Feb 13, 2007
    #6
  7. 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.
     
    Steven Cheng[MSFT], Feb 14, 2007
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Emil
    Replies:
    2
    Views:
    3,596
  2. Replies:
    1
    Views:
    1,089
    Victor Bazarov
    Jun 28, 2005
  3. carmelo
    Replies:
    8
    Views:
    413
    carmelo
    Jul 23, 2008
  4. Bernie Beattie

    WebParts - can you transfer one users choice to all users?

    Bernie Beattie, Sep 6, 2006, in forum: ASP .Net Web Controls
    Replies:
    0
    Views:
    140
    Bernie Beattie
    Sep 6, 2006
  5. Replies:
    8
    Views:
    123
    Peter J. Holzer
    Aug 29, 2008
Loading...

Share This Page