Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of p@pidster.com designates
 87.106.82.221 as permitted sender)
Received-SPF: neutral (s15243851.onlinehome-server.info: 78.86.122.68 is
 neither permitted nor denied by domain of pidster.com)
 client-ip=78.86.122.68; envelope-from=p@pidster.com; helo=Aerial.config;
Message-ID: <49707219.6070906@pidster.com>
Date: Fri, 16 Jan 2009 11:40:09 +0000
From: Pid <p@pidster.com>
Reply-To: p@pidster.com
Organization: Pid Inc
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Tomcat 6.x security-constraint redirection problem... please
 help!
References: <21448079.post@talk.nabble.com>
 <BLU142-W10F9CAC2C7241E5C05006EAED60@phx.gbl> <496DC6EA.5060007@pidster.com>
 <496F6E22.3010809@christopherschultz.net>
In-Reply-To: <496F6E22.3010809@christopherschultz.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Christopher Schultz wrote:
> Pid,
> 
> Pid wrote:
>> There's a couple of things that may be confusing the config below, which
>> have some simple corrections.
> 
>> I usually place "login.jsp" and "error.jsp" in "WEB-INF/login/", where
>> they are protected from unwanted attention by default - this avoids the
>> need to protect them with a security-contstraint.
> 
> Agreed. I've found that when using Tomcat to serve static content, these
> things tend to happen. The reason is that Tomcat saves the first
> unauthorized request and then repeats it after successful
> authentication. If the last request was for something like a CSS file
> (say, because the CSS file was protected, but the main page wasn't),
> then you'll end up being served the CSS file after login. It can be very
> disorienting.
> 
>> Tomcat returns the *first* file you requested inside the secured area
>> after authentication is completed.  So for some reason your browser is
>> requesting a script or CSS file before the JSP page.
> 
> For some reason, I thought it was the most recent request it saved.
> First makes more sense; thanks for mentioning it.

I have an app with a page which contains a flash object (displays a nice
graph) that calls a groovy script periodically to get data.

If the user session times out in between requests for the script then
when it's requested it's the first one after de-auth, so it becomes the
target that is re-established after re-login, (obviously not useful for
users).

I've been attempting to stop the periodic request by monitoring the
session period, but haven't had time to properly address it yet. :(

p


> -chris
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org