Re: [HttpSession creation: When How]

2004-11-30 Thread Carlos Cajina
Good morning.
Thanks a lot for the shared thoughts and ideas about HttpSession management. 
Last night I decided to give the Servlet Spec a second try and here's what I 
think is relevant to this topic:

- A session is considered new untils a client joins it [calls to 
HttpSession.isNew() return true]
- A client joins a session when session tracking info has been returned to 
the server, indicating that the session has been established.
- The container always (?) creates a session object for a given user request 
regardless of its nature (HTML, JSP...), but waits until the client sends 
tracking info back to consider the client as part of the new session

I'm yet to read RFC 2964 - Use of HTTP State Management, but from the Spec 
and your feedback I think a practical way to address this problem is whith 
the mecanism suggested by Dennis and Frank:
- If the session exists, check for required elements and place them there if 
they are missing / Check for some known object in session; if it's not 
there, the user hasn't been validated.

Besides being practical, this approach makes complete sense since -as Bob 
accurately points out: The basic HttpSession object is for state 
management, not evidence of  authentication.

Thanks again for sharing your knowledge. Should I trip over again in this 
matters I'd sure come back...  :^)

Regards,
Carlos
- Original Message - 
From: Bob Feretich [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Sent: Tuesday, November 30, 2004 12:25 AM
Subject: Re: [HttpSession creation: When  How]


When Tomcat intercepts an access to a protected resource and redirects to 
your login form, it saves your initial request by attaching it to the 
session object. If the login is successful, it retrieves the saved request 
and redirects to it. If you don't have an active session, it creates one 
to perform the save.

The basic HttpSession object is for state management, not evidence of 
authentication (see best practice RFC-2964 2.2.2). (You may attach 
authentication info to the session object.)

Regards,
Bob Feretich
Dennis Payne wrote:
You can use the session.invalidate() if you need to before creating a
new session (I did not use this approach).
With my system, if the session exists we check for required elements
and place them there if they are missing.  Every thirty minutes the
session automatically invalidates.  At that point we create a new
session and simply repeat the check for required elements.  All of this
is invisible to the user who logs in only once.  The only information
that stays from session to session is data that is persisted in (written
to) the database and put in the session for servlet/JSP use.
If I understand correctly the HTTP Session is initiated by the web
server when authentication takes place (I only have experience with
basic authentication).
Other wiser sources may clarify...

[EMAIL PROTECTED] 11-29-2004 17:31 

Good evening.
My question is about HttpSession objects creation and destruction
within a Servlet/JSP container. I'm using the JBoss/Tomcat bundle 
(versions 3.2.3/4.1.29) with a database realm properly configured. Here's 
how
things work so far:

1. User goes to a predefined Welcome File (index.html)
2. Within the welcome file there's a link to a protected resource (wich
happens to be the application's main screen)
3. The user clicks the link and the login page appears.
4. The user enters login/password and logs on successfully or is
redirected to an error page.
Up to this point everything works fine, but the thing that I don't 
understand is that the moment the user clicks the link that points to a

protected resource an HttpSession object is created by the server even
though the user hasn't been authenticated. This behavior kinda ruin my
plans because I have a Session Creation/Destruction Listener that is 
supposed
to detect a session creation event in order to be able to place some
things (objects) in that user session, but it seems that the created 
session
for the unauthenticated is recycled after authentication and my session 
lifecycle listener is no longer useful (the session already exists)

I've looked into the Servlet spec but couldn't find anything clarifying
enough... I'f anyone has any comments, tips, thoughts on this issue I'd
like to hear'em... :^)
Regards,
Carlos... -
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]


[HttpSession creation: When How]

2004-11-29 Thread Carlos Cajina
Good evening.
My question is about HttpSession objects creation and destruction within a 
Servlet/JSP container. I'm using the JBoss/Tomcat bundle (versions 
3.2.3/4.1.29) with a database realm properly configured. Here's how things 
work so far:

1. User goes to a predefined Welcome File (index.html)
2. Within the welcome file there's a link to a protected resource (wich 
happens to be the application's main screen)
3. The user clicks the link and the login page appears.
4. The user enters login/password and logs on successfully or is redirected 
to an error page.

Up to this point everything works fine, but the thing that I don't 
understand is that the moment the user clicks the link that points to a 
protected resource an HttpSession object is created by the server even 
though the user hasn't been authenticated. This behavior kinda ruin my plans 
because I have a Session Creation/Destruction Listener that is supposed to 
detect a session creation event in order to be able to place some things 
(objects) in that user session, but it seems that the created session for 
the unauthenticated is recycled after authentication and my session 
lifecycle listener is no longer useful (the session already exists)

I've looked into the Servlet spec but couldn't find anything clarifying 
enough... I'f anyone has any comments, tips, thoughts on this issue I'd like 
to hear'em... :^)

Regards,
Carlos... 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [HttpSession creation: When How]

2004-11-29 Thread Dennis Payne
You can use the session.invalidate() if you need to before creating a
new session (I did not use this approach).

With my system, if the session exists we check for required elements
and place them there if they are missing.  Every thirty minutes the
session automatically invalidates.  At that point we create a new
session and simply repeat the check for required elements.  All of this
is invisible to the user who logs in only once.  The only information
that stays from session to session is data that is persisted in (written
to) the database and put in the session for servlet/JSP use.

If I understand correctly the HTTP Session is initiated by the web
server when authentication takes place (I only have experience with
basic authentication).

Other wiser sources may clarify...

 [EMAIL PROTECTED] 11-29-2004 17:31 
Good evening.

My question is about HttpSession objects creation and destruction
within a 
Servlet/JSP container. I'm using the JBoss/Tomcat bundle (versions 
3.2.3/4.1.29) with a database realm properly configured. Here's how
things 
work so far:

1. User goes to a predefined Welcome File (index.html)
2. Within the welcome file there's a link to a protected resource (wich

happens to be the application's main screen)
3. The user clicks the link and the login page appears.
4. The user enters login/password and logs on successfully or is
redirected 
to an error page.

Up to this point everything works fine, but the thing that I don't 
understand is that the moment the user clicks the link that points to a

protected resource an HttpSession object is created by the server even

though the user hasn't been authenticated. This behavior kinda ruin my
plans 
because I have a Session Creation/Destruction Listener that is supposed
to 
detect a session creation event in order to be able to place some
things 
(objects) in that user session, but it seems that the created session
for 
the unauthenticated is recycled after authentication and my session 
lifecycle listener is no longer useful (the session already exists)

I've looked into the Servlet spec but couldn't find anything clarifying

enough... I'f anyone has any comments, tips, thoughts on this issue I'd
like 
to hear'em... :^)

Regards,

Carlos... 

-
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: [HttpSession creation: When How]

2004-11-29 Thread Frank W. Zammetti
Yes, the session is created automagically when a servlet-served resource 
is accessed (meaning things other than HTML, images, things like that). 
 JSPs and servlets in other words.  I seem to remember a config switch 
to turn this off, but that's how it generally works, and this is usually 
how other app servers work too AFAIK.

There are ways to deal with the, the way I generally do it is simply to 
check for some known object in session.  This object is only placed in 
session from my logon process.  So, if it's not there at any other time, 
the user hasn't been validated.  Cue whatever error/redirection logic 
you want at that point.  I think this is a fairly typical approach.

This confused the hell out of me for a while too... It's a bit 
counterintuitive, especially when there exists API functionality to 
create a session or use an existing one.  The logic there I suppose is 
that you may want to discard the automatically-created session in favor 
of your own during a logon process for instance, but I'm not sure I see 
the reason for doing that.

In any case, you aren't seeing anything unusual here, it's simply 
something you have to deal with one way or another (or find out the 
config switch to turn it off, if my memory is serving me correctly in 
saying it exists at all).

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Carlos Cajina wrote:
Good evening.
My question is about HttpSession objects creation and destruction within 
a Servlet/JSP container. I'm using the JBoss/Tomcat bundle (versions 
3.2.3/4.1.29) with a database realm properly configured. Here's how 
things work so far:

1. User goes to a predefined Welcome File (index.html)
2. Within the welcome file there's a link to a protected resource (wich 
happens to be the application's main screen)
3. The user clicks the link and the login page appears.
4. The user enters login/password and logs on successfully or is 
redirected to an error page.

Up to this point everything works fine, but the thing that I don't 
understand is that the moment the user clicks the link that points to a 
protected resource an HttpSession object is created by the server even 
though the user hasn't been authenticated. This behavior kinda ruin my 
plans because I have a Session Creation/Destruction Listener that is 
supposed to detect a session creation event in order to be able to place 
some things (objects) in that user session, but it seems that the 
created session for the unauthenticated is recycled after 
authentication and my session lifecycle listener is no longer useful 
(the session already exists)

I've looked into the Servlet spec but couldn't find anything clarifying 
enough... I'f anyone has any comments, tips, thoughts on this issue I'd 
like to hear'em... :^)

Regards,
Carlos...
-
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: [HttpSession creation: When How]

2004-11-29 Thread David Stevenson
You could put the following page directive on your login? .jsp page:

%@ page session=false %

David Stevenson

On Mon, 2004-11-29 at 20:35, Frank W. Zammetti wrote:
 Yes, the session is created automagically when a servlet-served resource 
 is accessed (meaning things other than HTML, images, things like that). 
   JSPs and servlets in other words.  I seem to remember a config switch 
 to turn this off, but that's how it generally works, and this is usually 
 how other app servers work too AFAIK.
 
 There are ways to deal with the, the way I generally do it is simply to 
 check for some known object in session.  This object is only placed in 
 session from my logon process.  So, if it's not there at any other time, 
 the user hasn't been validated.  Cue whatever error/redirection logic 
 you want at that point.  I think this is a fairly typical approach.
 
 This confused the hell out of me for a while too... It's a bit 
 counterintuitive, especially when there exists API functionality to 
 create a session or use an existing one.  The logic there I suppose is 
 that you may want to discard the automatically-created session in favor 
 of your own during a logon process for instance, but I'm not sure I see 
 the reason for doing that.
 
 In any case, you aren't seeing anything unusual here, it's simply 
 something you have to deal with one way or another (or find out the 
 config switch to turn it off, if my memory is serving me correctly in 
 saying it exists at all).


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [HttpSession creation: When How]

2004-11-29 Thread Bob Feretich
When Tomcat intercepts an access to a protected resource and redirects 
to your login form, it saves your initial request by attaching it to the 
session object. If the login is successful, it retrieves the saved 
request and redirects to it. If you don't have an active session, it 
creates one to perform the save.

The basic HttpSession object is for state management, not evidence of 
authentication (see best practice RFC-2964 2.2.2). (You may attach 
authentication info to the session object.)

Regards,
Bob Feretich
Dennis Payne wrote:
You can use the session.invalidate() if you need to before creating a
new session (I did not use this approach).
With my system, if the session exists we check for required elements
and place them there if they are missing.  Every thirty minutes the
session automatically invalidates.  At that point we create a new
session and simply repeat the check for required elements.  All of this
is invisible to the user who logs in only once.  The only information
that stays from session to session is data that is persisted in (written
to) the database and put in the session for servlet/JSP use.
If I understand correctly the HTTP Session is initiated by the web
server when authentication takes place (I only have experience with
basic authentication).
Other wiser sources may clarify...

[EMAIL PROTECTED] 11-29-2004 17:31 

Good evening.
My question is about HttpSession objects creation and destruction
within a 
Servlet/JSP container. I'm using the JBoss/Tomcat bundle (versions 
3.2.3/4.1.29) with a database realm properly configured. Here's how
things 
work so far:

1. User goes to a predefined Welcome File (index.html)
2. Within the welcome file there's a link to a protected resource (wich
happens to be the application's main screen)
3. The user clicks the link and the login page appears.
4. The user enters login/password and logs on successfully or is
redirected 
to an error page.

Up to this point everything works fine, but the thing that I don't 
understand is that the moment the user clicks the link that points to a

protected resource an HttpSession object is created by the server even
though the user hasn't been authenticated. This behavior kinda ruin my
plans 
because I have a Session Creation/Destruction Listener that is supposed
to 
detect a session creation event in order to be able to place some
things 
(objects) in that user session, but it seems that the created session
for 
the unauthenticated is recycled after authentication and my session 
lifecycle listener is no longer useful (the session already exists)

I've looked into the Servlet spec but couldn't find anything clarifying
enough... I'f anyone has any comments, tips, thoughts on this issue I'd
like 
to hear'em... :^)

Regards,
Carlos... 

-
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]