You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Kris Easter <kr...@colorado.edu> on 2012/07/30 22:24:08 UTC
Form Authentication question
I'm looking at the org.apache.catalina.authenticator.FormAuthenticator
class from the 7.0.29 src. This portion of the authenticate method
starting around line 301 is where I'm having a little problem:
if (log.isDebugEnabled()) {
log.debug("Authentication of '" + username + "' was successful");
}
if (session == null) {
session = request.getSessionInternal(false);
}
if (session == null) {
if (containerLog.isDebugEnabled()) {
containerLog.debug
("User took so long to log on the session expired");
}
if (landingPage == null) {
response.sendError(HttpServletResponse.SC_REQUEST_TIMEOUT,
sm.getString("authenticator.sessionExpired"));
} else {
// Make the authenticator think the user originally requested
// the landing page
String uri = request.getContextPath() + landingPage;
SavedRequest saved = new SavedRequest();
saved.setMethod("GET");
saved.setRequestURI(uri);
request.getSessionInternal(true).setNote(
Constants.FORM_REQUEST_NOTE, saved);
response.sendRedirect(response.encodeRedirectURL(uri));
}
return (false);
}
If the user sits too long on the login page the session times out, even
if their credentials were authenticated successfully, and sends them
back to the login page where they must re-enter their credentials. It
works this way even if I define a landingPage. Without a landingPage I
get the dreaded 408 error.
Can anyone enlighten me as to why it's a bad idea if:
if (session == null) {
session = request.getSessionInternal(false);
}
is instead:
if (session == null) {
session = request.getSessionInternal(true);
}
Thanks,
Kris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Best practice for redeployments
Posted by ll...@oreillyauto.com.
Pid,
My apologies, I did not realize that I was hijacking.
With how my mail client works I had thought I was starting a new thread.
Lee Lowder
From: Pid <pi...@pidster.com>
To: Tomcat Users List <us...@tomcat.apache.org>
Date: 07/31/2012 07:20 AM
Subject: Re: Best practice for redeployments
On 30/07/2012 22:57, llowder@oreillyauto.com wrote:
> All,
>
> I have 70-80 apps that are spread out across 3 different clusters (based
> on usage, availability needs etc)
>
> Currently, each night we wipe out the wars and then redeploy them with
> fresh copies from the end points of our promotion paths (one for test and
> one for prod).
>
> What's the general consensus for the best practice for this?
>
> Do people generally only redeploy whatever has changed?
>
> Are nightly tomcat restarts even needed (or recommended), or should we
> just hot-deploy things at fixed times (based on traffic patterns) but
only
> if something is needing to be updated?
>
> Any recommendations or thoughts or suggestions would be greatly
> appreciated. I'm sure there is some room for improvement in how we do
> things, but I was wondering what was considered a "standard practice" in
> this area.
>
> Lee Lowder
In future please start a completely new email, rather than replying to
an existing email* just editing the subject/body (which is call thread
hijacking).
p
* Re: Best practice for redeployments
--
[key:62590808]
[attachment "signature.asc" deleted by Lee Lowder/OReilly]
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Best practice for redeployments
Posted by Pid <pi...@pidster.com>.
On 30/07/2012 22:57, llowder@oreillyauto.com wrote:
> All,
>
> I have 70-80 apps that are spread out across 3 different clusters (based
> on usage, availability needs etc)
>
> Currently, each night we wipe out the wars and then redeploy them with
> fresh copies from the end points of our promotion paths (one for test and
> one for prod).
>
> What's the general consensus for the best practice for this?
>
> Do people generally only redeploy whatever has changed?
>
> Are nightly tomcat restarts even needed (or recommended), or should we
> just hot-deploy things at fixed times (based on traffic patterns) but only
> if something is needing to be updated?
>
> Any recommendations or thoughts or suggestions would be greatly
> appreciated. I'm sure there is some room for improvement in how we do
> things, but I was wondering what was considered a "standard practice" in
> this area.
>
> Lee Lowder
In future please start a completely new email, rather than replying to
an existing email* just editing the subject/body (which is call thread
hijacking).
p
* Re: Best practice for redeployments
--
[key:62590808]
Re: Best practice for redeployments
Posted by David kerber <dc...@verizon.net>.
On 7/30/2012 8:32 PM, Hassan Schroeder wrote:
> On Mon, Jul 30, 2012 at 2:57 PM,<ll...@oreillyauto.com> wrote:
>
>> Currently, each night we wipe out the wars and then redeploy them with
>> fresh copies ...
>
> ?!
>
>> What's the general consensus for the best practice for this?
>
> Uh, "don't" ?
+1
>
>> Are nightly tomcat restarts even needed ...
>
> I have legacy apps that run for months, and then only get "restarted"
> when Tomcat itself is upgraded.
Yup. Or when OS updates are applied and require a reboot.
>
>> Any recommendations or thoughts or suggestions would be greatly
>> appreciated. I'm sure there is some room for improvement in how we do
>> things, but I was wondering what was considered a "standard practice" in
>> this area.
>
> Also, I only mount the spare tire on my car when one of the other four
> is flat. Irresponsible slacker, I know, but ...
>
> FWIW, YMMV, etc.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Best practice for redeployments
Posted by Hassan Schroeder <ha...@gmail.com>.
On Mon, Jul 30, 2012 at 2:57 PM, <ll...@oreillyauto.com> wrote:
> Currently, each night we wipe out the wars and then redeploy them with
> fresh copies ...
?!
> What's the general consensus for the best practice for this?
Uh, "don't" ?
> Are nightly tomcat restarts even needed ...
I have legacy apps that run for months, and then only get "restarted"
when Tomcat itself is upgraded.
> Any recommendations or thoughts or suggestions would be greatly
> appreciated. I'm sure there is some room for improvement in how we do
> things, but I was wondering what was considered a "standard practice" in
> this area.
Also, I only mount the spare tire on my car when one of the other four
is flat. Irresponsible slacker, I know, but ...
FWIW, YMMV, etc.
--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
http://about.me/hassanschroeder
twitter: @hassan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Best practice for redeployments
Posted by ll...@oreillyauto.com.
All,
I have 70-80 apps that are spread out across 3 different clusters (based
on usage, availability needs etc)
Currently, each night we wipe out the wars and then redeploy them with
fresh copies from the end points of our promotion paths (one for test and
one for prod).
What's the general consensus for the best practice for this?
Do people generally only redeploy whatever has changed?
Are nightly tomcat restarts even needed (or recommended), or should we
just hot-deploy things at fixed times (based on traffic patterns) but only
if something is needing to be updated?
Any recommendations or thoughts or suggestions would be greatly
appreciated. I'm sure there is some room for improvement in how we do
things, but I was wondering what was considered a "standard practice" in
this area.
Lee Lowder
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Form Authentication question
Posted by Kris Easter <kr...@colorado.edu>.
On Mon, 2012-07-30 at 14:36 -0600, Mark Thomas wrote:
> On 30/07/2012 21:24, Kris Easter wrote:
> >
> ...
> >
> > If the user sits too long on the login page the session times out, even
> > if their credentials were authenticated successfully, and sends them
> > back to the login page where they must re-enter their credentials. It
> > works this way even if I define a landingPage. Without a landingPage I
> > get the dreaded 408 error.
> >
> > Can anyone enlighten me as to why it's a bad idea if:
> >
> > if (session == null) {
> > session = request.getSessionInternal(false);
> > }
> >
> > is instead:
> >
> > if (session == null) {
> > session = request.getSessionInternal(true);
> > }
>
> Because the session defines where to go after the authentication i.e.
> which page the user requested originally. I suppose we could allow the
> user to transition to the landing page in that case.
>
> Mark
That would be preferable for my use case.
Kris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Form Authentication question
Posted by Mark Thomas <ma...@apache.org>.
On 30/07/2012 21:24, Kris Easter wrote:
>
> I'm looking at the org.apache.catalina.authenticator.FormAuthenticator
> class from the 7.0.29 src. This portion of the authenticate method
> starting around line 301 is where I'm having a little problem:
>
>
> if (log.isDebugEnabled()) {
> log.debug("Authentication of '" + username + "' was successful");
> }
>
> if (session == null) {
> session = request.getSessionInternal(false);
> }
>
> if (session == null) {
> if (containerLog.isDebugEnabled()) {
> containerLog.debug
> ("User took so long to log on the session expired");
> }
>
> if (landingPage == null) {
>
> response.sendError(HttpServletResponse.SC_REQUEST_TIMEOUT,
> sm.getString("authenticator.sessionExpired"));
> } else {
> // Make the authenticator think the user originally requested
> // the landing page
> String uri = request.getContextPath() + landingPage;
> SavedRequest saved = new SavedRequest();
> saved.setMethod("GET");
> saved.setRequestURI(uri);
> request.getSessionInternal(true).setNote(
> Constants.FORM_REQUEST_NOTE, saved);
> response.sendRedirect(response.encodeRedirectURL(uri));
> }
> return (false);
> }
>
>
> If the user sits too long on the login page the session times out, even
> if their credentials were authenticated successfully, and sends them
> back to the login page where they must re-enter their credentials. It
> works this way even if I define a landingPage. Without a landingPage I
> get the dreaded 408 error.
>
> Can anyone enlighten me as to why it's a bad idea if:
>
> if (session == null) {
> session = request.getSessionInternal(false);
> }
>
> is instead:
>
> if (session == null) {
> session = request.getSessionInternal(true);
> }
Because the session defines where to go after the authentication i.e.
which page the user requested originally. I suppose we could allow the
user to transition to the landing page in that case.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org