RE: Association between Session object and Cookies/URL rewriting
Hi, It is not CMS. Will take a look at the security filter. Mohan -Original Message- From: Max Cooper [mailto:[EMAIL PROTECTED] Sent: Friday, March 07, 2003 1:30 PM To: Struts Users Mailing List Subject: Re: Association between Session object and Cookies/URL rewriting Requirement is this : My login page itself expires even if the user doesn't login for the session timeout period. We want to prevent that. Hmm... I don't think there is much you can do in that case with container-managed security. If the user fails to login within the session expiration time, their session will expire. When the user then submits the login form, it will look like a spontaneous login to the server, which is not supported with container-managed security, and will cause an error (on Tomcat at least; WebLogic does something a little different, but I think the different behaviors just highlight the reason why depending on this setup is risky). The SecurityFilter project supports this kind of operation to some extent. The session will still expire, so the server will not be able to take the user directly to the protected page that caused the login form to appear. But SecurityFilter supports the configuration of a 'default page' to send the user to if they login without an active session, or simply submit a login form without being sent there by the filter. http://securityfilter.sourceforge.net/ -Max - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Association between Session object and Cookies/URL rewriting
Tomcat is responsible of the cookie creation but it is the Struts Action Servlet that is responsible of the session (HttpSession initialization) isn't it ? A few months ago I had had a discussion with Craig and it had indicated to me that a session was initialized in several cases: * The controller servlet will create a session for you, if you declare that your form bean is in session scope. * The controller servlet will create a session for you, if you configured the automatic locale recognition mechanism (the locale servlet initialization parameter for 1.0, or the corresponding attribute on the controller element for 1.1). * Your application Action can create a session if it needs to, by calling request.getSession(). * Actions will create a session for you automatically if you use transaction tokens, or the getLocale()/setLocale() methods. * JSP pages will create a session for you automatically unless you explicitly tell them not to (%@ page ... session=false ... %). * The html:html tag will create a session for you automatically if you use locale=true. * The html:form tag will create a session for you automatically if your form bean is in request scope, or if you are using transaction tokens. I don't understand how the controller distinguish a client X from a client Y ? what parameter/information allow to identify a client ? As I said yesterday in my application two clients have not the same authentication information (userLogin and password). If a client X enter the URL http::\\localhost:8080\MyAppli, when the home page is displayed if the form is in the session an HttpSession is created isn't it ? but the client has not yet given his userLogin and password. If a new browser is open on the same PC with the URL of the application is a new HttpSession is created ? Normally a new session must be created only if login information is different from the first client's browser. But on the Home page we do not have to carry out the Login action yet. Do you understand my question ? --- As of February 12, 2003 Thomson unifies its email addresses on a worldwide basis.Please note my new email address: [EMAIL PROTECTED] Thomson is the leader in solutions and technologies for the entertainment and media industries and serves its customers under its four strategic brands: Technicolor, Grass Valley, RCA and THOMSON. More about Thomson: http://www.thomson.net/videochain Original Message- From: Nicolas De Loof [mailto:[EMAIL PROTECTED] Sent: 05 March 2003 14:53 To: Struts Users Mailing List Subject: Re: Association between Session object and Cookies/URL rewriting Struts doesn't create coockies, J2EE servlet container does (tomcat). When you use request.getSession() in your code, J2EE server will a coockie (or a request parameter if URL rewriting is used, see your server config) to get the session ID. If no ID is set, it will generate a new session ID and add a set-coockie HTTP header in response. New request from user browser will come to the server with a SESSIONID coockie header, and request.getSession() implementation will be able to find the session object from ID. Read J2EE or Tomcat documentation to get more infos on sessions (sessionid coockie, URL rewriting ...). Nico. I don't understand very well how Struts manages session objects and why a sessionID is fixed for a user ? Session objects are stored on the web server (Tomcat in my case) and cookie saved on the disk allows to retrieve the HttpSession associated to a user. But I don't understand how the cookie is created and why is it associated to a client ? How Struts creates the session cookie ? I read that the cookie object is created when a user first loads a web page that is a part of the application. But at this stage what distinguishes a user X from a user Y ? In my application I distinguish two users with authentication information but when the first page is displayed the authentication is not done. How Struts know that it is a new user and that it has to create a new HtppSession and a new cookie? Is a user (and so a cookie) associated to a user NT account ? I am not certain to have been rather clear Thanks in advance for your help. Sandra --- As of February 12, 2003 Thomson unifies its email addresses on a worldwide basis.Please note my new email address: [EMAIL PROTECTED] Thomson is the leader in solutions and technologies for the entertainment and media industries and serves its customers under its four strategic brands: Technicolor, Grass Valley, RCA and THOMSON. More about Thomson: http://www.thomson.net/videochain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
RE: Association between Session object and Cookies/URL rewriting
Hi, Exactly what happens with my pet project here. The login page times out before the user logs in after the specified timeout period. I have been pulling my hair all day. Need more explanation. I am using setLocale in the base action which my login action is extending. I do understand the question. Mohan If a client X enter the URL http::\\localhost:8080\MyAppli, when the home page is displayed if the form is in the session an HttpSession is created isn't it ? but the client has not yet given his userLogin and password. If a new browser is open on the same PC with the URL of the application is a new HttpSession is created ? Normally a new session must be created only if login information is different from the first client's browser. But on the Home page we do not have to carry out the Login action yet. Do you understand my question ? --- As of February 12, 2003 Thomson unifies its email addresses on a worldwide basis.Please note my new email address: [EMAIL PROTECTED] Thomson is the leader in solutions and technologies for the entertainment and media industries and serves its customers under its four strategic brands: Technicolor, Grass Valley, RCA and THOMSON. More about Thomson: http://www.thomson.net/videochain Original Message- From: Nicolas De Loof [mailto:[EMAIL PROTECTED] Sent: 05 March 2003 14:53 To: Struts Users Mailing List Subject: Re: Association between Session object and Cookies/URL rewriting Struts doesn't create coockies, J2EE servlet container does (tomcat). When you use request.getSession() in your code, J2EE server will a coockie (or a request parameter if URL rewriting is used, see your server config) to get the session ID. If no ID is set, it will generate a new session ID and add a set-coockie HTTP header in response. New request from user browser will come to the server with a SESSIONID coockie header, and request.getSession() implementation will be able to find the session object from ID. Read J2EE or Tomcat documentation to get more infos on sessions (sessionid coockie, URL rewriting ...). Nico. I don't understand very well how Struts manages session objects and why a sessionID is fixed for a user ? Session objects are stored on the web server (Tomcat in my case) and cookie saved on the disk allows to retrieve the HttpSession associated to a user. But I don't understand how the cookie is created and why is it associated to a client ? How Struts creates the session cookie ? I read that the cookie object is created when a user first loads a web page that is a part of the application. But at this stage what distinguishes a user X from a user Y ? In my application I distinguish two users with authentication information but when the first page is displayed the authentication is not done. How Struts know that it is a new user and that it has to create a new HtppSession and a new cookie? Is a user (and so a cookie) associated to a user NT account ? I am not certain to have been rather clear Thanks in advance for your help. Sandra --- As of February 12, 2003 Thomson unifies its email addresses on a worldwide basis.Please note my new email address: [EMAIL PROTECTED] Thomson is the leader in solutions and technologies for the entertainment and media industries and serves its customers under its four strategic brands: Technicolor, Grass Valley, RCA and THOMSON. More about Thomson: http://www.thomson.net/videochain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Association between Session object and Cookies/URL rewriting
HttpSession is a seperate matter from authentication as far as the container is concerned, in as much as session tracking operates to associate requests with a particular client. The way it does this is by allocated a session id - which the client submits with each request. There are two ways that this id can be submitted. The first (and I believe the default) is to make use of cookies. If the container is giving the client a session and the client has cookies enabled, the container will return to the client a cookie that contains the session id, and the client borwser submits this with its requests allowing the container to identify which session the request belongs to. This mechanism works almost transparently both to the user and the developer. The second way - url rewriting - operates when cookies are disabled on the client (and it is considered best practise to allow for this possibility as a lot of users are getting paranoid about cookies these days). This involves all links that are displayed in the browser including the session id as part of the url - so you will see urls of the form: http://www.mystery-machine.com/shaggy/scooby.do;jsessionid=4878D95252DE47FDC 39E69070F49F397 Obviously for the links to contain the session id the developer has to do a bit more work - basically requiring all links to pages/actions participating in that session to be 'rewritten'. The struts html:link tag will do this for any links you render with it automatically, - I presume the html:form tag will also do it for its action (I dont use jsp so arent entirely sure but it would seem logical). If you need to do it yourself somewhere the servlet apis HttpServletResponse also supplies an encodeUrl() method that when passed a string containing a plain url will add the session id if necessary and return the encoded url string to you. -Original Message- From: Heligon Sandra [mailto:[EMAIL PROTECTED] Sent: Thursday, 6 March 2003 16:41 To: 'Struts Users Mailing List' Subject: RE: Association between Session object and Cookies/URL rewriting Importance: High Tomcat is responsible of the cookie creation but it is the Struts Action Servlet that is responsible of the session (HttpSession initialization) isn't it ? A few months ago I had had a discussion with Craig and it had indicated to me that a session was initialized in several cases: * The controller servlet will create a session for you, if you declare that your form bean is in session scope. * The controller servlet will create a session for you, if you configured the automatic locale recognition mechanism (the locale servlet initialization parameter for 1.0, or the corresponding attribute on the controller element for 1.1). * Your application Action can create a session if it needs to, by calling request.getSession(). * Actions will create a session for you automatically if you use transaction tokens, or the getLocale()/setLocale() methods. * JSP pages will create a session for you automatically unless you explicitly tell them not to (%@ page ... session=false ... %). * The html:html tag will create a session for you automatically if you use locale=true. * The html:form tag will create a session for you automatically if your form bean is in request scope, or if you are using transaction tokens. I don't understand how the controller distinguish a client X from a client Y ? what parameter/information allow to identify a client ? As I said yesterday in my application two clients have not the same authentication information (userLogin and password). If a client X enter the URL http::\\localhost:8080\MyAppli, when the home page is displayed if the form is in the session an HttpSession is created isn't it ? but the client has not yet given his userLogin and password. If a new browser is open on the same PC with the URL of the application is a new HttpSession is created ? Normally a new session must be created only if login information is different from the first client's browser. But on the Home page we do not have to carry out the Login action yet. Do you understand my question ? --- As of February 12, 2003 Thomson unifies its email addresses on a worldwide basis.Please note my new email address: [EMAIL PROTECTED] Thomson is the leader in solutions and technologies for the entertainment and media industries and serves its customers under its four strategic brands: Technicolor, Grass Valley, RCA and THOMSON. More about Thomson: http://www.thomson.net/videochain Original Message- From: Nicolas De Loof [mailto:[EMAIL PROTECTED] Sent: 05 March 2003 14:53 To: Struts Users Mailing List Subject: Re: Association between Session object and Cookies/URL rewriting Struts doesn't create coockies, J2EE servlet container does (tomcat). When you use request.getSession() in your code, J2EE server will a coockie (or a request parameter if URL rewriting is used, see your server config
RE: Association between Session object and Cookies/URL rewriting
I well understand now that Sessions (object on the web server) are used either cookies or URL writing (in the client side). In the struts application I have to make changes if I want to use URL rewriting. But what I still do not understand (I am sorry to be also insistent) is why/or how each user will have a own unique sessionID ?. How a user is identified? What distinguish a client from an other client ? Is the user NT account ? Perhaps a client is not a physical person but an instance of Web browser , is this as that which should be heard it ? Mohan, could you explain me I am using setLocale in the base action. I don't understand well what setLocale allows? --- As of February 12, 2003 Thomson unifies its email addresses on a worldwide basis.Please note my new email address: [EMAIL PROTECTED] Thomson is the leader in solutions and technologies for the entertainment and media industries and serves its customers under its four strategic brands: Technicolor, Grass Valley, RCA and THOMSON. More about Thomson: http://www.thomson.net/videochain Original Message- From: Andrew Hill [mailto:[EMAIL PROTECTED] Sent: 06 March 2003 10:07 To: Struts Users Mailing List Subject: RE: Association between Session object and Cookies/URL rewriting HttpSession is a seperate matter from authentication as far as the container is concerned, in as much as session tracking operates to associate requests with a particular client. The way it does this is by allocated a session id - which the client submits with each request. There are two ways that this id can be submitted. The first (and I believe the default) is to make use of cookies. If the container is giving the client a session and the client has cookies enabled, the container will return to the client a cookie that contains the session id, and the client borwser submits this with its requests allowing the container to identify which session the request belongs to. This mechanism works almost transparently both to the user and the developer. The second way - url rewriting - operates when cookies are disabled on the client (and it is considered best practise to allow for this possibility as a lot of users are getting paranoid about cookies these days). This involves all links that are displayed in the browser including the session id as part of the url - so you will see urls of the form: http://www.mystery-machine.com/shaggy/scooby.do;jsessionid=4878D95252DE47FDC 39E69070F49F397 Obviously for the links to contain the session id the developer has to do a bit more work - basically requiring all links to pages/actions participating in that session to be 'rewritten'. The struts html:link tag will do this for any links you render with it automatically, - I presume the html:form tag will also do it for its action (I dont use jsp so arent entirely sure but it would seem logical). If you need to do it yourself somewhere the servlet apis HttpServletResponse also supplies an encodeUrl() method that when passed a string containing a plain url will add the session id if necessary and return the encoded url string to you. -Original Message- From: Heligon Sandra [mailto:[EMAIL PROTECTED] Sent: Thursday, 6 March 2003 16:41 To: 'Struts Users Mailing List' Subject: RE: Association between Session object and Cookies/URL rewriting Importance: High Tomcat is responsible of the cookie creation but it is the Struts Action Servlet that is responsible of the session (HttpSession initialization) isn't it ? A few months ago I had had a discussion with Craig and it had indicated to me that a session was initialized in several cases: * The controller servlet will create a session for you, if you declare that your form bean is in session scope. * The controller servlet will create a session for you, if you configured the automatic locale recognition mechanism (the locale servlet initialization parameter for 1.0, or the corresponding attribute on the controller element for 1.1). * Your application Action can create a session if it needs to, by calling request.getSession(). * Actions will create a session for you automatically if you use transaction tokens, or the getLocale()/setLocale() methods. * JSP pages will create a session for you automatically unless you explicitly tell them not to (%@ page ... session=false ... %). * The html:html tag will create a session for you automatically if you use locale=true. * The html:form tag will create a session for you automatically if your form bean is in request scope, or if you are using transaction tokens. I don't understand how the controller distinguish a client X from a client Y ? what parameter/information allow to identify a client ? As I said yesterday in my application two clients have not the same authentication information (userLogin and password). If a client X enter the URL http::\\localhost:8080\MyAppli, when the home page
Re: Association between Session object and Cookies/URL rewriting
I well understand now that Sessions (object on the web server) are used either cookies or URL writing (in the client side). In the struts application I have to make changes if I want to use URL rewriting. But what I still do not understand (I am sorry to be also insistent) is why/or how each user will have a own unique sessionID ?. How a user is identified? What distinguish a client from an other client ? Is the user NT account ? Perhaps a client is not a physical person but an instance of Web browser , A client is not a physical person but an instance of a browser : When J2EE server doesn't get any session info from request (form coockie or request parameter if url rewriting is used), it will generate a new session id for client. Every new request from this browser will come with sessionid, and a pseudo-connection will be maintained between browser and server. A user is indentified by the browser instance it is using. Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Association between Session object and Cookies/URL rewriting
Hi,
I looked at all the conditions in Craig's mail that you included.
* Actions will create a session for you automatically if you use
transaction tokens, or the getLocale()/setLocale() methods.
My BaseAction that my LoginAction extends has code like this.
protected void setLocale(
HttpServletRequest request,
Locale locale) {
HttpSession session = request.getSession(true);
session.setAttribute( Action.LOCALE_KEY,locale );
}
My login page expires after the session timeout period even before the user
logs in . So I thought that since a new session is already created (
according to the above mentioned point ) and I am using request.getSession()
( not request.getSession( true ) ) and the setLocale method it is normal for
the login page itself to expire.
Is that right ?
Mohan
-Original Message-
From: Heligon Sandra [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 06, 2003 2:55 PM
To: 'Struts Users Mailing List'
Subject: RE: Association between Session object and Cookies/URL
rewriting
I well understand now that Sessions (object on the web server) are
used either cookies or URL writing (in the client side).
In the struts application I have to make changes if I want to
use URL rewriting.
But what I still do not understand (I am sorry to be also insistent) is
why/or how each user will have a own unique sessionID ?.
How a user is identified?
What distinguish a client from an other client ?
Is the user NT account ?
Perhaps a client is not a physical person but an instance of Web browser ,
is this as that which should be heard it ?
Mohan, could you explain me I am using setLocale in the base action.
I don't understand well what setLocale allows?
---
As of February 12, 2003 Thomson unifies its email addresses on a worldwide
basis.Please note my new email address: [EMAIL PROTECTED]
Thomson is the leader in solutions and technologies for the entertainment
and media industries and serves its customers under its four strategic
brands: Technicolor, Grass Valley, RCA and THOMSON.
More about Thomson: http://www.thomson.net/videochain
Original Message-
From: Andrew Hill [mailto:[EMAIL PROTECTED]
Sent: 06 March 2003 10:07
To: Struts Users Mailing List
Subject: RE: Association between Session object and Cookies/URL
rewriting
HttpSession is a seperate matter from authentication as far as the container
is concerned, in as much as session tracking operates to associate requests
with a particular client. The way it does this is by allocated a session
id - which the client submits with each request.
There are two ways that this id can be submitted.
The first (and I believe the default) is to make use of cookies. If the
container is giving the client a session and the client has cookies enabled,
the container will return to the client a cookie that contains the session
id, and the client borwser submits this with its requests allowing the
container to identify which session the request belongs to. This mechanism
works almost transparently both to the user and the developer.
The second way - url rewriting - operates when cookies are disabled on the
client (and it is considered best practise to allow for this possibility as
a lot of users are getting paranoid about cookies these days). This involves
all links that are displayed in the browser including the session id as part
of the url - so you will see urls of the form:
http://www.mystery-machine.com/shaggy/scooby.do;jsessionid=4878D95252DE47FDC
39E69070F49F397
Obviously for the links to contain the session id the developer has to do a
bit more work - basically requiring all links to pages/actions participating
in that session to be 'rewritten'. The struts html:link tag will do this
for any links you render with it automatically, - I presume the html:form
tag will also do it for its action (I dont use jsp so arent entirely sure
but it would seem logical).
If you need to do it yourself somewhere the servlet apis HttpServletResponse
also supplies an encodeUrl() method that when passed a string containing a
plain url will add the session id if necessary and return the encoded url
string to you.
-Original Message-
From: Heligon Sandra [mailto:[EMAIL PROTECTED]
Sent: Thursday, 6 March 2003 16:41
To: 'Struts Users Mailing List'
Subject: RE: Association between Session object and Cookies/URL
rewriting
Importance: High
Tomcat is responsible of the cookie creation but it is
the Struts Action Servlet that is responsible of the
session (HttpSession initialization) isn't it ?
A few months ago I had had a discussion with Craig and it had indicated
to me that a session was initialized in several cases:
* The controller servlet will create a session for you, if you
declare that your form bean is in session scope.
* The controller servlet will create a session for you, if you
configured the automatic locale
RE: Association between Session object and Cookies/URL rewriting
but however if one uses the cookies for saving the sessionId on the customer, the cookie is saved under a user directory C:\WINNT\Profiles\user-name\Cookies. the user-name reprensents a physical person for cookie information, isn't it ? --- As of February 12, 2003 Thomson unifies its email addresses on a worldwide basis.Please note my new email address: [EMAIL PROTECTED] Thomson is the leader in solutions and technologies for the entertainment and media industries and serves its customers under its four strategic brands: Technicolor, Grass Valley, RCA and THOMSON. More about Thomson: http://www.thomson.net/videochain Original Message- From: Nicolas De Loof [mailto:[EMAIL PROTECTED] Sent: 06 March 2003 10:32 To: Struts Users Mailing List Subject: Re: Association between Session object and Cookies/URL rewriting I well understand now that Sessions (object on the web server) are used either cookies or URL writing (in the client side). In the struts application I have to make changes if I want to use URL rewriting. But what I still do not understand (I am sorry to be also insistent) is why/or how each user will have a own unique sessionID ?. How a user is identified? What distinguish a client from an other client ? Is the user NT account ? Perhaps a client is not a physical person but an instance of Web browser , A client is not a physical person but an instance of a browser : When J2EE server doesn't get any session info from request (form coockie or request parameter if url rewriting is used), it will generate a new session id for client. Every new request from this browser will come with sessionid, and a pseudo-connection will be maintained between browser and server. A user is indentified by the browser instance it is using. Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Association between Session object and Cookies/URL rewriting
right, but if you restart your browser, session will be invalidated, as coockie is (by default) set to a browser instance. The way coockies are stored on windows (NT) platform has no impact on session tracking mechanism. Nico. but however if one uses the cookies for saving the sessionId on the customer, the cookie is saved under a user directory C:\WINNT\Profiles\user-name\Cookies. the user-name reprensents a physical person for cookie information, isn't it ? --- As of February 12, 2003 Thomson unifies its email addresses on a worldwide basis.Please note my new email address: [EMAIL PROTECTED] Thomson is the leader in solutions and technologies for the entertainment and media industries and serves its customers under its four strategic brands: Technicolor, Grass Valley, RCA and THOMSON. More about Thomson: http://www.thomson.net/videochain Original Message- From: Nicolas De Loof [mailto:[EMAIL PROTECTED] Sent: 06 March 2003 10:32 To: Struts Users Mailing List Subject: Re: Association between Session object and Cookies/URL rewriting I well understand now that Sessions (object on the web server) are used either cookies or URL writing (in the client side). In the struts application I have to make changes if I want to use URL rewriting. But what I still do not understand (I am sorry to be also insistent) is why/or how each user will have a own unique sessionID ?. How a user is identified? What distinguish a client from an other client ? Is the user NT account ? Perhaps a client is not a physical person but an instance of Web browser , A client is not a physical person but an instance of a browser : When J2EE server doesn't get any session info from request (form coockie or request parameter if url rewriting is used), it will generate a new session id for client. Every new request from this browser will come with sessionid, and a pseudo-connection will be maintained between browser and server. A user is indentified by the browser instance it is using. Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Association between Session object and Cookies/URL rewriting
Session IDs identify sessions, not users. A session is using a browser to access a server from a particular machine. It doesn't matter if you login or not, sessions are meant just to associate a group of requests as coming from one (or more) person sitting at a computer using a browser. HTTP is a stateless protocol, meaning the protocol does not have any built-in way for the server to recognize that several requests are coming from the same session. By using a session cookie (or URL rewriting), the server can track which requests should be associated with a particular session, because all of those requests will include the session ID. Here's a little dialog to illustrate: Ms. Browser (a browser): Hello Mr. Forgetful, please send me the search form. Mr. Forgetful (the server): Welcome, please excuse me not remembering who you are or even if this is your first request or not, but it is not in my protocol to do so. So that I may handle your requests with the highest level of service in the future, please include this SessionID cookie that I am including in your response with your requests. It will help me identify you in the future and perhaps remember your preferences. Ms. Browser: I take no offense to you not remembering me, even though I was just here earlier in the day. I realize it is not in your protocol to do so, and I do appreciate your efforts with the SessionID cookie. I will be sure to include it with all my requests. Please perform a search with the keywords tattoo parlor. Mr. Forgetful: A search for tattoo parlor, eh? I still don't know your name, but I see that you have visited recently; thank you for including the SessionID cookie with your request. Here are your search results. I have included 10 hits per page, as it is the default. Ms. Browser: Thank you, Mr. Forgetful. Can you please run the search for tattoo parlors again and include 25 hits per page this time? Mr. Forgetful: A search for tattoo parlor with 25 hits per page is coming your way. I will remember your preference for 25 hits so that I may format any future searches with the same preference. Thank you for including your SessionID cookie with your request, and please be sure to include it with any future requests so that I may apply your preferences. Ms. Browser: Oh, I see a hit that I would like to view. Please send me information on Sick Dogs Tattoo Parlor. Mr. Forgetful: Whoa! That information requires that you identify yourself before viewing, and I don't have any user information associated with the SessionID cookie that you sent with your request. Please request the login form so that I may verify your access. I will remember the page you were trying to view based on your SessionID for your convenience. Ms. Browser: You must be sending me on some kind of wild goose chase, Mr. Forgetful! Please send me the login form. Mr. Forgetful: Here is the login form, as requested. Ms. Browser: Okay, my username is 'PaintedLady' and my password is 'Butterfly'. Mr. Forgetful: Oh hello, PaintedLady! I have associated your user information with the SessionID cookie that you included with your request. Please make a new request the Sick Dogs Tattoo Parlor information page again. Ms. Broswer: I hope this is the end of this goose chase, Mr. Forgetful! Please send me the information page on Sick Dogs Tattoo Parlor, please. Mr. Forgetful: Whoa! Oh nevermind, I see that it is just you, PaintedLady, based on the user information associated with your SessionID, and I see that you have sufficient rights for me to process your request. Here is the page you requested. Ms. Browser: Thank you, Mr. Forgetful. They have a picture of one of the tattoos on my back, and I am beginning to think that one was a mistake. I'm going to back up a bit here. Please do a search for tattoo removal service. Mr. Forgetful: Okay, here are the results for the tattoo removal service search, and based on the preferences I have associated with your SessionID, I have included 25 hits per page. Okay, it's kind of a silly dialog. But that is how the SessionID cookie works, and how it interplays with authentication. Note that the user information is not directly available in the HttpSession in most cases, but the server associates both with the SessionID behind the scenes, and your apps can access it through request.getUserPrinicpal() and request.getRemoteUser(), request.isUserInRole(), etc. The lifecycle of this authentication information is the same as that of the HttpSession, since the server uses the SessionID cookie to identify both pieces of information. Servers often use a combination of the IP address your requests come from and perhaps other information along with the SessionID cookie value to enhance security. The name of the 'SessionID' cookie here is simply an illustration -- the real name of the cookie depends on your server, but the usage is as described. -Max - To
Re: Association between Session object and Cookies/URL rewriting
2003. március 6. 12:10 dátummal Max Cooper ezt írtad: Here's a little dialog to illustrate: Wow! That was marvellous! Tib - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Association between Session object and Cookies/URL rewriting
Hi, It seems that there is no way to associate the session timeout information in the web.xml for the session created after the user logs in. Or is there ? Let me know if I am very wrong here but my login page also expires before the user is authenticated. The user perception is that the application is expiring even before he is authenticated. Mohan -Original Message- From: Gemes Tibor [mailto:[EMAIL PROTECTED] Sent: Thursday, March 06, 2003 5:18 PM To: Struts Users Mailing List Subject: Re: Association between Session object and Cookies/URL rewriting 2003. március 6. 12:10 dátummal Max Cooper ezt írtad: Here's a little dialog to illustrate: Wow! That was marvellous! Tib - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Association between Session object and Cookies/URL rewriting
It sounds like there is something else going on. The session timeout set in the web.xml file is the time required for the server to totally forget about you, whether you had authenticated yourself or not. It is the time since your last request that matters. If the timeout is set for 30 minutes, you can go to the site, click around for a few hours, and then if you wait more than 30 minutes before making another request, the server will drop your session. If you happened to have authenticated yourself, it will forget about that at the same time that it forgets about your HttpSession stuff. Some login pages and servers may drop your old session when you authenticate, but I know that Tomcat doesn't do that unless you explicitly have a session.invalidate() call in your login page. I tested this by having a simple app with container-managed authentication where you could edit the contents of your session with both an unprotected page and a protected page. If you put stuff in your session and then clicked a link to go to the protected page, you would be asked to login, and then you would arrive at the protected page to find that all the stuff you put in the session was still there. In the SecurityFilter project (a Filter-based mimic of container-managed authentication), we did have to handle one exception, and that is that your session will be dropped if you were previously authenticated in that same session. So, it won't drop the session on an unauthenticated - authenticated transition, but the session will be dropped on an authenticated - authenticated transition. We did this to be sure that any information that might have been stored in the session for the last user is not available to the new user as a security measure. I don't think that Tomcat has to account for this issue, since it won't ever send you to login if you have already authenticated yourself, and will give an error if you submit a login form without being sent there by Tomcat. I am not sure what they do with your old session in the case that you send a login request anyway, but you can't really design your app to work that way since it isn't supported in the first place. You might just get an error and remain logged in as the original user, or you might get an error and have your old session dropped (I am not sure if you would be logged in as the new user or not). In SecurityFilter, you are allowed to send a login request any time you want by design, so we had to handle that case. SecurityFilter project home page (shameless plug :P): http://securityfilter.sourceforge.net/ -Max - Original Message - From: Mohan Radhakrishnan [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Sent: Thursday, March 06, 2003 3:55 AM Subject: RE: Association between Session object and Cookies/URL rewriting Hi, It seems that there is no way to associate the session timeout information in the web.xml for the session created after the user logs in. Or is there ? Let me know if I am very wrong here but my login page also expires before the user is authenticated. The user perception is that the application is expiring even before he is authenticated. Mohan -Original Message- From: Gemes Tibor [mailto:[EMAIL PROTECTED] Sent: Thursday, March 06, 2003 5:18 PM To: Struts Users Mailing List Subject: Re: Association between Session object and Cookies/URL rewriting 2003. március 6. 12:10 dátummal Max Cooper ezt írtad: Here's a little dialog to illustrate: Wow! That was marvellous! Tib - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Association between Session object and Cookies/URL rewriting
So I will have to use
inValidateSession( request );
What will happen to code like this in by base action if I do this? That
would be lost.
protected void setLocale(
HttpServletRequest request,
Locale locale) {
HttpSession session = request.getSession(true);
session.setAttribute( Action.LOCALE_KEY,locale );
}
Mohan
-Original Message-
From: Max Cooper [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 06, 2003 6:18 PM
To: Struts Users Mailing List
Subject: Re: Association between Session object and Cookies/URL
rewriting
Some login pages and servers may drop your old session when you
authenticate, but I know that Tomcat doesn't do that unless you explicitly
have a session.invalidate() call in your login page.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Association between Session object and Cookies/URL rewriting
I am not sure what the goal is for your application. You only want to
call session.invalidate() if you want the server to forget about the
user (force a logout). What is it that you wish to achieve?
-Max
On Thu, 2003-03-06 at 05:50, Mohan Radhakrishnan wrote:
So I will have to use
inValidateSession( request );
What will happen to code like this in by base action if I do this? That
would be lost.
protected void setLocale(
HttpServletRequest request,
Locale locale) {
HttpSession session = request.getSession(true);
session.setAttribute( Action.LOCALE_KEY,locale );
}
Mohan
-Original Message-
From: Max Cooper [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 06, 2003 6:18 PM
To: Struts Users Mailing List
Subject: Re: Association between Session object and Cookies/URL
rewriting
Some login pages and servers may drop your old session when you
authenticate, but I know that Tomcat doesn't do that unless you explicitly
have a session.invalidate() call in your login page.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Association between Session object and Cookies/URL rewriting
Hi,
Actually it is the normal functionality. I was confused a bit.
I've done the following things.
1. I will call session.invalidate()
2. saveOnRestart=false to prevent writing of session.ser
Manager
className=org.apache.catalina.session.PersistentManager
debug=0
saveOnRestart=false
maxActiveSessions=-1
minIdleSwap=-1
maxIdleSwap=-1
maxIdleBackup=-1
Requirement is this : My login page itself expires even if the user
doesn't login for the session timeout period. We want to prevent that.
NO. 2 above is done to prevent tomcat from writing session.ser. I assume
there are no side-effects. The two might not be related. But I thought if
session info. is persisted across shutdowns and restarts I could see old
session data.
Mohan
-Original Message-
From: Max Cooper [mailto:[EMAIL PROTECTED]
Sent: Friday, March 07, 2003 12:18 AM
To: Struts Users Mailing List
Subject: RE: Association between Session object and Cookies/URL
rewriting
I am not sure what the goal is for your application. You only want to
call session.invalidate() if you want the server to forget about the
user (force a logout). What is it that you wish to achieve?
-Max
On Thu, 2003-03-06 at 05:50, Mohan Radhakrishnan wrote:
So I will have to use
inValidateSession( request );
What will happen to code like this in by base action if I do this?
That
would be lost.
protected void setLocale(
HttpServletRequest request,
Locale locale) {
HttpSession session = request.getSession(true);
session.setAttribute( Action.LOCALE_KEY,locale );
}
Mohan
-Original Message-
From: Max Cooper [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 06, 2003 6:18 PM
To: Struts Users Mailing List
Subject: Re: Association between Session object and Cookies/URL
rewriting
Some login pages and servers may drop your old session when you
authenticate, but I know that Tomcat doesn't do that unless you
explicitly
have a session.invalidate() call in your login page.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Association between Session object and Cookies/URL rewriting
Requirement is this : My login page itself expires even if the user doesn't login for the session timeout period. We want to prevent that. Hmm... I don't think there is much you can do in that case with container-managed security. If the user fails to login within the session expiration time, their session will expire. When the user then submits the login form, it will look like a spontaneous login to the server, which is not supported with container-managed security, and will cause an error (on Tomcat at least; WebLogic does something a little different, but I think the different behaviors just highlight the reason why depending on this setup is risky). The SecurityFilter project supports this kind of operation to some extent. The session will still expire, so the server will not be able to take the user directly to the protected page that caused the login form to appear. But SecurityFilter supports the configuration of a 'default page' to send the user to if they login without an active session, or simply submit a login form without being sent there by the filter. http://securityfilter.sourceforge.net/ -Max - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Association between Session object and Cookies/URL rewriting
Struts doesn't create coockies, J2EE servlet container does (tomcat). When you use request.getSession() in your code, J2EE server will a coockie (or a request parameter if URL rewriting is used, see your server config) to get the session ID. If no ID is set, it will generate a new session ID and add a set-coockie HTTP header in response. New request from user browser will come to the server with a SESSIONID coockie header, and request.getSession() implementation will be able to find the session object from ID. Read J2EE or Tomcat documentation to get more infos on sessions (sessionid coockie, URL rewriting ...). Nico. I don't understand very well how Struts manages session objects and why a sessionID is fixed for a user ? Session objects are stored on the web server (Tomcat in my case) and cookie saved on the disk allows to retrieve the HttpSession associated to a user. But I don't understand how the cookie is created and why is it associated to a client ? How Struts creates the session cookie ? I read that the cookie object is created when a user first loads a web page that is a part of the application. But at this stage what distinguishes a user X from a user Y ? In my application I distinguish two users with authentication information but when the first page is displayed the authentication is not done. How Struts know that it is a new user and that it has to create a new HtppSession and a new cookie? Is a user (and so a cookie) associated to a user NT account ? I am not certain to have been rather clear Thanks in advance for your help. Sandra --- As of February 12, 2003 Thomson unifies its email addresses on a worldwide basis.Please note my new email address: [EMAIL PROTECTED] Thomson is the leader in solutions and technologies for the entertainment and media industries and serves its customers under its four strategic brands: Technicolor, Grass Valley, RCA and THOMSON. More about Thomson: http://www.thomson.net/videochain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
