• 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

low-level understanding of http/struts/beans

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello all,

i've been playing with Struts for some time and really like the framework.

The thing i have been wondering is how the HTTP really works. For example when I'm doing a password secured application, I like to add a UserBean to the session scope when user goes through the LoginAction. The bean contains all the necessary information about the user I'll would like to have available while the user is using the application.

The question: is the UserBean really transferred to the client via HTTP or does the HTTP/app.server simply keep a somekind of a reference to the bean?

The reason I'm asking is that I've been wondering about the security issues. If the bean is really transferred to the client, can somebody with knowledge "decrypt" the bean and read all of its data?

Thanks.

- John
 
Ranch Hand
Posts: 4864
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When an HttpSession is created for a user, that session and all objects associated with it exist strictly on the server. It is not transferred back and forth to the browser. The way that most application servers keep track of sessions is with cookies. The way this works is that when the App Server creates a session for you, it puts a cookie on your browser. In that cookie is a unique session ID which tells the App Server which session is yours.

The only way that a third party could access this data would be to either guess the session ID (very unlikely) or to listen in on your interactions with the server and then create a cookie with the same session ID on their browser. If you're worried about this, using HTTPS will prevent a third party from listening in on the transaction.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic