• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Can someone explain whats happening ?

 
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I have a jsp tool which shows results of queries. There are two types of users for this tool, one with read/write permission and one with read-only permission. Depending on the permissions for a logged-in user, results are shown in input boxes(for read-write permission) or labels(for read-only). I was checking the jsp displays of this tool with two instances of Internet Explorer and two instances of Netscape Communicator. In one instance of IE and NC, I logged in with read-write permissions, and in the second instances, I logged in with read-only permissions.
First I viewed a jsp page in NC,with readonly permission. Next, I viewed the same page, with read-write permission, in the next instance of NC. Then, when I Reloaded the second instance of NC(which had input boxes till now), I got a display corresponding to read-only permission, ie, with labels.
The way I'm storing permissions for every logged-in user is through session variables. When the user logs in, his credentials are checked and appropriate permissions are given, which are stored in the session.
I did not notice this behaviour in IE, but I could repeatedly get this is Netscape. What is causing this change of permissions ? Is there something that I have completely overlooked ?
Any response will be very helpful.
Thanks.
 
Mallika Kumar
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I take back what I said above....I'm seeing the same behaviour with Internet Explorer too!!! The version of Netscape that I'm using is 4.72 and Internet Explorer is 4.0.
 
Ranch Hand
Posts: 149
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Mallika
When you open IE with a new window (or control N), it uses the same sessionid as the first window.. So essentially, if you login as the second user in this window, you blow away the sessions created for the first window. If you click on the desktop icon to open it, you get a new id and these two are now using different sesions, maintaining unique identities.
I'm guessing this is why you first said it works in IE (opened by clicking desktop icon) and then said no (opened by file ->new window)
Netscape always uses the same id, no matter how u open it. It uses the same internal thread..
 
Ranch Hand
Posts: 3695
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I thought sessions were linked to machines (IP) not browser instances. Isn't it impossible for a single user to fake-out a session on a single machine by using two browsers?
 
Mallika Kumar
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Mak. That was certainly helpful.
 
Maky Chopra
Ranch Hand
Posts: 149
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Mike..
By default, your JSP application participates in the session tracking mechanism. Every time a new user requests a JSP page that uses HTTPSession objects, the JSP container sends back a response plus a special number to the browser. This special number is called a session identifier and is guaranteed as a unique user identifier. The HTTPSession object resides in memory waiting for its methods to be called again when the same user returns.
On the client side, the browser keeps the session identifier and sends it back to the server on the next request. This session identifier tells the JSP container that this request is not a first visit by the user and that a HTTPSession object has been created for this user. Instead of creating a new HTTPSession object, the JSP container then looks for a HTTPSession object with the same session identifier and associates the request with the HTTPSession object.
Session identifiers are transmitted between the server and the browser as cookies. What if the browser doesn't accept cookies? All subsequent requests to the server will not carry a session identifier. As a result, the JSP container will think it is a request from a new user, and it will create a HTTPSession object again, and the previous HTTPSession object remains in memory and the previous state information for that user is lost.
Further a session identifier can only be recognized by the JSP container that issues it. If you have copies of your application installed in more than one machine in a web farm, there must be a way to guarantee that requests from the same user will be directed to the server that first handles the user's request.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic