JDBC Realm by-passing login page using a link
Is it possible to pass login info in a link and then based on this information set the JDBC realm status to logged in? In other words is it possible to trigger the authentication manually in a filter? Thanks! /Fredrik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JDBC Realm by-passing login page using a link
It is my understanding that the JDBC realm will execute prior to any filters or other servlets, so I wouldn't think this would be possible unless you perform your own authentication - possibly in a filter - to do just what you're looking for. -Original Message- From: Fredrik Liden [mailto:[EMAIL PROTECTED] Sent: Thursday, March 10, 2005 1:40 PM To: Tomcat Users List Subject: JDBC Realm by-passing login page using a link Is it possible to pass login info in a link and then based on this information set the JDBC realm status to logged in? In other words is it possible to trigger the authentication manually in a filter? Thanks! /Fredrik - 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]
Direct access to form-login-page, and to j_security_check
Going to try to ask this a different way... Is it possible to directly submit information to j_security_check and/or to directly access form-login-page, rather than posting form-login-page and authenticating with j_security_check only in response to an attempted access of a protected page? I've found quite a few forum threads from 2003 discussing this issue and posting various hackish workarounds, but am wondering if Tomcat 5.5 might have provided a direct solution. I am already achieving a partial solution by linking to a protected page that serves only to redirect back to index.jsp to show a personalized view (after authentication). However, I would like a cleaner and more complete solution (e.g., supporting users who bookmark the login page). Most importantly I would like to embed my login form directly on index.jsp (and every other page of the site) so the user can directly login rather than being forced to click a link to get a login page and then log in. Is there a way to do this? Thanks for any help, Chuck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
bypassing login page
I have a servlet that requires an HTTPS connection and normally forces a browser to log in using a jsp page. I would like to use the same servlet to allow a program to submit a request and retrieve the response without having to navigate through the login page. Is there a way to do this? I am using the WinINet (yuck) API on the client and setting the user ID and password on the connection call. Robert S. Harper Senior Engineer 1100 East 6600 South, Suite 300 Salt Lake City, UT 84121-7411 801.265.8800 ex. 255
Unexpected error forwarding to login page
Anyone? No responses from last week..
Has anyone see this error message before?
Is this the correct Mailing list to post this on?
I am trying to use FORM based authentication but I am getting an error in
the tomcat console.
When I try to goto my web page
(http://localhost:8080/E3/common/CustomerInq/index.faces) I get a blank
screen.
However, if after getting the blank screen I goto the login page
(http://localhost:8080/E3/login2.jsp) and type in a correct login page then
I will get redirected to the CustomerInq/index.faces page correctly.
Tomcat console error:
Jun 25, 2004 2:51:46 PM org.apache.catalina.authenticator.FormAuthenticator
authenticate
WARNING: Unexpected error forwarding to login page
java.lang.NullPointerException
at
org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthent
icator.java:214)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase
.java:504)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137
)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:104)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117
)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:109)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:793)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
ction(Http11Protocol.java:702)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:571)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:644)
at java.lang.Thread.run(Thread.java:534)
This is a snippit of my web.xml...
code:
!-- Faces Servlet Mapping --
servlet-mapping
servlet-nameFaces Servlet/servlet-name
url-pattern*.faces/url-pattern
/servlet-mapping
security-constraint
web-resource-collection
web-resource-nameresticted/web-resource-name
url-pattern/common/*/url-pattern
/web-resource-collection
auth-constraint
role-nameuser/role-name
/auth-constraint
/security-constraint
login-config
auth-methodFORM/auth-method
form-login-page/login.faces/form-login-page
form-error-page/loginerror.jsp/form-error-page
/login-config
security-role
role-nameuser/role-name
/security-role
/web-app
and here is the login from the Orielly JSF book that I am trying to use as a
starting point...
code:
html
head
titleLogin/title
link rel=stylesheet type=text/css
href=${pageContext.request.contextPath}/style.css
/head
body bgcolor=white
div class=titlePlease Login/div
p
The page you requested is only available to registered users.
Please enter your username and password and click Login.
/p
form action=j_security_check method=post
table class=tablebg
tr
td align=rightUsername:/td
tdinput name=j_username/td
/tr
tr
td align=rightPassword:/td
td
input type=password name=j_password
/td
/tr
/table
input type=submit value=Login
/form
/body
/html
Any ideas are will be greatly appreciated.
-David
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
WARNING: Unexpected error forwarding to login page
Is this the correct Mailing list to post this on?
I am trying to use FORM based authentication but I am getting this error in
the tomcat console...
code:
_
Jun 25, 2004 2:51:46 PM org.apache.catalina.authenticator.FormAuthenticator
authenticate
WARNING: Unexpected error forwarding to login page
java.lang.NullPointerException
at
org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthent
icator.java:214)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase
.java:504)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137
)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:104)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117
)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:109)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:793)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
ction(Http11Protocol.java:702)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:571)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:644)
at java.lang.Thread.run(Thread.java:534)
_
When I try to goto my web page
(http://localhost:8080/E3/common/CustomerInq/index.faces) I get a blank
screen.
However, if after getting the blank screen I goto the login page
(http://localhost:8080/E3/login2.jsp) and type in a correct login page then
I will get redirected to the CustomerInq/index.faces page correctly.
This is a snippit of my web.xml...
code:
_
!-- Faces Servlet Mapping --
servlet-mapping
servlet-nameFaces Servlet/servlet-name
url-pattern*.faces/url-pattern
/servlet-mapping
security-constraint
web-resource-collection
web-resource-nameresticted/web-resource-name
url-pattern/common/*/url-pattern
/web-resource-collection
auth-constraint
role-nameuser/role-name
/auth-constraint
/security-constraint
login-config
auth-methodFORM/auth-method
form-login-page/login2.jsp/form-login-page
form-error-page/loginerror.jsp/form-error-page
/login-config
security-role
role-nameuser/role-name
/security-role
/web-app
_
and here is the login from the Orielly JSF book that I am trying to use as a
starting point...
code:
_
html
head
titleLogin/title
link rel=stylesheet type=text/css
href=${pageContext.request.contextPath}/style.css
/head
body bgcolor=white
div class=titlePlease Login/div
p
The page you requested is only available to registered users.
Please enter your username and password and click Login.
/p
form action=j_security_check method=post
table class=tablebg
tr
td align=rightUsername:/td
tdinput name=j_username/td
/tr
tr
td align=rightPassword:/td
td
input type=password name=j_password
/td
/tr
FW: WARNING: Unexpected error forwarding to login page
Sorry for the repost.. Formatting got messed up.
Is this the correct Mailing list to post this on?
I am trying to use FORM based authentication but I am getting this error in
the tomcat console...
code:
Jun 25, 2004 2:51:46 PM org.apache.catalina.authenticator.FormAuthenticator
authenticate
WARNING: Unexpected error forwarding to login page
java.lang.NullPointerException
at
org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthent
icator.java:214)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase
.java:504)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137
)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:104)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117
)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:109)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:793)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
ction(Http11Protocol.java:702)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:571)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:644)
at java.lang.Thread.run(Thread.java:534)
When I try to goto my web page
(http://localhost:8080/E3/common/CustomerInq/index.faces) I get a blank
screen.
However, if after getting the blank screen I goto the login page
(http://localhost:8080/E3/login2.jsp) and type in a correct login page then
I will get redirected to the CustomerInq/index.faces page correctly.
This is a snippit of my web.xml...
code:
!-- Faces Servlet Mapping --
servlet-mapping
servlet-nameFaces Servlet/servlet-name
url-pattern*.faces/url-pattern
/servlet-mapping
security-constraint
web-resource-collection
web-resource-nameresticted/web-resource-name
url-pattern/common/*/url-pattern
/web-resource-collection
auth-constraint
role-nameuser/role-name
/auth-constraint
/security-constraint
login-config
auth-methodFORM/auth-method
form-login-page/login2.jsp/form-login-page
form-error-page/loginerror.jsp/form-error-page
/login-config
security-role
role-nameuser/role-name
/security-role
/web-app
and here is the login from the Orielly JSF book that I am trying to use as a
starting point...
code:
html
head
titleLogin/title
link rel=stylesheet type=text/css
href=${pageContext.request.contextPath}/style.css
/head
body bgcolor=white
div class=titlePlease Login/div
p
The page you requested is only available to registered users.
Please enter your username and password and click Login.
/p
form action=j_security_check method=post
table class=tablebg
tr
td align=rightUsername:/td
tdinput name=j_username/td
/tr
tr
td align=rightPassword:/td
td
input type=password name=j_password
/td
/tr
/table
input type=submit value=Login
/form
/body
/html
Any ideas are will be greatly appreciated.
-David
David Wilson
[EMAIL PROTECTED]
Staff Developer
Relevant Business Systems
(Fax) 678-868-1773
Please send complaints to /dev/null
Re: Session Timeout and Direct Reference to login page
Jonathan Eric Miller wrote: The strange thing is that this page seems to only intermittently be displayed. i.e. it is catching the case where the session expires, but, in some cases since I'm using container based security, it is going back to the login page. Sometimes it goes to this page first, and then brings up the login page. Other times, it just goes straight to the login page. I need to look into it further. I have SingleSignOn enabled, so, I'm not sure if that May be it's working so fast you sometimes don't notice this redirection, and sometimes do? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Timeout and Direct Reference to login page
I found out about a few other functions that make it bit easier. I think I
have it working using the following,
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
if(((HttpServletRequest)request).getRequestedSessionId() != null
((HttpServletRequest)request).isRequestedSessionIdValid() == false) {
RequestDispatcher rd =
request.getRequestDispatcher(/WEB-INF/sessionexpired.jsp);
rd.forward(request, response);
}
else {
chain.doFilter(request, response);
}
}
The strange thing is that this page seems to only intermittently be
displayed. i.e. it is catching the case where the session expires, but, in
some cases since I'm using container based security, it is going back to the
login page. Sometimes it goes to this page first, and then brings up the
login page. Other times, it just goes straight to the login page. I need to
look into it further. I have SingleSignOn enabled, so, I'm not sure if that
might have something to do with it. I need to do more testing. In theory, I
think it should go to the login page each time. So, I'm thinking of putting
a check in my login page similar to the above that just shows optional text
stating that the session has expired.
Another thing that I'm wondering is if it is possible to use a servlet as
the login page for Tomcat rather than a .jsp file.
Jon
- Original Message -
From: Veniamin Fichin [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Sent: Friday, May 21, 2004 7:15 AM
Subject: Re: Session Timeout and Direct Reference to login page
Jonathan Eric Miller wrote:
Yeah, that seems like it would work. I'm wondering if I could maybe use
a
filter by itself though and not use the listener and do something like
the
following.
1. Intercept all requests with a filter.
2. Get the HttpSession out of the request. Get the session ID by calling
HttpSession.getId();
3. Get the cookie array and see if there is a cookie named jsessionid.
If
there is, compare the two session IDs. If they are different forward to
sessionexpired.jsp to display error page. Otherwise, continue as normal.
I've just tried this way, it works. Look at example .java file in
attach for example, it's Filter implementation. Thanks for the
suggestion, it's very useful.
-
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: Session Timeout and Direct Reference to login page
Jonathan Eric Miller wrote:
Yeah, that seems like it would work. I'm wondering if I could maybe use a
filter by itself though and not use the listener and do something like the
following.
1. Intercept all requests with a filter.
2. Get the HttpSession out of the request. Get the session ID by calling
HttpSession.getId();
3. Get the cookie array and see if there is a cookie named jsessionid. If
there is, compare the two session IDs. If they are different forward to
sessionexpired.jsp to display error page. Otherwise, continue as normal.
I've just tried this way, it works. Look at example .java file in
attach for example, it's Filter implementation. Thanks for the
suggestion, it's very useful.
package org.unchqua.test.servlet;
import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletOutputStream;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.Cookie;
public class NewSessionFilter implements Filter {
private FilterConfig fconf;
public void init(FilterConfig arg0) throws ServletException {
fconf=arg0;
}
public void doFilter(ServletRequest req, ServletResponse resp,
FilterChain fchain) throws IOException, ServletException {
boolean newManualSession=false;
String fromSession=null;
if (((HttpServletRequest)req).getSession(false)!=null) {
fromSession=((HttpServletRequest)req).getSession(false).getId();
}
if (fromSession==null) {
fromSession=((HttpServletRequest)req).getSession().getId();
newManualSession=true;
}
String fromCookie=null;
Cookie[] cooks=((HttpServletRequest)req).getCookies();
if (cooks!=null) {
for (int i=0; icooks.length; i++) {
if (cooks[i].getName().equals(JSESSIONID)) {
fromCookie=cooks[i].getValue();
break;
}
}
}
ServletOutputStream out=resp.getOutputStream();
out.println(newManualSession ? Session manually created : );
out.println(fromSession!=null ? From session: +fromSession : No session);
out.println(fromCookie!=null ? From cookies: +fromCookie : No session id in
cookies);
if (fromSession==null fromCookie==null)
out.println(Session is completely new);
else if (fromSession==null fromCookie!=null)
out.println(Session lived but has been expired);
//fchain.doFilter(req, resp);
}
public void destroy() {
fconf=null;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Timeout and Direct Reference to login page
Jonathan Eric Miller wrote: Thanks. I think option #1 is what I'm looking for. What I don't understand is what I need to do with the session listener though? I don't understand how to determine whether the new session is truly new, or if it's a new session because a previous session timed out. Could I use a filter and check the incoming session ID and if the session ID isn't in the list of session IDs that the server knows about, assume that it's an expired session? Yes, this may be the right solution. Store a hash in a singleton class and fill it with session ids that has expired (add a new hash pair in every invocation of sessionDestroyed()). And at every request check that: 0) HttpSession.isNew()==true . 1) HttpServletRequest.getCookies() array contains an entry that matches one of your hash pairs. That way you may determine if that session is truly new or an expired one. It's just a guess. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Timeout and Direct Reference to login page
In my case, I don't just want to test for a timed out session. I want to see
if the session has timed out since the user has logged in.
So, when the user logs in, I add an object to the session (any object will
do). Then at the top of every servlet I test for the existence of that
object 'if(session.getAttribute(myObject) == null)'. If the object is null
then I know that the session has timed out since the user last logged in.
At that point, I forward to the session expired page which informs the user
that he/she must log back in.
It sounds like you're looking for something similar.
On Wednesday 19 May 2004 04:56 pm, Jonathan Eric Miller wrote:
Thanks. I think option #1 is what I'm looking for. What I don't understand
is what I need to do with the session listener though?
I don't understand how to determine whether the new session is truly new,
or if it's a new session because a previous session timed out. Could I use
a filter and check the incoming session ID and if the session ID isn't in
the list of session IDs that the server knows about, assume that it's an
expired session?
Does anyone have example source code on how to do this?
Jon
- Original Message -
From: QM [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Sent: Wednesday, May 19, 2004 3:16 PM
Subject: Re: Session Timeout and Direct Reference to login page
On Wed, May 19, 2004 at 02:58:05PM -0500, Jonathan Eric Miller wrote:
: All I want to do is detect when a session has timed out for a user and
: display a page stating such when the user makes a request after the
session
: has timed out. It seems like this should be a straight forward thing to
do.
: Am I missing something?
You could use a session listener and check its existence with a
filter... In other words:
// filter pseudocode
if( null != session.getAttribute( UserMarker ) ){
// pass the req and resp down the filter chain
}else{
// forward() to a your session timed out page
}
Is this what you're after?
Option #2: have each page meta-refresh to the your session timed out
page (set the refresh value 1 or 2 seconds beyond the session timeout).
This is more intrusive, though: people don't typically like it when
their browser starts moving around when they didn't explicitly ask.
-QM
--
software -- http://www.brandxdev.net
tech news -- http://www.RoarNetworX.com
-
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]
--
Ben Souther
F.W. Davison Company, Inc.
This e-mail message, and any accompanying documents, is for the sole use of
the intended recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure, distribution or
copying is prohibited. If you are not the intended recipient, please
contact our office by email or by telephone at (508) 747-7261 and
immediately destroy all copies of the original message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Timeout and Direct Reference to login page
Yeah, that seems like it would work. I'm wondering if I could maybe use a filter by itself though and not use the listener and do something like the following. 1. Intercept all requests with a filter. 2. Get the HttpSession out of the request. Get the session ID by calling HttpSession.getId(); 3. Get the cookie array and see if there is a cookie named jsessionid. If there is, compare the two session IDs. If they are different forward to sessionexpired.jsp to display error page. Otherwise, continue as normal. This assumes that the session ID changes everytime it expires. As far as I know, that is the case. I would also have to figure out how to get the jsessionid if it is in the URL rather than in a cookie. I would prefer to do it that way if I can for the sake of simplicity. I want to avoid having a Hashtable that grows indefinitely if possible. Does it seem like this work, or, am I missing something? I'm wondering if this wouldn't work if I didn't have single sign-on enabled. i.e. the login page would get displayed at session expiration. I'm not sure if the login page does only forwards, or if it does a redirect. I'm thinking the redirect might make the above logic not work since the session ID in the cookie would get updated first by the login page. Note, the filter runs after the login page. It seems like there should be a generic way to handle this kind of thing that is well understood and known to work. Jon - Original Message - From: Veniamin Fichin [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Thursday, May 20, 2004 2:59 AM Subject: Re: Session Timeout and Direct Reference to login page Jonathan Eric Miller wrote: Thanks. I think option #1 is what I'm looking for. What I don't understand is what I need to do with the session listener though? I don't understand how to determine whether the new session is truly new, or if it's a new session because a previous session timed out. Could I use a filter and check the incoming session ID and if the session ID isn't in the list of session IDs that the server knows about, assume that it's an expired session? Yes, this may be the right solution. Store a hash in a singleton class and fill it with session ids that has expired (add a new hash pair in every invocation of sessionDestroyed()). And at every request check that: 0) HttpSession.isNew()==true . 1) HttpServletRequest.getCookies() array contains an entry that matches one of your hash pairs. That way you may determine if that session is truly new or an expired one. It's just a guess. - 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: Session Timeout and Direct Reference to login page
What was wrong with the first suggestion? 1.) When your user logs in, throw an object in their session. 2.) In each servlet/jsp (or, better, in a filter), test for the existence of that object and forward back to the login if it is null. Seems pretty straight forward to me. On Thursday 20 May 2004 12:51 pm, Jonathan Eric Miller wrote: Yeah, that seems like it would work. I'm wondering if I could maybe use a filter by itself though and not use the listener and do something like the following. 1. Intercept all requests with a filter. 2. Get the HttpSession out of the request. Get the session ID by calling HttpSession.getId(); 3. Get the cookie array and see if there is a cookie named jsessionid. If there is, compare the two session IDs. If they are different forward to sessionexpired.jsp to display error page. Otherwise, continue as normal. This assumes that the session ID changes everytime it expires. As far as I know, that is the case. I would also have to figure out how to get the jsessionid if it is in the URL rather than in a cookie. I would prefer to do it that way if I can for the sake of simplicity. I want to avoid having a Hashtable that grows indefinitely if possible. Does it seem like this work, or, am I missing something? I'm wondering if this wouldn't work if I didn't have single sign-on enabled. i.e. the login page would get displayed at session expiration. I'm not sure if the login page does only forwards, or if it does a redirect. I'm thinking the redirect might make the above logic not work since the session ID in the cookie would get updated first by the login page. Note, the filter runs after the login page. It seems like there should be a generic way to handle this kind of thing that is well understood and known to work. Jon - Original Message - From: Veniamin Fichin [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Thursday, May 20, 2004 2:59 AM Subject: Re: Session Timeout and Direct Reference to login page Jonathan Eric Miller wrote: Thanks. I think option #1 is what I'm looking for. What I don't understand is what I need to do with the session listener though? I don't understand how to determine whether the new session is truly new, or if it's a new session because a previous session timed out. Could I use a filter and check the incoming session ID and if the session ID isn't in the list of session IDs that the server knows about, assume that it's an expired session? Yes, this may be the right solution. Store a hash in a singleton class and fill it with session ids that has expired (add a new hash pair in every invocation of sessionDestroyed()). And at every request check that: 0) HttpSession.isNew()==true . 1) HttpServletRequest.getCookies() array contains an entry that matches one of your hash pairs. That way you may determine if that session is truly new or an expired one. It's just a guess. - 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] -- Ben Souther F.W. Davison Company, Inc. This e-mail message, and any accompanying documents, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or copying is prohibited. If you are not the intended recipient, please contact our office by email or by telephone at (508) 747-7261 and immediately destroy all copies of the original message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Timeout and Direct Reference to login page
Thanks for the suggestion. The reason that I can't do it that way (as far as I know) is because I'm using container-based security. I'm not handling the submission of the login form directly. Before I switched to using container-based security, I was doing it exactly as you described. Jon - Original Message - From: Ben Souther [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Thursday, May 20, 2004 12:26 PM Subject: Re: Session Timeout and Direct Reference to login page What was wrong with the first suggestion? 1.) When your user logs in, throw an object in their session. 2.) In each servlet/jsp (or, better, in a filter), test for the existence of that object and forward back to the login if it is null. Seems pretty straight forward to me. On Thursday 20 May 2004 12:51 pm, Jonathan Eric Miller wrote: Yeah, that seems like it would work. I'm wondering if I could maybe use a filter by itself though and not use the listener and do something like the following. 1. Intercept all requests with a filter. 2. Get the HttpSession out of the request. Get the session ID by calling HttpSession.getId(); 3. Get the cookie array and see if there is a cookie named jsessionid. If there is, compare the two session IDs. If they are different forward to sessionexpired.jsp to display error page. Otherwise, continue as normal. This assumes that the session ID changes everytime it expires. As far as I know, that is the case. I would also have to figure out how to get the jsessionid if it is in the URL rather than in a cookie. I would prefer to do it that way if I can for the sake of simplicity. I want to avoid having a Hashtable that grows indefinitely if possible. Does it seem like this work, or, am I missing something? I'm wondering if this wouldn't work if I didn't have single sign-on enabled. i.e. the login page would get displayed at session expiration. I'm not sure if the login page does only forwards, or if it does a redirect. I'm thinking the redirect might make the above logic not work since the session ID in the cookie would get updated first by the login page. Note, the filter runs after the login page. It seems like there should be a generic way to handle this kind of thing that is well understood and known to work. Jon - Original Message - From: Veniamin Fichin [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Thursday, May 20, 2004 2:59 AM Subject: Re: Session Timeout and Direct Reference to login page Jonathan Eric Miller wrote: Thanks. I think option #1 is what I'm looking for. What I don't understand is what I need to do with the session listener though? I don't understand how to determine whether the new session is truly new, or if it's a new session because a previous session timed out. Could I use a filter and check the incoming session ID and if the session ID isn't in the list of session IDs that the server knows about, assume that it's an expired session? Yes, this may be the right solution. Store a hash in a singleton class and fill it with session ids that has expired (add a new hash pair in every invocation of sessionDestroyed()). And at every request check that: 0) HttpSession.isNew()==true . 1) HttpServletRequest.getCookies() array contains an entry that matches one of your hash pairs. That way you may determine if that session is truly new or an expired one. It's just a guess. - 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] -- Ben Souther F.W. Davison Company, Inc. This e-mail message, and any accompanying documents, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or copying is prohibited. If you are not the intended recipient, please contact our office by email or by telephone at (508) 747-7261 and immediately destroy all copies of the original message. - 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: Session Timeout and Direct Reference to login page
Tomcat behaves according to the Servlet/JSP specs. It creates a new session if a request is made after the previous one expires. It's not too difficult to write your own, I did. -Write a session-timeout.jsp with a link to your login. -Define a context-param in web.xml (session-timeout-page-url) or something like that, which defines the name of your session-timeout.jsp -At the top of every servlet check for the existence of an object that get's put in session during login (an empty string will do). If it's null, forward to the session-timeout.jsp. Of course, you could also just forward straight to the login page and bypass the session-timeout.jsp altogether. If you're doing everything with JSPs, you could just use an include for the code that does the checking so you don't have to put the same code on the top of every JSP. You could also do the same thing from a Filter. On Wednesday 19 May 2004 04:35 pm, Jonathan Eric Miller wrote: It's too bad there isn't a session-timeout-page element that you can put in web.xml kind of like the error-page element... Jon - Original Message - From: Jonathan Eric Miller [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, May 19, 2004 2:58 PM Subject: Re: Session Timeout and Direct Reference to login page Renato, Did you ever receive a response to this? I'm having the same problem. My current problem is slightly more complicated though. I have my application protected using container based security, but, I also have single-sign on enabled. So, the user doesn't get redirected back to the login page when the session times out. Previously, I used to make it so that if the session had expired (detected by my main JavaBean not being present (I was never able to figure out how to determine whether it was a new session or one that had expired and hence couldn't display an error message in the later case)), I'd just redirect the user back to the first page of my application. However, now, I'm using JavaServer Faces. As a result, I'm not the one implementing the controller part of my application, JSF is. Someone mentioned something about using HttpSessionListener. I don't see how that can work because you don't have a handle to the request and response. Is there a standard way of handling session timeouts? All I want to do is detect when a session has timed out for a user and display a page stating such when the user makes a request after the session has timed out. It seems like this should be a straight forward thing to do. Am I missing something? Jon - Original Message - From: Renato Romano [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Tuesday, March 02, 2004 3:31 AM Subject: Session Timeout and Direct Reference to login page I have two problems i'm facing with every web application using declarative security model, that is: 1) Detect that the user session has expired, and forward him to an appropriate login page; Usually we build webapp in which the home page shows a login form; to handle this, I use to make a index.jsp page which redirects the user to a protected page; this is handled by the container which then shows my login page (as specified in web.xml) that is my HOME page. With this approach however, I can't detect session expirying, so if the session times out, the user is presented with the HOME page (the login page) without further notice or advice!! I tried to solve this with a filter, but it seems the container (Tomcat 4.1.127 inside Jboss) forwards to the login page without calling the filter. 2) If the user waits too long reading the home/login page, the sessions times out, Tomcat looses the reference to the previously requested protected page, and on login shows an Invalid Direct refernce to form login page error. Again a filter seem not to be useful in this case, since Tomcat commits the error without calling the filter!! Any help or hint on this topic is very, very appreciated Renato Renato Romano Sistemi e Telematica S.p.A. Calata Grazie - Vial Al Molo Giano 16127 - GENOVA e-mail: [EMAIL PROTECTED] Tel.: 010 2712603 _ - 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] -- Ben Souther F.W. Davison Company, Inc. This e
Re: Session Timeout and Direct Reference to login page
It's too bad there isn't a session-timeout-page element that you can put in web.xml kind of like the error-page element... Jon - Original Message - From: Jonathan Eric Miller [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, May 19, 2004 2:58 PM Subject: Re: Session Timeout and Direct Reference to login page Renato, Did you ever receive a response to this? I'm having the same problem. My current problem is slightly more complicated though. I have my application protected using container based security, but, I also have single-sign on enabled. So, the user doesn't get redirected back to the login page when the session times out. Previously, I used to make it so that if the session had expired (detected by my main JavaBean not being present (I was never able to figure out how to determine whether it was a new session or one that had expired and hence couldn't display an error message in the later case)), I'd just redirect the user back to the first page of my application. However, now, I'm using JavaServer Faces. As a result, I'm not the one implementing the controller part of my application, JSF is. Someone mentioned something about using HttpSessionListener. I don't see how that can work because you don't have a handle to the request and response. Is there a standard way of handling session timeouts? All I want to do is detect when a session has timed out for a user and display a page stating such when the user makes a request after the session has timed out. It seems like this should be a straight forward thing to do. Am I missing something? Jon - Original Message - From: Renato Romano [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Tuesday, March 02, 2004 3:31 AM Subject: Session Timeout and Direct Reference to login page I have two problems i'm facing with every web application using declarative security model, that is: 1) Detect that the user session has expired, and forward him to an appropriate login page; Usually we build webapp in which the home page shows a login form; to handle this, I use to make a index.jsp page which redirects the user to a protected page; this is handled by the container which then shows my login page (as specified in web.xml) that is my HOME page. With this approach however, I can't detect session expirying, so if the session times out, the user is presented with the HOME page (the login page) without further notice or advice!! I tried to solve this with a filter, but it seems the container (Tomcat 4.1.127 inside Jboss) forwards to the login page without calling the filter. 2) If the user waits too long reading the home/login page, the sessions times out, Tomcat looses the reference to the previously requested protected page, and on login shows an Invalid Direct refernce to form login page error. Again a filter seem not to be useful in this case, since Tomcat commits the error without calling the filter!! Any help or hint on this topic is very, very appreciated Renato Renato Romano Sistemi e Telematica S.p.A. Calata Grazie - Vial Al Molo Giano 16127 - GENOVA e-mail: [EMAIL PROTECTED] Tel.: 010 2712603 _ - 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: Session Timeout and Direct Reference to login page
Thanks. I think option #1 is what I'm looking for. What I don't understand
is what I need to do with the session listener though?
I don't understand how to determine whether the new session is truly new, or
if it's a new session because a previous session timed out. Could I use a
filter and check the incoming session ID and if the session ID isn't in the
list of session IDs that the server knows about, assume that it's an expired
session?
Does anyone have example source code on how to do this?
Jon
- Original Message -
From: QM [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Sent: Wednesday, May 19, 2004 3:16 PM
Subject: Re: Session Timeout and Direct Reference to login page
On Wed, May 19, 2004 at 02:58:05PM -0500, Jonathan Eric Miller wrote:
: All I want to do is detect when a session has timed out for a user and
: display a page stating such when the user makes a request after the
session
: has timed out. It seems like this should be a straight forward thing to
do.
: Am I missing something?
You could use a session listener and check its existence with a
filter... In other words:
// filter pseudocode
if( null != session.getAttribute( UserMarker ) ){
// pass the req and resp down the filter chain
}else{
// forward() to a your session timed out page
}
Is this what you're after?
Option #2: have each page meta-refresh to the your session timed out
page (set the refresh value 1 or 2 seconds beyond the session timeout).
This is more intrusive, though: people don't typically like it when
their browser starts moving around when they didn't explicitly ask.
-QM
--
software -- http://www.brandxdev.net
tech news -- http://www.RoarNetworX.com
-
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: Session Timeout and Direct Reference to login page
On Wed, May 19, 2004 at 02:58:05PM -0500, Jonathan Eric Miller wrote:
: All I want to do is detect when a session has timed out for a user and
: display a page stating such when the user makes a request after the session
: has timed out. It seems like this should be a straight forward thing to do.
: Am I missing something?
You could use a session listener and check its existence with a
filter... In other words:
// filter pseudocode
if( null != session.getAttribute( UserMarker ) ){
// pass the req and resp down the filter chain
}else{
// forward() to a your session timed out page
}
Is this what you're after?
Option #2: have each page meta-refresh to the your session timed out
page (set the refresh value 1 or 2 seconds beyond the session timeout).
This is more intrusive, though: people don't typically like it when
their browser starts moving around when they didn't explicitly ask.
-QM
--
software -- http://www.brandxdev.net
tech news -- http://www.RoarNetworX.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Timeout and Direct Reference to login page
Renato, Did you ever receive a response to this? I'm having the same problem. My current problem is slightly more complicated though. I have my application protected using container based security, but, I also have single-sign on enabled. So, the user doesn't get redirected back to the login page when the session times out. Previously, I used to make it so that if the session had expired (detected by my main JavaBean not being present (I was never able to figure out how to determine whether it was a new session or one that had expired and hence couldn't display an error message in the later case)), I'd just redirect the user back to the first page of my application. However, now, I'm using JavaServer Faces. As a result, I'm not the one implementing the controller part of my application, JSF is. Someone mentioned something about using HttpSessionListener. I don't see how that can work because you don't have a handle to the request and response. Is there a standard way of handling session timeouts? All I want to do is detect when a session has timed out for a user and display a page stating such when the user makes a request after the session has timed out. It seems like this should be a straight forward thing to do. Am I missing something? Jon - Original Message - From: Renato Romano [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Tuesday, March 02, 2004 3:31 AM Subject: Session Timeout and Direct Reference to login page I have two problems i'm facing with every web application using declarative security model, that is: 1) Detect that the user session has expired, and forward him to an appropriate login page; Usually we build webapp in which the home page shows a login form; to handle this, I use to make a index.jsp page which redirects the user to a protected page; this is handled by the container which then shows my login page (as specified in web.xml) that is my HOME page. With this approach however, I can't detect session expirying, so if the session times out, the user is presented with the HOME page (the login page) without further notice or advice!! I tried to solve this with a filter, but it seems the container (Tomcat 4.1.127 inside Jboss) forwards to the login page without calling the filter. 2) If the user waits too long reading the home/login page, the sessions times out, Tomcat looses the reference to the previously requested protected page, and on login shows an Invalid Direct refernce to form login page error. Again a filter seem not to be useful in this case, since Tomcat commits the error without calling the filter!! Any help or hint on this topic is very, very appreciated Renato Renato Romano Sistemi e Telematica S.p.A. Calata Grazie - Vial Al Molo Giano 16127 - GENOVA e-mail: [EMAIL PROTECTED] Tel.: 010 2712603 _ - 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]
Session Timeout and Direct Reference to login page
I have two problems i'm facing with every web application using declarative security model, that is: 1) Detect that the user session has expired, and forward him to an appropriate login page; Usually we build webapp in which the home page shows a login form; to handle this, I use to make a index.jsp page which redirects the user to a protected page; this is handled by the container which then shows my login page (as specified in web.xml) that is my HOME page. With this approach however, I can't detect session expirying, so if the session times out, the user is presented with the HOME page (the login page) without further notice or advice!! I tried to solve this with a filter, but it seems the container (Tomcat 4.1.127 inside Jboss) forwards to the login page without calling the filter. 2) If the user waits too long reading the home/login page, the sessions times out, Tomcat looses the reference to the previously requested protected page, and on login shows an Invalid Direct refernce to form login page error. Again a filter seem not to be useful in this case, since Tomcat commits the error without calling the filter!! Any help or hint on this topic is very, very appreciated Renato Renato Romano Sistemi e Telematica S.p.A. Calata Grazie - Vial Al Molo Giano 16127 - GENOVA e-mail: [EMAIL PROTECTED] Tel.: 010 2712603 _ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Session Timeout and Direct Reference to login page
I have two problems i'm facing with every web application using declarative security model, that is: 1) Detect that the user session has expired, and forward him to an appropriate login page; Usually we build webapp in which the home page shows a login form; to handle this, I use to make a index.jsp page which redirects the user to a protected page; this is handled by the container which then shows my login page (as specified in web.xml) that is my HOME page. With this approach however, I can't detect session expirying, so if the session times out, the user is presented with the HOME page (the login page) without further notice or advice!! I tried to solve this with a filter, but it seems the container (Tomcat 4.1.127 inside Jboss) forwards to the login page without calling the filter. 2) If the user waits too long reading the home/login page, the sessions times out, Tomcat looses the reference to the previously requested protected page, and on login shows an Invalid Direct refernce to form login page error. Again a filter seem not to be useful in this case, since Tomcat commits the error without calling the filter!! Any help or hint on this topic is very, very appreciated Renato Renato Romano Sistemi e Telematica S.p.A. Calata Grazie - Vial Al Molo Giano 16127 - GENOVA e-mail: [EMAIL PROTECTED] Tel.: 010 2712603 _ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Login page only via SSL
Hello all gurus, Could somebody explain me how to force Tomcat 4.1 using SSL for strictly only for login page? Thanks, Pranas
Re: Login page only via SSL
Possibly the best way described in : http://java.sun.com/webservices/docs/1.1/tutorial/doc/WebAppSecurity4.html Regards - Original Message - From: Pranas [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Monday, December 29, 2003 5:17 PM Subject: Login page only via SSL Hello all gurus, Could somebody explain me how to force Tomcat 4.1 using SSL for strictly only for login page? Thanks, Pranas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Login page only via SSL
Adding this to your web.xml should work: security-constraint web-resource-collection web-resource-nameSSL/web-resource-name url-pattern/login.jsp/url-pattern /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint login-config auth-methodBASIC/auth-method realm-nameSSL/realm-name /login-config Hope this helps -Duncan Smith www.pennymail.com Pranas wrote: Hello all gurus, Could somebody explain me how to force Tomcat 4.1 using SSL for strictly only for login page? Thanks, Pranas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Session problem?JDBCRealm: Invalid direct reference to form login page
I'm trying to use the JDCBRealm from Tomcat 4.1.27 with an enhydra 5.0 application servlet and got the following problem Invalid direct reference to form login page which seem to be related to the session management. From what I understand, a session is first created (by enhydra SessionMgr) when browsing unprotected page. Next a protected page is requested and we are redirected to the login page but with a new session created by Tomcat 4.1. The FormAuthenticator will save the initial request in this new session created by Tomcat 4.1. The user is then properly authenticated but Tomcat try to retrieve the initial request in the initial session created by Enhydra, and it is unable to access it, it creates another session and say there is an Invalid direct reference to form login page. REQUEST URI =/enhydra/catalogue/Categories.htm cookie=JSESSIONID=R3ubmDGE-O571edTbpty5Uu6 header=referer=http://localhost:8080/enhydra/AccueilGeneral.html header=cookie=JSESSIONID=R3ubmDGE-O571edTbpty5Uu6 requestedSessionId=R3ubmDGE-O571edTbpty5Uu6 --- Checking constraint 'SecurityConstraint[Protected Area]' against GET /catalogue/Categories.htm -- true Save request in session 'C8BC7F93D9808C8C7532B3282C364B14' Redirect to login page '/enhydra/NewLogin.html' Failed authenticate() test --- cookie=JSESSIONID=C8BC7F93D9808C8C7532B3282C364B14; domain=null; path=/enhydra header=Set-Cookie=JSESSIONID=C8BC7F93D9808C8C7532B3282C364B14; Path=/enhydra header=Location=http://localhost:8080/enhydra/NewLogin.html status=302 = REQUEST URI =/enhydra/NewLogin.html cookie=JSESSIONID=R3ubmDGE-O571edTbpty5Uu6 cookie=JSESSIONID=C8BC7F93D9808C8C7532B3282C364B14 header=referer=http://localhost:8080/enhydra/AccueilGeneral.html header=cookie=JSESSIONID=R3ubmDGE-O571edTbpty5Uu6; JSESSIONID=C8BC7F93D9808C8C7532B3282C364B14 requestedSessionId=R3ubmDGE-O571edTbpty5Uu6 --- Checking constraint 'SecurityConstraint[Protected Area]' against GET /NewLogin.html -- false Mapped to servlet 'enhydra' with servlet path '' and path info '/NewLogin.html' and update=true --- contentType=text/html; charset=ISO-8859-1 status=200 = REQUEST URI =/enhydra/j_security_check cookie=JSESSIONID=R3ubmDGE-O571edTbpty5Uu6 cookie=JSESSIONID=C8BC7F93D9808C8C7532B3282C364B14 header=referer=http://localhost:8080/enhydra/NewLogin.html header=cookie=JSESSIONID=R3ubmDGE-O571edTbpty5Uu6; JSESSIONID=C8BC7F93D9808C8C7532B3282C364B14 requestedSessionId=R3ubmDGE-O571edTbpty5Uu6 --- Security checking request POST /enhydra/j_security_check Authentication of 'dan' was successful Redirecting to original 'null' Failed authenticate() test --- cookie=JSESSIONID=91AD787C623278EF332FE2235EAB5451; domain=null; path=/enhydra header=Set-Cookie=JSESSIONID=91AD787C623278EF332FE2235EAB5451; Path=/enhydra message=Référence directe à la form de connexion (form login page) invalide remoteUser=null status=400 = _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
login page css not applied
Hi, I have a problem where the login page is not showing any images and not having the css applied to it. Here is my web.xml: --- web-app servlet servlet-nameController/servlet-name servlet-classcorej2ee.web.Controller/servlet-class init-param param-namecorej2ee.web.navigation.class/param-name param-valuecorej2ee.web.EnvEntryNavigator/param-value /init-param /servlet servlet-mapping servlet-nameController/servlet-name url-pattern/*.jsp/url-pattern /servlet-mapping welcome-file-list welcome-filewelcome.jsp/welcome-file welcome-fileindex.html/welcome-file /welcome-file-list resource-ref res-ref-namejdbc/afecWEBDB/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth /resource-ref security-constraint web-resource-collection web-resource-nameRegular and Power User/web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-nameRegularUser/role-name role-namePowerUser/role-name role-nameAdministrator/role-name /auth-constraint user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint security-constraint web-resource-collection web-resource-nameAdministrator/web-resource-name url-pattern/admin/*/url-pattern /web-resource-collection auth-constraint role-nameAdministrator/role-name /auth-constraint user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint login-config auth-methodFORM/auth-method form-login-config form-login-page/login.jsp/form-login-page form-error-page/loginError.html/form-error-page /form-login-config /login-config env-entry env-entry-nameroute/welcomePage/success/env-entry-name env-entry-value/welcome.jsp/env-entry-value env-entry-typejava.lang.String/env-entry-type /env-entry /web-app My images are under images folder in the root of the application and my css in under css folder in the root of my application. The webpage is referencing css, for example, like this: link href=css/background.css rel=stylesheet type=text/css I am know I am messing up security paths, but I can't figure out what to do about it. Any help would be greatly appreciated. Thanks. Yaakov Chaikin Software Engineer BAE SYSTEMS 301-838-6899 (phone) 301-838-6802 (fax) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: login page css not applied
US SSA said: Hi, I have a problem where the login page is not showing any images and not having the css applied to it. But after the user has authenticated, it works right? I'm not 100% sure about the setup of your webapp and I've been spending so much time with other products I've forgotten a lot of stuff, but it appears to me on first glance that you've got a security constraint on /*, which would include images/ and css/ in that webapp before the user has authenticated, wouldn't it? If not, then I've forgotten more than I realized. Anyway, if so, the browser is requesting the css and image files before the user has enough authentication to get them. That's why it's working after the user is authenticated and a role assigned. Rod. [snip] security-constraint web-resource-collection web-resource-nameRegular and Power User/web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-nameRegularUser/role-name role-namePowerUser/role-name role-nameAdministrator/role-name /auth-constraint user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: login page css not applied
Yes, you are right. However, when I changed the pattern to /*.jsp, the login page was skipped and the browser went straight to the protected page without any authentication. I am not sure what's going on. Yaakov Chaikin Software Engineer BAE SYSTEMS 301-838-6899 (phone) 301-838-6802 (fax) [EMAIL PROTECTED] -Original Message- From: Rod Giffin [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 1:31 PM To: [EMAIL PROTECTED] Subject: Re: login page css not applied US SSA said: Hi, I have a problem where the login page is not showing any images and not having the css applied to it. But after the user has authenticated, it works right? I'm not 100% sure about the setup of your webapp and I've been spending so much time with other products I've forgotten a lot of stuff, but it appears to me on first glance that you've got a security constraint on /*, which would include images/ and css/ in that webapp before the user has authenticated, wouldn't it? If not, then I've forgotten more than I realized. Anyway, if so, the browser is requesting the css and image files before the user has enough authentication to get them. That's why it's working after the user is authenticated and a role assigned. Rod. [snip] security-constraint web-resource-collection web-resource-nameRegular and Power User/web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-nameRegularUser/role-name role-namePowerUser/role-name role-nameAdministrator/role-name /auth-constraint user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint - 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: login page css not applied
I just did this same thing yesterday. Your CSS and images are being protected by the web resource containing url-pattern/*/url-pattern. Until a user has logged in, they won't be able to receive images, css, etc. Be more specific in your URL pattern so you don't include those common resources. -Original Message- From: Chaikin, Yaakov Y (US SSA) [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 12:06 PM To: [EMAIL PROTECTED] Subject: login page css not applied Hi, I have a problem where the login page is not showing any images and not having the css applied to it. Here is my web.xml: --- web-app servlet servlet-nameController/servlet-name servlet-classcorej2ee.web.Controller/servlet-class init-param param-namecorej2ee.web.navigation.class/param-name param-valuecorej2ee.web.EnvEntryNavigator/param-value /init-param /servlet servlet-mapping servlet-nameController/servlet-name url-pattern/*.jsp/url-pattern /servlet-mapping welcome-file-list welcome-filewelcome.jsp/welcome-file welcome-fileindex.html/welcome-file /welcome-file-list resource-ref res-ref-namejdbc/afecWEBDB/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth /resource-ref security-constraint web-resource-collection web-resource-nameRegular and Power User/web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-nameRegularUser/role-name role-namePowerUser/role-name role-nameAdministrator/role-name /auth-constraint user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint security-constraint web-resource-collection web-resource-nameAdministrator/web-resource-name url-pattern/admin/*/url-pattern /web-resource-collection auth-constraint role-nameAdministrator/role-name /auth-constraint user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint login-config auth-methodFORM/auth-method form-login-config form-login-page/login.jsp/form-login-page form-error-page/loginError.html/form-error-page /form-login-config /login-config env-entry env-entry-nameroute/welcomePage/success/env-entry-name env-entry-value/welcome.jsp/env-entry-value env-entry-typejava.lang.String/env-entry-type /env-entry /web-app My images are under images folder in the root of the application and my css in under css folder in the root of my application. The webpage is referencing css, for example, like this: link href=css/background.css rel=stylesheet type=text/css I am know I am messing up security paths, but I can't figure out what to do about it. Any help would be greatly appreciated. Thanks. Yaakov Chaikin Software Engineer BAE SYSTEMS 301-838-6899 (phone) 301-838-6802 (fax) [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: login page css not applied
Ok, I've seen that before. Probably your protected page has the same name as one of the welcome-file page matches in web.xml, or they're both present. If index.html is your welcome page, use that in the welcome-file setting and not an existing .jsp file. I think that's the way it works. Rod. US SSA said: Yes, you are right. However, when I changed the pattern to /*.jsp, the login page was skipped and the browser went straight to the protected page without any authentication. I am not sure what's going on. Yaakov Chaikin Software Engineer BAE SYSTEMS 301-838-6899 (phone) 301-838-6802 (fax) [EMAIL PROTECTED] -Original Message- From: Rod Giffin [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 1:31 PM To: [EMAIL PROTECTED] Subject: Re: login page css not applied US SSA said: Hi, I have a problem where the login page is not showing any images and not having the css applied to it. But after the user has authenticated, it works right? I'm not 100% sure about the setup of your webapp and I've been spending so much time with other products I've forgotten a lot of stuff, but it appears to me on first glance that you've got a security constraint on /*, which would include images/ and css/ in that webapp before the user has authenticated, wouldn't it? If not, then I've forgotten more than I realized. Anyway, if so, the browser is requesting the css and image files before the user has enough authentication to get them. That's why it's working after the user is authenticated and a role assigned. Rod. [snip] security-constraint web-resource-collection web-resource-nameRegular and Power User/web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-nameRegularUser/role-name role-namePowerUser/role-name role-nameAdministrator/role-name /auth-constraint user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: login page css not applied
Rod, I am sorry, but I am not 100% following you... Yes, you are right. I have the following situation: I am trying url: localhost/xxxWEB/ This gets forwared by the welcome-page to welcome.jsp, which I want to be protected. welcome.jsp page is in xxxWEB/ directory. Could you explain what you are suggesting again? Thanks. Yaakov Chaikin Software Engineer BAE SYSTEMS 301-838-6899 (phone) 301-838-6802 (fax) [EMAIL PROTECTED] -Original Message- From: Rod Giffin [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 1:46 PM To: [EMAIL PROTECTED] Subject: RE: login page css not applied Ok, I've seen that before. Probably your protected page has the same name as one of the welcome-file page matches in web.xml, or they're both present. If index.html is your welcome page, use that in the welcome-file setting and not an existing .jsp file. I think that's the way it works. Rod. US SSA said: Yes, you are right. However, when I changed the pattern to /*.jsp, the login page was skipped and the browser went straight to the protected page without any authentication. I am not sure what's going on. Yaakov Chaikin Software Engineer BAE SYSTEMS 301-838-6899 (phone) 301-838-6802 (fax) [EMAIL PROTECTED] -Original Message- From: Rod Giffin [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 1:31 PM To: [EMAIL PROTECTED] Subject: Re: login page css not applied US SSA said: Hi, I have a problem where the login page is not showing any images and not having the css applied to it. But after the user has authenticated, it works right? I'm not 100% sure about the setup of your webapp and I've been spending so much time with other products I've forgotten a lot of stuff, but it appears to me on first glance that you've got a security constraint on /*, which would include images/ and css/ in that webapp before the user has authenticated, wouldn't it? If not, then I've forgotten more than I realized. Anyway, if so, the browser is requesting the css and image files before the user has enough authentication to get them. That's why it's working after the user is authenticated and a role assigned. Rod. [snip] security-constraint web-resource-collection web-resource-nameRegular and Power User/web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-nameRegularUser/role-name role-namePowerUser/role-name role-nameAdministrator/role-name /auth-constraint user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint - 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: login page css not applied
US SSA said: Rod, I am sorry, but I am not 100% following you... Yes, you are right. I have the following situation: I am trying url: localhost/xxxWEB/ I think it would work if you set the welcome-file element to send the user by default to localhost/xxxWEB/login.html (or index.html or whatever) where the login form could reside. The welcome.jsp page should not be a default page if it is protected, or it will be served before the user is authenticated. Since login.html or whatnot is not a jsp page, it won't be protected by a security-constraint such as /*.jsp, and it will be able to be accessed. This gets forwared by the welcome-page to welcome.jsp, which I want to be protected. welcome.jsp page is in xxxWEB/ directory. Could you explain what you are suggesting again? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: login page css not applied
Rod, Actually, I am pretty sure that the welcome-file has nothing to do with it. All that does is tell the server which URL to try to serve up if you were to leave off the file name from the url you are typing in. So, in my case typing localhost/xxxWEB/ is equivalent to localhost/xxxWEB/welcome.jsp. The real problem that I can't figure out is why when I specify that I am only securing *.jsp, it secures nothing. I'll have to research that one. Yaakov Chaikin Software Engineer BAE SYSTEMS 301-838-6899 (phone) 301-838-6802 (fax) [EMAIL PROTECTED] -Original Message- From: Rod Giffin [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 2:34 PM To: [EMAIL PROTECTED] Subject: RE: login page css not applied US SSA said: Rod, I am sorry, but I am not 100% following you... Yes, you are right. I have the following situation: I am trying url: localhost/xxxWEB/ I think it would work if you set the welcome-file element to send the user by default to localhost/xxxWEB/login.html (or index.html or whatever) where the login form could reside. The welcome.jsp page should not be a default page if it is protected, or it will be served before the user is authenticated. Since login.html or whatnot is not a jsp page, it won't be protected by a security-constraint such as /*.jsp, and it will be able to be accessed. This gets forwared by the welcome-page to welcome.jsp, which I want to be protected. welcome.jsp page is in xxxWEB/ directory. Could you explain what you are suggesting again? - 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]
j_security_check - Bookmarking the login page. A teaser!
Hello, I have recently switched my site to using form-based logins. I found as soon as I started testing that there is a fundamental problem with this approach. When the user get sent via a click to a protected page they get the login screen. The only problem arises when a user bookmarks the login screen. If they bookmark the login screen then use this bookmark to bring it up, when they enter their details Tomcat doesn't know where to bring them next and hence gives them an error message. I can use Apache rewriting or aliasing if you think either of these will help solve the problem. Any suggestions? Surely this problem has been encountered by everyone who has ever implemented form-based login, or do they just not? Thanks, Andoni
RE: j_security_check - Bookmarking the login page. A teaser!
Hi Adoni, No... you are not alone. I've been there too! My half hearted solution was to simply display a message on the login page asking them not to bookmark it. I think the proper solution would be to allow developers to specify a 'default' url along with the login and error urls. This page could then be displayed instead of the error page when there is no saved target url. You will probably also come across another non-obvious problem to do with form-based security. When people use download accelerators like 'GetRight' etc these programs attempt to download a given url. Unfortunately if the item they are trying to download falls under your protected region Tomcat will present them with the login page instead of the resource they were after. This will happen even if you have successfully logged in because as far as Tomcat is concerned the request came from a new and as yet not logged in session. Regards, David Legg Web Analyst - 3Dlabs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: j_security_check - Bookmarking the login page. A teaser!
Just a noob firing off into the dark... Couldn't you have a small piece of code that checks for the session and if they are bringing up the login page directly (ie no session info) then take them to the index. I'm going to get this on my site too so I will interested in a solution. G. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: j_security_check - Bookmarking the login page. A teaser!
On 11/19/2003 01:08 PM Graham Reeds wrote: Just a noob firing off into the dark... Couldn't you have a small piece of code that checks for the session and if they are bringing up the login page directly (ie no session info) then take them to the index. No, 'fraid not, your app never gets to see requests to j_security_check - it's handled by tomcat beforehand. Adam -- struts 1.1 + tomcat 5.0.12 + java 1.4.2 Linux 2.4.20 RH9 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: j_security_check - Bookmarking the login page. A teaser!
Adam, On 11/19/2003 01:08 PM Graham Reeds wrote: Just a noob firing off into the dark... Couldn't you have a small piece of code that checks for the session and if they are bringing up the login page directly (ie no session info) then take them to the index. No, 'fraid not, your app never gets to see requests to j_security_check - it's handled by tomcat beforehand. Right, and the user never sees this URL. They're talking about intercepting the request for the login *page*, not the j_security_check request. -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: j_security_check - Bookmarking the login page. A teaser!
Actually one of my first attempts at a solution was this in reverse. I was saying if there is a session take them on in to the main menu page. This does not work either though as if there was no session and they had only called this page (say from a bookmark) they were still stuck. The reason your way does not work is given by another response. Andoni. - Original Message - From: Graham Reeds [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 12:08 PM Subject: Re: j_security_check - Bookmarking the login page. A teaser! Just a noob firing off into the dark... Couldn't you have a small piece of code that checks for the session and if they are bringing up the login page directly (ie no session info) then take them to the index. I'm going to get this on my site too so I will interested in a solution. G. - 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: j_security_check - Bookmarking the login page. A teaser!
The bookmarking of the login page is a well known issue. However,
without dumping CMS there seems to be little to do but resort to a few
hacks ;(
Our hack pt1:
Add to the top of the login page a redirect to a sensible entry point
for the app:
% if (request.getSession(false).isNew())
response.sendRedirect(/index.jsp); %
Our hack pt2:
Add an error page that catches the 'illegal direct reference to login
page' (or whatever it is). Use this error page to redirect to a sensible
entry point to the app.
eg:
% Object badUri = request.getAttribute(javax.servlet.error.request_uri);
Object errorCode =
request.getAttribute(javax.servlet.error.status_code);
if (/j_security_check.equalsIgnoreCase(badUri.toString())
400.equals(errorCode.toString())) {
response.sendRedirect(/index.jsp);
return;
}
%
Pt 2 also catches things like a user sitting on the login page until the
session times out.
HTH,
Jon
David Legg wrote:
Hi Adoni,
No... you are not alone. I've been there too!
My half hearted solution was to simply display a message on the login page
asking them not to bookmark it. I think the proper solution would be to
allow developers to specify a 'default' url along with the login and error
urls. This page could then be displayed instead of the error page when
there is no saved target url.
You will probably also come across another non-obvious problem to do with
form-based security. When people use download accelerators like 'GetRight'
etc these programs attempt to download a given url. Unfortunately if the
item they are trying to download falls under your protected region Tomcat
will present them with the login page instead of the resource they were
after. This will happen even if you have successfully logged in because as
far as Tomcat is concerned the request came from a new and as yet not logged
in session.
Regards,
David Legg
Web Analyst - 3Dlabs
-
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: j_security_check - Bookmarking the login page. A teaser!
Andoni:
Which version of Tomcat do you use? On Tomcat 5.0.14, if you access a
protected page, the web browser displays the login page, but in the
address field, the browser continues to list the protected page address.
If you bookmark the page, your browser stores the address of the
protected page, not the login page.
As a consequence of the browser preserving the protected page address,
but displaying the login page, the browser continues to display links
and images relative to the protected page's URL. As the protected page
may be located in any protected path, your login page may not properly
display images or import stylesheets located in other unprotected areas,
including those in the same directory as the login page. In order to
guarantee that the login page refers correctly to these unprotected
objects, the login page must refer to them using addresses relative to
the application context (in the address
http://www.mytomcatsite.net/myapp, myapp is the context). For
example, you could use the JSTL c:url tag to set the context address
(URL) and refer to objects relative to this address:
%@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core%
%-- Calculate URLs relative to application context. --% c:url
var=contextUrl value=//
!DOCTYPE html PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN
http://www.w3.org/TR/REC-html40/loose.dtd;
html
head
link rel=stylesheet href=${contextUrl}Style/General.css
type=text/css /head body
a href=${contextUrl}View/index.jsp
img src=${contextUrl}Image/menu_r1_c1.gif
width=80
height=80/
/a
/body
/html
Unless you specify an absolute address, both JSTL tags c:url and
c:redirect form addresses relative to the application context. These
come in handy in your login page.
Derek
-Original Message-
From: Andoni [mailto:[EMAIL PROTECTED]
Sent: November 19, 2003 5:14 AM
To: Tomcat Users List
Subject: j_security_check - Bookmarking the login page. A teaser!
Hello,
I have recently switched my site to using form-based logins.
I found as soon as I started testing that there is a fundamental problem
with this approach. When the user get sent via a click to a protected
page they get the login screen. The only problem arises when a user
bookmarks the login screen. If they bookmark the login screen then use
this bookmark to bring it up, when they enter their details Tomcat
doesn't know where to bring them next and hence gives them an error
message.
I can use Apache rewriting or aliasing if you think either of these will
help solve the problem.
Any suggestions? Surely this problem has been encountered by everyone
who has ever implemented form-based login, or do they just not?
Thanks,
Andoni
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: j_security_check - Bookmarking the login page. A teaser!
Hi,
I have implemented this and on first sight it seems to work perfectly. Can
you please just confirm my understanding of it though so I am sure I know
what I am doing:
1. The error page part need never really come in to play.
2. A user calls the login page and it basically is using the session's isNew
method to decide whether this is a session just newly created from a
bookmark or a session that was in existence before the login page was
displayed as would be the case with one that had been created in whichever
page had called index.jsp.
Thanks,
Andoni.
- Original Message -
From: Jon Wingfield [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Sent: Wednesday, November 19, 2003 2:54 PM
Subject: Re: j_security_check - Bookmarking the login page. A teaser!
The bookmarking of the login page is a well known issue. However,
without dumping CMS there seems to be little to do but resort to a few
hacks ;(
Our hack pt1:
Add to the top of the login page a redirect to a sensible entry point
for the app:
% if (request.getSession(false).isNew())
response.sendRedirect(/index.jsp); %
Our hack pt2:
Add an error page that catches the 'illegal direct reference to login
page' (or whatever it is). Use this error page to redirect to a sensible
entry point to the app.
eg:
% Object badUri =
request.getAttribute(javax.servlet.error.request_uri);
Object errorCode =
request.getAttribute(javax.servlet.error.status_code);
if (/j_security_check.equalsIgnoreCase(badUri.toString())
400.equals(errorCode.toString())) {
response.sendRedirect(/index.jsp);
return;
}
%
Pt 2 also catches things like a user sitting on the login page until the
session times out.
HTH,
Jon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: j_security_check - Bookmarking the login page. A teaser!
On 11/19/2003 02:57 PM Christopher Schultz wrote: No, 'fraid not, your app never gets to see requests to j_security_check - it's handled by tomcat beforehand. Right, and the user never sees this URL. They're talking about intercepting the request for the login *page*, not the j_security_check request. Oh right. Sorry. Was suffering an attack of abject stupidity. Adam -- struts 1.1 + tomcat 5.0.12 + java 1.4.2 Linux 2.4.20 RH9 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: j_security_check - Bookmarking the login page. A teaser!
Yup. The error page only rarely comes into play (and is unrelated to the
bookmarking issue). I've just tried it again to make sure i wasn't going
mad:
If you try to access a restricted page you get punted to the login page.
If you then don't login until after the just created session times out
you get a 400 error on j_security_check. The error page catches this and
redirects back to the login page.
Not the nicest user experience but better (arguably) than an error page.
Jon
Andoni wrote:
Hi,
I have implemented this and on first sight it seems to work perfectly. Can
you please just confirm my understanding of it though so I am sure I know
what I am doing:
1. The error page part need never really come in to play.
2. A user calls the login page and it basically is using the session's isNew
method to decide whether this is a session just newly created from a
bookmark or a session that was in existence before the login page was
displayed as would be the case with one that had been created in whichever
page had called index.jsp.
Thanks,
Andoni.
- Original Message -
From: Jon Wingfield [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Sent: Wednesday, November 19, 2003 2:54 PM
Subject: Re: j_security_check - Bookmarking the login page. A teaser!
The bookmarking of the login page is a well known issue. However,
without dumping CMS there seems to be little to do but resort to a few
hacks ;(
Our hack pt1:
Add to the top of the login page a redirect to a sensible entry point
for the app:
% if (request.getSession(false).isNew())
response.sendRedirect(/index.jsp); %
Our hack pt2:
Add an error page that catches the 'illegal direct reference to login
page' (or whatever it is). Use this error page to redirect to a sensible
entry point to the app.
eg:
% Object badUri =
request.getAttribute(javax.servlet.error.request_uri);
Object errorCode =
request.getAttribute(javax.servlet.error.status_code);
if (/j_security_check.equalsIgnoreCase(badUri.toString())
400.equals(errorCode.toString())) {
response.sendRedirect(/index.jsp);
return;
}
%
Pt 2 also catches things like a user sitting on the login page until the
session times out.
HTH,
Jon
-
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]
form login page does not appear for my custom authenticator?
Dear all,
I had a wierd problem working with my own authenticator. The form login page did not
appear at all but I got an error message stating Configuration error: Cannot perform
access control without an authenticated principal. By checking the log file, I
understood how this error was triggered but still could not solve it.
Since the login page did not appear, I had no chance to invoke j_security_check (by
clicking the submit button). Consequently the request url did not end with the string
j_security_check. Somewhere in the program, the following check thus failed.
// Is this the action request from the login page?
boolean loginAction =
requestURI.startsWith(contextPath)
requestURI.endsWith(Constants.FORM_ACTION);
// No -- Save this request and redirect to the form login page
if (!loginAction) {
session = getSession(request, true);
if (debug = 1)
log(Save request in session ' + session.getId() + ');
saveRequest(request, session);
if (debug = 1)
log(Redirect to login page ' + loginURI + ');
hres.sendRedirect(hres.encodeRedirectURL(loginURI));
return (false);
}
So I was redirected to the login page (again it did not appear at all). This time the
following check succeeded:
// Is this a request for the login page itself? Test here to avoid
// displaying it twice (from the user's perspective) -- once because
// of the save and redirect and once because of the restore and
// redirect performed below.
String loginURI = contextPath + config.getLoginPage();
if (requestURI.equals(loginURI)) {
if (debug = 1)
log(Requesting login page normally);
return (true); // Display the login page in the usual manner
}
I think this code assumes I have been already authenticated. That's why finally I got
the error.
My questions are:
1. When should the login page appear? I think it should appear before the call of the
corresponding authenticator, am I right?
2. Is there some special configuration to bring up the login page for user's custom
authenticator?
Any suggestions or hints would be greatly appreciated.
-
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
Invalid Reference To Login Page - workaround via a proxy?
Hi,
I'm using Tomcat 4.0.x. I have a requirement to have a login box on the first page of
my
site. This cannot be done in this version of Tomcat as we get Invalid Reference to
Login Page,
as the requestURI is set to null ( java realms require us to try and access a
protected resource, then
get transferred to the login page ).
I came up with the solution to post the login details to a servlet. This would look
a little like this:
http://localhost:8080/mysite/LoginProxy?j_username=administratorj_password=midletsitej_forward=/index.jsp
My program would then alter the Request object, changing the requestURI field with the
j_forward parameter.
I couldn't get access to any setter properties of the request, so I subclasses
HttpServletRequestWrapper
and overrode the getRequestURI method to return the j_forward parameter's value if the
requestURI was
null. I then call dispatchRequest() with my HttpServletRequestWrapper object.
However this does not work. I get the error The requested resource
(/mysite/j_security_check) is not available.
However, if I simply put in http://localhost:8080/mysite/j_security_check, I do hit
the login target.
I expect this has something to do with the way that the request comes to tomcat. Maybe
it
checks for j_security_check when it checks whether my Proxy can be accessed. I'd hoped
that it
was some kind of accessible virtual page that could be accessed.
Is my line of investigation doomed?
Here's the code exerpt
public void service ( HttpServletRequest a_Request, HttpServletResponse a_Response )
throws java.io.IOException, ServletException
/*
-
20 July 03 Ben Jessel Created.
-
*/
{
// Method Location
final String ksLocation = service ( HttpServletRequest a_Request,
HttpServletResponse a_Response );
// Get the map of parameters from this request.
Map paramMap = a_Request.getParameterMap();
String sUserName= a_Request.getParameter ( c_ksUserNameParam );
String sPassword= a_Request.getParameter ( c_ksPasswordParam );
String sForward = a_Request.getParameter ( c_ksForwardParam );
LoginRequest tst = new LoginRequest ( a_Request, sForward ) ;
tst.setAttribute(j_username, sUserName );
tst.setAttribute(j_password, sPassword );
System.out.println( tst.getContextPath() + /j_security_check?j_username= +
sUserName + j_password= + sPassword );
// Get the RequestDispatcher
RequestDispatcher rd =
getServletConfig().getServletContext().getRequestDispatcher( tst.getContextPath() +
/j_security_check?j_username= + sUserName + j_password= + sPassword );
rd.forward(tst, a_Response);
}
}
class LoginRequest extends HttpServletRequestWrapper
{
String m_sForwardURI = ;
String requestURI = /midletsite/index.jsp;
/**
* @param arg0
*/
public LoginRequest(HttpServletRequest arg0) {
super(arg0);
}
/**
* @param arg0
*/
public LoginRequest(HttpServletRequest arg0, String a_sForwardURI ) {
super(arg0);
m_sForwardURI = a_sForwardURI;
}
public String getRequestURI()
{
return ( ( super.getRequestURI()==null ) ||
( getRequestURI().trim().length()==0 ) ) ? m_sForwardURI :
super.getRequestURI();
}
__
Join Freeserve http://www.freeserve.com/time/
Winner of the 2003 Internet Service Providers' Association awards for Best Unmetered
ISP and Best Consumer Application.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Invalid direct reference to form login page
Sometimes I get this error message... can someone give me a hint on the probable causes?? ___ :: Christian J. Dechery :: Accenture do Brasil :: CHT - Solutions Operations :: [EMAIL PROTECTED]
RE: Invalid direct reference to form login page
Usually you are interested in some secured resource, and you try to get it. Because it's secured you will be redirected to a login-page, and after authenticating yourself you will be redirected to the requested resource. If you go directly to the login-page, where will it redirect you when you are loged in ? This is the cause ... Abid -Original Message- From: Christian J. Dechery - ACCENTURE [mailto:[EMAIL PROTECTED] Sent: 21. juli 2003 16:09 To: Tomcat Users List (E-mail) Subject: Invalid direct reference to form login page Sometimes I get this error message... can someone give me a hint on the probable causes?? ___ :: Christian J. Dechery :: Accenture do Brasil :: CHT - Solutions Operations :: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RES: Invalid direct reference to form login page
yeah... I figured that. I have a logoff page, and it used to call the login in case the user wanted the re-authenticate... now I just have to link to the index page instead of the login page and everything works fine. Thanks! ___ :: Christian J. Dechery :: Accenture do Brasil :: CHT - Solutions Operations :: [EMAIL PROTECTED] -Mensagem original- De: Abid Ali Teepo [mailto:[EMAIL PROTECTED] Enviada em: segunda-feira, 21 de julho de 2003 11:22 Para: Tomcat Users List Assunto: RE: Invalid direct reference to form login page Usually you are interested in some secured resource, and you try to get it. Because it's secured you will be redirected to a login-page, and after authenticating yourself you will be redirected to the requested resource. If you go directly to the login-page, where will it redirect you when you are loged in ? This is the cause ... Abid -Original Message- From: Christian J. Dechery - ACCENTURE [mailto:[EMAIL PROTECTED] Sent: 21. juli 2003 16:09 To: Tomcat Users List (E-mail) Subject: Invalid direct reference to form login page Sometimes I get this error message... can someone give me a hint on the probable causes?? ___ :: Christian J. Dechery :: Accenture do Brasil :: CHT - Solutions Operations :: [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]
login page customization for CMA
Hi, I'm using container manager authentication, and I'm trying to display different messages inside the login page depending on the caller of that page, so if a request is made to the protected resource /account/*, I want to display suitable message to those who want to access account services in the login page, and same to the resource /order/*, but with a different message. The problem is that there is no way I could find to pass a parameter for example from a resource under /account/* to get this behaviour, because this parameter is actually not seen in the login page. I tried to look for where tomcat stores the request before it routes to the login page, but it looks to me that the process is not straight forward, and I need to play around with class loaders to get this info. Can anybody think of a way to implement this without getting into a container specific solution? _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
invalid direct reference to form login page...
Hi all, I've set up Tomcat (4.1.24) to do form based authentication. Everything works great, except I've had to deal with a lot of users that type in the url I've given them, get redirected to the login page, and bookmark the login page before logging in. Later, when they use the bookmark, they get sent to the login page, but get a Invalid direct reference to form login page... message once they log in. I understand why this happens, but don't know what to do about it. Is there a way to specify a default page to go to when the login page is requested directly? Thanks, Brian Kuhn Telscape Communications Brian Kuhn [EMAIL PROTECTED] _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: invalid direct reference to form login page...
Your problem has just recently been discussed on this list. Ben Jessel
proposed a workaround which I attached below. Hopefully, this might work for
you.
Stefan
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, June 27, 2003 1:42 PM
To: [EMAIL PROTECTED]
Subject: Possible workaround for invalid direct reference to
login page
Java Authentication with tomcat relies on realms. If you
access a page
protected by that realm you get directed to the login page.
However, it is possible to go directly to the login page (
this can happen
when users bookmark the login page inadvertantly ).
This happens in two scenarios:
1) The user is already logged in.
2) The user is not logged in.
If you authenticate yourself once you have gone directly to the login
page, you get a invalid direct reference error. Fair
enough, the login
page is trying to redirect to itself. Now, I tried to
workaround this by
checking if the session is null, and if it is, redirecting to some
protected page, eg. protected/index.jsp. No luck. It seems
that a session
is implicitly created, and a new session id gets created.
So I've tried a cookie strategy:
%
if ( request.getCookies()==null ) {
response.sendRedirect(//jsp/protected/index.jsp);
}
if ( request.getRemoteUser()!=null )
{
response.sendRedirect(/x/jsp/protected/index.jsp);
}
%
i.e, we wont have a cookie if we've gone directly to the
login page. But
we will have if we've tried to access a protected page and
then we've been
forwarded to a login page, tomcat will give us a cookie.
Now if we're already logged in ( which we check with
getRemoteUser() ,
then we just forward to user to an index page.
This seems o.k. However my index page actually includes my
login page! I'm
planning to get around this with some logic that only
includes the login
page excerpt if we are not logged in..
Ben
-Original Message-
From: Brian Kuhn [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 29, 2003 1:16 AM
To: [EMAIL PROTECTED]
Subject: invalid direct reference to form login page...
Hi all,
I've set up Tomcat (4.1.24) to do form based authentication.
Everything
works great, except I've had to deal with a lot of users that
type in the
url I've given them, get redirected to the login page, and
bookmark the
login page before logging in. Later, when they use the
bookmark, they get
sent to the login page, but get a Invalid direct reference
to form login
page... message once they log in.
I understand why this happens, but don't know what to do
about it. Is there
a way to specify a default page to go to when the login page
is requested
directly?
Thanks,
Brian Kuhn
Telscape Communications
Brian Kuhn
[EMAIL PROTECTED]
_
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
-
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]
Possible workaround for invalid direct reference to login page
Java Authentication with tomcat relies on realms. If you access a page
protected by that realm you get directed to the login page.
However, it is possible to go directly to the login page ( this can happen
when users bookmark the login page inadvertantly ).
This happens in two scenarios:
1) The user is already logged in.
2) The user is not logged in.
If you authenticate yourself once you have gone directly to the login
page, you get a invalid direct reference error. Fair enough, the login
page is trying to redirect to itself. Now, I tried to workaround this by
checking if the session is null, and if it is, redirecting to some
protected page, eg. protected/index.jsp. No luck. It seems that a session
is implicitly created, and a new session id gets created.
So I've tried a cookie strategy:
%
if ( request.getCookies()==null ) {
response.sendRedirect(//jsp/protected/index.jsp);
}
if ( request.getRemoteUser()!=null )
{
response.sendRedirect(/x/jsp/protected/index.jsp);
}
%
i.e, we wont have a cookie if we've gone directly to the login page. But
we will have if we've tried to access a protected page and then we've been
forwarded to a login page, tomcat will give us a cookie.
Now if we're already logged in ( which we check with getRemoteUser() ,
then we just forward to user to an index page.
This seems o.k. However my index page actually includes my login page! I'm
planning to get around this with some logic that only includes the login
page excerpt if we are not logged in..
Ben
invalid reference to form login page
Hello, I'm using container-managed security features in TC 4.1, and I'm receiving error: invalid reference to form login page when trying to login user. I use form-based authentication and have a page with appropriate configured form (j_username,j_password, etc). Where is the problem? Thanks, Jan Peknik. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: invalid reference to form login page error
You cannot access you logon page directly, try to access a page protected by you security constraints instead. This is an issue with the servlet 2.3 specs. Let's say you secured the domain /mysecuresite in your web.xml and you created a logon.jsp page for Tomcat form-based authentication. If you access /mysecuresite/mysecurepage.jsp, tomcat will redirect you to logon.jsp. If logon is successful, you get redirected back to the mysecurepage.jsp page. If you access logon.jsp directly, tomcat doesn't know where to send you on successful logon. Unfortunately, there is no notion of default page in the specs. Aymeric. [EMAIL PROTECTED] 06/22/03 04:46PM Hello, I'm using container-managed security features in TC 4.1, and I'm receiving error: invalid reference to form login page when trying to login user. I use form-based authentication and have a page with appropriate configured form (j_username,j_password, etc). Where is the problem? Thanks, Jan Peknik. Stydím se ho vytáhnout! A jaký je vá* dùvod vymìnit svùj telefon za nový? Nokia 6610 ji* od 6977 Kè. http://www.atlas.cz/clickAD.asp?ad=32086 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
invalid reference to form login page error
Hello, I'm using container-managed security features in TC 4.1, and I'm receiving error: invalid reference to form login page when trying to login user. I use form-based authentication and have a page with appropriate configured form (j_username,j_password, etc). Where is the problem? Thanks, Jan Peknik. Stydm se ho vythnout! A jak je v dvod vymnit svj telefon za nov? Nokia 6610 ji od 6977 K. http://www.atlas.cz/clickAD.asp?ad=32086 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: invalid reference to form login page error
On Mon, 23 Jun 2003 05:46, j p wrote: Hello, I'm using container-managed security features in TC 4.1, and I'm receiving error: invalid reference to form login page G'day, Funny that I was just installing Tomcat on my laptop and got the very same thing... I believe you can't access login.jsp directly you must be referred there, there could well be an option to switch this feature off somewhere but I haven't dug for it yet. Cheers, -- Jason Bainbridge http://jblinux.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with Bookmarking a Login Page
On Sun, Mar 23, 2003 at 05:10:43AM -0800, Mike Duffy wrote: Does anyone know of a Struts work around for the problem with Tomact in bookmarking the login page for container managed security? I believe, based on past conversations here, that Struts has its own security filter solution to use, instead of standard J2EE security. There was a brief thread on this issue about a month ago [http://www.mail-archive.com/[EMAIL PROTECTED]/msg59734.html] There is a SourceForge project called SecurityFilter that can be used to replace Tomcat's container managed security, but it would be nice to be able to work with Tomcat. I built my current project with standard J2EE security realms, and currently plan to tell my users don't do that. I do have a vague hope, that I will one day get around to exploring, of setting up a servlet filter that intervenes *before* the security realm gets invoked, and filters out direct requests to the login page, forwarding them to the main system page. However, I haven't even had a chance to look into this, yet. Has anyone tried to call j_security_check directly from an Action class? Once you can authenticate a user you would be able to get the roles for that user. Is there a way to set up a JDBC Realm purely in Struts? I did not see any information on this in a quick scan of the documentation. Hopefully, the good people working on Tomcat see this as a bug that needs to be fixed. As far as I've been able to determine, looking at the archives, the answer is broken as designed, i.e. the spec is broken but tomcat is implementing the spec (which, since tomcat is the reference implementation, I can't really fault them for). The upshot is they won't change it until the spec changes (and hopefully specifies a more reasonable solution). Quote from a recent thread in the Tomcat news group: I wish that there was a legitimate configuration change to enable you to bookmark a login.jsp page--such as a j_success_url parameter which instructs Tomcat where to send users if not doing an automated login process. Another user stated, ...I simply just can't believe that there are Tomcat instances out there in a live production environment with configured realms that suffer from this problem. Surely there must be something http://www.mail-archive.com/[EMAIL PROTECTED]/msg77974.html If you can figure out a way to have a filter intercept requests for the login page, that'd do the trick. The alternative would be to patch and build your own variation of tomcat, with code to deal with this specific situation. So you'd have a bit of extra work upgrading to new versions of tomcat... Hm... I wonder... if you put the login page *outside* the security realm, would that allow you to have the login page itself redirect to a more appropriate page, if directly invoked? I'll have to crack open the j_security_check class (can't remember, offhand at the moment, what's it's called) and see if there's some parameter it sets when it intercepts a request and forwards it to the login page. If it does set a parameter, checking for that would be a good test to see if the user directly invoked the login page. Steven J. Owens [EMAIL PROTECTED] I'm going to make broad, sweeping generalizations and strong, declarative statements, because otherwise I'll be here all night and this document will be four times longer and much less fun to read. Take it all with a grain of salt. - Me at http://darksleep.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with Bookmarking a Login Page
On Tue, 25 Mar 2003, Steven J. Owens wrote: Date: Tue, 25 Mar 2003 03:54:23 -0500 From: Steven J. Owens [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: Problem with Bookmarking a Login Page On Sun, Mar 23, 2003 at 05:10:43AM -0800, Mike Duffy wrote: Does anyone know of a Struts work around for the problem with Tomact in bookmarking the login page for container managed security? I believe, based on past conversations here, that Struts has its own security filter solution to use, instead of standard J2EE security. That is not actually true. There are alternative solutions to container-managed security which work fine with Struts (such as the securityfilter project at SourceForge), but they are by no means specific to Struts. There was a brief thread on this issue about a month ago [http://www.mail-archive.com/[EMAIL PROTECTED]/msg59734.html] There is a SourceForge project called SecurityFilter that can be used to replace Tomcat's container managed security, but it would be nice to be able to work with Tomcat. I built my current project with standard J2EE security realms, and currently plan to tell my users don't do that. I do have a vague hope, that I will one day get around to exploring, of setting up a servlet filter that intervenes *before* the security realm gets invoked, and filters out direct requests to the login page, forwarding them to the main system page. However, I haven't even had a chance to look into this, yet. Has anyone tried to call j_security_check directly from an Action class? Once you can authenticate a user you would be able to get the roles for that user. Is there a way to set up a JDBC Realm purely in Struts? I did not see any information on this in a quick scan of the documentation. Hopefully, the good people working on Tomcat see this as a bug that needs to be fixed. As far as I've been able to determine, looking at the archives, the answer is broken as designed, i.e. the spec is broken but tomcat is implementing the spec (which, since tomcat is the reference implementation, I can't really fault them for). The upshot is they won't change it until the spec changes (and hopefully specifies a more reasonable solution). Quote from a recent thread in the Tomcat news group: I wish that there was a legitimate configuration change to enable you to bookmark a login.jsp page--such as a j_success_url parameter which instructs Tomcat where to send users if not doing an automated login process. Another user stated, ...I simply just can't believe that there are Tomcat instances out there in a live production environment with configured realms that suffer from this problem. Surely there must be something http://www.mail-archive.com/[EMAIL PROTECTED]/msg77974.html If you can figure out a way to have a filter intercept requests for the login page, that'd do the trick. The alternative would be to patch and build your own variation of tomcat, with code to deal with this specific situation. So you'd have a bit of extra work upgrading to new versions of tomcat... Hm... I wonder... if you put the login page *outside* the security realm, would that allow you to have the login page itself redirect to a more appropriate page, if directly invoked? I'll have to crack open the j_security_check class (can't remember, offhand at the moment, what's it's called) and see if there's some parameter it sets when it intercepts a request and forwards it to the login page. If it does set a parameter, checking for that would be a good test to see if the user directly invoked the login page. Steven J. Owens [EMAIL PROTECTED] I'm going to make broad, sweeping generalizations and strong, declarative statements, because otherwise I'll be here all night and this document will be four times longer and much less fun to read. Take it all with a grain of salt. - Me at http://darksleep.com The hard-nosed answer -- if you have users trying to bookmark the login page, switch your app to BASIC authentication (where there is no such thing as a login page that can be bookmarked) instead. The login page should be considered to be a part of the container, not a part of the application; the container displays it only when an unauthenticated user first requests a protected resource -- exactly the way that BASIC authentication works in all web servers. The more realistic answer -- the case where users might want to bookmark the login page so they can get to it immediately -- is only one of many hundreds of potential use cases for authentication. The servlet spec does not currently provide any portable mechanisms to support this use case -- any short term solution you come up with (in Tomcat's case, that probably means modifying the Tomcat source code, because the j_security_check URL is only
Re: Problem with Bookmarking a Login Page
Thank Craig. I think the correct way to educate users is to create a specific error-page for the 400 error which says something like, You may have reached this error page from the login page.., and to have a link on that page to the default secured page (which means the login page would be displayed when the user clicked on the link). Can you confirm that j_security_check can only be called by the container in response to a browser request, meaning that it is not possible to call j_security_check directly or to force a call by forwarding or redirecting to a secured page? This would rule out any attemps to create a filter based on a call to the login page. Also, it doesn't look like there are any methods in the API to set users and roles in the session that could then be available to the methods getUserPrincipal(), isUserInRole(), etc. This would mean that if you are going to come up with your own A/A framework you have to bypass the container A/A completely. Is that correct? Mike --- Craig R. McClanahan [EMAIL PROTECTED] wrote: On Tue, 25 Mar 2003, Steven J. Owens wrote: Date: Tue, 25 Mar 2003 03:54:23 -0500 From: Steven J. Owens [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: Problem with Bookmarking a Login Page On Sun, Mar 23, 2003 at 05:10:43AM -0800, Mike Duffy wrote: Does anyone know of a Struts work around for the problem with Tomact in bookmarking the login page for container managed security? I believe, based on past conversations here, that Struts has its own security filter solution to use, instead of standard J2EE security. That is not actually true. There are alternative solutions to container-managed security which work fine with Struts (such as the securityfilter project at SourceForge), but they are by no means specific to Struts. There was a brief thread on this issue about a month ago [http://www.mail-archive.com/[EMAIL PROTECTED]/msg59734.html] There is a SourceForge project called SecurityFilter that can be used to replace Tomcat's container managed security, but it would be nice to be able to work with Tomcat. I built my current project with standard J2EE security realms, and currently plan to tell my users don't do that. I do have a vague hope, that I will one day get around to exploring, of setting up a servlet filter that intervenes *before* the security realm gets invoked, and filters out direct requests to the login page, forwarding them to the main system page. However, I haven't even had a chance to look into this, yet. Has anyone tried to call j_security_check directly from an Action class? Once you can authenticate a user you would be able to get the roles for that user. Is there a way to set up a JDBC Realm purely in Struts? I did not see any information on this in a quick scan of the documentation. Hopefully, the good people working on Tomcat see this as a bug that needs to be fixed. As far as I've been able to determine, looking at the archives, the answer is broken as designed, i.e. the spec is broken but tomcat is implementing the spec (which, since tomcat is the reference implementation, I can't really fault them for). The upshot is they won't change it until the spec changes (and hopefully specifies a more reasonable solution). Quote from a recent thread in the Tomcat news group: I wish that there was a legitimate configuration change to enable you to bookmark a login.jsp page--such as a j_success_url parameter which instructs Tomcat where to send users if not doing an automated login process. Another user stated, ...I simply just can't believe that there are Tomcat instances out there in a live production environment with configured realms that suffer from this problem. Surely there must be something http://www.mail-archive.com/[EMAIL PROTECTED]/msg77974.html If you can figure out a way to have a filter intercept requests for the login page, that'd do the trick. The alternative would be to patch and build your own variation of tomcat, with code to deal with this specific situation. So you'd have a bit of extra work upgrading to new versions of tomcat... Hm... I wonder... if you put the login page *outside* the security realm, would that allow you to have the login page itself redirect to a more appropriate page, if directly invoked? I'll have to crack open the j_security_check class (can't remember, offhand at the moment, what's it's called) and see if there's some parameter it sets when it intercepts a request and forwards it to the login page. If it does set a parameter, checking for that would be a good test to see if the user directly invoked the login page. Steven J. Owens [EMAIL PROTECTED] I'm
Status 400 - Invalid direct reference to form login page
Status 400 - Invalid direct reference to form login page The above error is generated when a user bookmarks the login page on an application server where container managed security is used. Does anyone have an elegant way of dealing with this error? Putting a note on the login page saying, Please dont bookmark me. is obviously inelegant. There does not seem to be a work around because j_security_check must be called from the container. All my attempts to call j_security_check directly failed. My attempts to create a filter also failed because I could not find a differentiator in the request between a bad call to the login page and a good call. I could force entry through an intermediate page by creating an error-page entry in the web.xml: error-page error-code400/error-code locationintermediatePage.jsp/location /error-page The intermediate page could have a link to a protected entry point (from which the container would call the login page). But, Status 400 is a general bad request, not necessarily this specific bad request. Note: If your location is a protected resource and you forward a user to that location by creating an error-page reference in web-xml, the user will get to the protected page, but not be authenticated. It seems that authentication is only invoked when it comes through a browser not through a forward or redirect. Actually, it seems that the only answer is to junk the container managed security wired into Tomcat and use the SecurityFilter project at SourceForge or write my own. Any thoughts? __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem with Bookmarking a Login Page
Does anyone know of a Struts work around for the problem with Tomact in bookmarking the login page for container managed security? There was a brief thread on this issue about a month ago [http://www.mail-archive.com/[EMAIL PROTECTED]/msg59734.html] There is a SourceForge project called SecurityFilter that can be used to replace Tomcat's container managed security, but it would be nice to be able to work with Tomcat. Has anyone tried to call j_security_check directly from an Action class? Once you can authenticate a user you would be able to get the roles for that user. Is there a way to set up a JDBC Realm purely in Struts? I did not see any information on this in a quick scan of the documentation. Hopefully, the good people working on Tomcat see this as a bug that needs to be fixed. Quote from a recent thread in the Tomcat news group: I wish that there was a legitimate configuration change to enable you to bookmark a login.jsp page--such as a j_success_url parameter which instructs Tomcat where to send users if not doing an automated login process. Another user stated, ...I simply just can't believe that there are Tomcat instances out there in a live production environment with configured realms that suffer from this problem. Surely there must be something http://www.mail-archive.com/[EMAIL PROTECTED]/msg77974.html Thanks. Mike __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with Bookmarking a Login Page
The way I always do it is I create a User (with email, fullName, etc.) class
which is mapped into my database to the same tables I instruct Tomcat to use
for a JdbcRealm. Then, I set up a filter which makes sure that a User
object exists when there is a user principal. You can use the
request.getUserPrincipal().getName() to find out the username of the logged
in user. In your filter, you do something like...
User user = ( User )request.getSession().getAttribute( user );
if( user == null request.getUserPrincipal() != null )
{
user = UserDao.getUserByName( request.getUserPrincipal().getName() );
request.setAttribute( user, user );
}
Hope this helps!
- Original Message -
From: Mike Duffy [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, March 23, 2003 8:10 AM
Subject: Problem with Bookmarking a Login Page
Does anyone know of a Struts work around for the problem with Tomact
in bookmarking the login page for container managed security?
There was a brief thread on this issue about a month ago
[http://www.mail-archive.com/[EMAIL PROTECTED]/msg59734.html]
There is a SourceForge project called SecurityFilter that can be used
to replace Tomcat's container managed security, but it would be nice
to be able to work with Tomcat.
Has anyone tried to call j_security_check directly from an Action
class? Once you can authenticate a user you would be able to get the
roles for that user.
Is there a way to set up a JDBC Realm purely in Struts? I did not see
any information on this in a quick scan of the documentation.
Hopefully, the good people working on Tomcat see this as a bug that
needs to be fixed.
Quote from a recent thread in the Tomcat news group: I wish that
there was a legitimate configuration change to enable you to bookmark
a login.jsp page--such as a j_success_url parameter which instructs
Tomcat where to send users if not doing an automated login process.
Another user stated, ...I simply just can't believe that there are
Tomcat instances out there in a live production environment with
configured realms that suffer from this problem. Surely there must be
something
http://www.mail-archive.com/[EMAIL PROTECTED]/msg77974.html
Thanks.
Mike
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
-
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: Own Login page
From: James Chrystal [mailto:[EMAIL PROTECTED] Sent: 25 February 2003 20:34 To: [EMAIL PROTECTED] Subject: Own Login page Paul, I've run into your problem as well, and here's how I solved it. Please post this answer to the mailing archives, as I don't want to subscribe and get all that email myself! This was a little tricky to figure out, but it does work. Jim BTW - I work for Red 5 Interactive, here in Des Moines, IA. We're web integrators, so if you need any work done, give us a call! A couple of pieces of information you probably already know: 1) When you request a secure resource from tomcat, tomcat redirects to the login page defined in the deployment descriptor (web.xml). 2) You cannot submit to j_security_check without having requested a secure resource, because Tomcat would not know where to send you once you logged in. 3) From the .jsp/servlet/.html page which comprises your login, you have no way of accessing the secure url originally requested. Here's what you need in your deployment descriptor: error-page error-code403/error-code location/loginError.jsp/location /error-page login-config auth-methodFORM/auth-method form-login-config form-login-page/loginHandler.jsp/form-login-page form-error-page/loginError.jsp/form-error-page /form-login-config /login-config Here's how it works: 1) User fills out login form, and submits - there are hidden fields on the form to tell the next .jsp in the change where to redirect. 2) preLogin.jsp receives the request, puts the j_username/j_password in the session, and redirects to the secureUrl. 3) Tomcat intercepts the request to the secureUrl and realizes the user is not logged in. Tomcat caches the securlUrl for that user, and forwards to the page defined in the deployment descriptor as the form-login-page, in our case, loginHandler.jsp. 4) The loginHandler.jsp page sends a redirect to the j_security_check url stored in the session, but not before appending the j_username and j_password from the session. 5) Tomcat again intercepts the request. If the j_username and j_password evaluate to a valid user, Tomcat will forward to the originally requested resource. If the credentials are invalid, Tomcat will redirect to the form-error-page defined in the deployment descriptor. This way, the user can re-enter his/her information and try to submit again. Here's some examples: 1) Create a login form - this can be a static html page or anything you like, and it can exist anywhere on your site. form name=login action=/preLogin.jsp method=post input type=hidden name=secureUrl value=/secure/someUrl/ input type=hidden name=j_security_check value=/j_security_check/ table tr tdj_username/td tdinput type=text name=j_username/td /tr tr tdj_password/td tdinput type=password name=j_password/td /tr tr td colspan=2input type=submit value=login/td /tr /table 2) Create a preLogin.jsp - this must be a jsp page, as we're going to do some work % request.getSession( true ); request.setAttribute( j_username, request.getParameter( j_username ) ); request.setAttribute( j_password, request.getParameter( j_password ) ); request.setAttribute( j_security_check, request.getParameter( j_security_check ) ); response.sendRedirect( request.getParameter( secureUrl ) ); % 3) Create a loginHandler.jsp page % response.sendRedirect( request.getSession().getAttribute( j_security_check ) + ?j_username= + request.getSession().getAttribute( j_username ) + j_password= + request.getSession().getAttribute( j_password ) ); % 4) Create a login error page - loginerror.jsp form name=preLogin action=preLogin.jsp input type=hidden name=secureUrl value=/secure/someUrl/ input type=hidden name=securityCheckUrl value=/j_security_check/ table tr tdj_username/td tdinput type=text name=j_username/td /tr tr tdj_password/td tdinput type=password name=j_password/td /tr tr td colspan=2input type=submit value=login/td /tr /table - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Own Login page
Dear Team I've been scanning the web, and this mail archive, looking for the answer to a question many have asked, but to which I not find any clear answer. Please bare with me... We are using form based authentication... works fine. However, on occasion we want to show a login form on a page. The user puts in their name and password, clicks submit and is taken to some protected url having been authorised. The way I see it, we need to set the action of this login form to a jsp/servlet, of our making, that takes the name and password, validates and sets up the appropriate authority object and forwards them to the target page or to an error page. Because we've set up the authority object for the session/context, the standard form based dialog does not appear. (Does this make sense?) But I can't see how we do what the j_security_check action must do. Someone must have been there, done that!. Could they enlighten me? I've waded through enough javadoc now :( Many thanks Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: error opening tomcat admin login page
Hi Mark, Sorry I didn't have much time yesterday so sent a very brief response! I experienced this problem when copying my Tomcat installation from W2K to Unix. The file transfer mechanism screwed up lots things, mainly case sensitivity, CR/LF. As you point out, only the admin application (struts based) seems to be affected. About a week ago Roberto Rios posted to the list with the exact same problem - and my advice on reinstallation worked for him. I am not familiar with your platform, but would guess that your gunzip or tar utilities are doing something unexpected when extracting the files. On the download page for Tomcat appears the following: NOTE: The tar files in this distribution use GNU tar extensions, and must be untarred with a GNU compatible version of tar. The version of tar on Solaris and Mac OS X will not work with these files. Add HP-UX to that list also :-( I extract everything on W2K from .zip, then use a custom ant target to tar and gzip everything back up again into a .tar.gz which does extract properly under HP-UX - ho-hum :-) I can only advise you try a reinstallation, if that still doesn't work, see if you can come up with a similar workaround. HTH -Original Message- From: Mark Strecker [mailto:[EMAIL PROTECTED]] Sent: Mittwoch, 19. Februar 2003 19:34 To: Tomcat Users List Subject: Re: error opening tomcat admin login page Thanks for your response. I am having trouble understanding what to do. I tried to track down the source of the problem and I found the message tag in struts-bean.tld ... but that's it. I couldn't find any properties files in the admin webapp ... would you be more specific about which file(s) you mean? Are you saying to reinstall Tomcat? I'm not sure what would happen differently if I did. It's a simple gunzip, tar -xf then run tomcat. Would you elaborate on this too? TIA, Mark Roberts, Eric wrote: Hi, Its a case sensitivity issue - when you installed either message got translated to MESSAGE or the other way round. Two solutions - 1) re-install from another souce or 2) go down into the admin app directories and change the names of the properties files manually HTH -Original Message- From: Mark Strecker [mailto:[EMAIL PROTECTED]] Sent: Mittwoch, 19. Februar 2003 17:42 To: Tomcat Users List Subject: error opening tomcat admin login page Hello All, I installed tomcat 4.1.18 on an sgi(Java 1.3.1 on Irix 6.5) and cannot open the admin login(/admin/login.jsp). I get this exception : org.apache.jasper.JasperException: Cannot find message resources under key org.apache.struts.action.MESSAGE at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:530, Compiled Code) at org.apache.jsp.login_jsp._jspService(login_jsp.java:188, Compiled Code) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137, Compiled Code) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853, Compiled Code) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:204, Compiled Code) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295, Compiled Code) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241, Compiled Code) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853, Compiled Code) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247, Compiled Code) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193, Compiled Code) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643, Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480, Compiled Code) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995, Compiled Code) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643, Compiled Code) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:550, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641, Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480, Compiled Code) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995, Compiled Code) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415, Compiled Code) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180, Compiled Code) at org.apache.catalina.core.StandardPipeline
Re: error opening tomcat admin login page
Thanks! That was the problem! I just needed to use gnu tar. Add sgi to the list of platforms that mess up the tomcat installation. Mark Roberts, Eric wrote: Hi Mark, Sorry I didn't have much time yesterday so sent a very brief response! I experienced this problem when copying my Tomcat installation from W2K to Unix. The file transfer mechanism screwed up lots things, mainly case sensitivity, CR/LF. As you point out, only the admin application (struts based) seems to be affected. About a week ago Roberto Rios posted to the list with the exact same problem - and my advice on reinstallation worked for him. I am not familiar with your platform, but would guess that your gunzip or tar utilities are doing something unexpected when extracting the files. On the download page for Tomcat appears the following: NOTE: The tar files in this distribution use GNU tar extensions, and must be untarred with a GNU compatible version of tar. The version of tar on Solaris and Mac OS X will not work with these files. Add HP-UX to that list also :-( I extract everything on W2K from .zip, then use a custom ant target to tar and gzip everything back up again into a .tar.gz which does extract properly under HP-UX - ho-hum :-) I can only advise you try a reinstallation, if that still doesn't work, see if you can come up with a similar workaround. HTH -Original Message- From: Mark Strecker [mailto:[EMAIL PROTECTED]] Sent: Mittwoch, 19. Februar 2003 19:34 To: Tomcat Users List Subject: Re: error opening tomcat admin login page Thanks for your response. I am having trouble understanding what to do. I tried to track down the source of the problem and I found the message tag in struts-bean.tld ... but that's it. I couldn't find any properties files in the admin webapp ... would you be more specific about which file(s) you mean? Are you saying to reinstall Tomcat? I'm not sure what would happen differently if I did. It's a simple gunzip, tar -xf then run tomcat. Would you elaborate on this too? TIA, Mark Roberts, Eric wrote: Hi, Its a case sensitivity issue - when you installed either message got translated to MESSAGE or the other way round. Two solutions - 1) re-install from another souce or 2) go down into the admin app directories and change the names of the properties files manually HTH -Original Message- From: Mark Strecker [mailto:[EMAIL PROTECTED]] Sent: Mittwoch, 19. Februar 2003 17:42 To: Tomcat Users List Subject: error opening tomcat admin login page Hello All, I installed tomcat 4.1.18 on an sgi(Java 1.3.1 on Irix 6.5) and cannot open the admin login(/admin/login.jsp). I get this exception : org.apache.jasper.JasperException: Cannot find message resources under key org.apache.struts.action.MESSAGE at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:530, Compiled Code) at org.apache.jsp.login_jsp._jspService(login_jsp.java:188, Compiled Code) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137, Compiled Code) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853, Compiled Code) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:204, Compiled Code) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295, Compiled Code) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241, Compiled Code) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853, Compiled Code) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247, Compiled Code) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193, Compiled Code) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643, Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480, Compiled Code) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995, Compiled Code) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643, Compiled Code) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:550, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641, Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480, Compiled Code) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995, Compiled Code) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415, Compiled Code) at org.apache.catalina.core.StandardHostValve.invoke
error opening tomcat admin login page
Hello All, I installed tomcat 4.1.18 on an sgi(Java 1.3.1 on Irix 6.5) and cannot open the admin login(/admin/login.jsp). I get this exception : org.apache.jasper.JasperException: Cannot find message resources under key org.apache.struts.action.MESSAGE at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:530, Compiled Code) at org.apache.jsp.login_jsp._jspService(login_jsp.java:188, Compiled Code) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137, Compiled Code) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853, Compiled Code) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:204, Compiled Code) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295, Compiled Code) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241, Compiled Code) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853, Compiled Code) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247, Compiled Code) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193, Compiled Code) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643, Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480, Compiled Code) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995, Compiled Code) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643, Compiled Code) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:550, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641, Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480, Compiled Code) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995, Compiled Code) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415, Compiled Code) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643, Compiled Code) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641, Compiled Code) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641, Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480, Compiled Code) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995, Compiled Code) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643, Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480, Compiled Code) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995, Compiled Code) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223, Compiled Code) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:432, Compiled Code) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:386, Compiled Code) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:534, Compiled Code) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:530, Compiled Code) at java.lang.Thread.run(Thread.java:484, Compiled Code) Any help would be greatly appreciated. Thanks, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: error opening tomcat admin login page
Hi, Its a case sensitivity issue - when you installed either message got translated to MESSAGE or the other way round. Two solutions - 1) re-install from another souce or 2) go down into the admin app directories and change the names of the properties files manually HTH -Original Message- From: Mark Strecker [mailto:[EMAIL PROTECTED]] Sent: Mittwoch, 19. Februar 2003 17:42 To: Tomcat Users List Subject: error opening tomcat admin login page Hello All, I installed tomcat 4.1.18 on an sgi(Java 1.3.1 on Irix 6.5) and cannot open the admin login(/admin/login.jsp). I get this exception : org.apache.jasper.JasperException: Cannot find message resources under key org.apache.struts.action.MESSAGE at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:530, Compiled Code) at org.apache.jsp.login_jsp._jspService(login_jsp.java:188, Compiled Code) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137, Compiled Code) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853, Compiled Code) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:204, Compiled Code) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295, Compiled Code) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241, Compiled Code) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853, Compiled Code) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247, Compiled Code) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193, Compiled Code) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643, Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480, Compiled Code) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995, Compiled Code) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643, Compiled Code) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:550, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641, Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480, Compiled Code) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995, Compiled Code) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415, Compiled Code) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643, Compiled Code) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641, Compiled Code) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641, Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480, Compiled Code) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995, Compiled Code) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643, Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480, Compiled Code) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995, Compiled Code) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223, Compiled Code) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:432, Compiled Code) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:386, Compiled Code) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:534, Compiled Code) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:530, Compiled Code) at java.lang.Thread.run(Thread.java:484, Compiled Code) Any help would be greatly appreciated. Thanks, Mark - To unsubscribe, e
Re: error opening tomcat admin login page
Thanks for your response. I am having trouble understanding what to do. I tried to track down the source of the problem and I found the message tag in struts-bean.tld ... but that's it. I couldn't find any properties files in the admin webapp ... would you be more specific about which file(s) you mean? Are you saying to reinstall Tomcat? I'm not sure what would happen differently if I did. It's a simple gunzip, tar -xf then run tomcat. Would you elaborate on this too? TIA, Mark Roberts, Eric wrote: Hi, Its a case sensitivity issue - when you installed either message got translated to MESSAGE or the other way round. Two solutions - 1) re-install from another souce or 2) go down into the admin app directories and change the names of the properties files manually HTH -Original Message- From: Mark Strecker [mailto:[EMAIL PROTECTED]] Sent: Mittwoch, 19. Februar 2003 17:42 To: Tomcat Users List Subject: error opening tomcat admin login page Hello All, I installed tomcat 4.1.18 on an sgi(Java 1.3.1 on Irix 6.5) and cannot open the admin login(/admin/login.jsp). I get this exception : org.apache.jasper.JasperException: Cannot find message resources under key org.apache.struts.action.MESSAGE at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:530, Compiled Code) at org.apache.jsp.login_jsp._jspService(login_jsp.java:188, Compiled Code) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137, Compiled Code) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853, Compiled Code) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:204, Compiled Code) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295, Compiled Code) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241, Compiled Code) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853, Compiled Code) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247, Compiled Code) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193, Compiled Code) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643, Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480, Compiled Code) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995, Compiled Code) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643, Compiled Code) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:550, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641, Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480, Compiled Code) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995, Compiled Code) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415, Compiled Code) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643, Compiled Code) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641, Compiled Code) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641, Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480, Compiled Code) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995, Compiled Code) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174, Compiled Code) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643, Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480, Compiled Code) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995, Compiled Code) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223, Compiled Code) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:432, Compiled Code) at org.apache.coyote.http11.Http11Protocol
JDBCRealm - entering site through login page
hi all, developing on w98 with tomcat 3.2.24, mysql 3.23.26, struts 1.0.2, jsk 1.3.1. will be deploying with same setup but on xp. i was taking a custom authorization approach originally, using a Struts LoginAction for the protected areas of my web app. but i thought a JDBCRealm would be a neat thing to implement. so, i got my JDBCRealm configured, no problem. what happens now, is when a user tries to load a protected resource, they are taken to the login page. however, if someone, say, bookmarks the login page itself, or loads http://www.mydomain.com/login.jsp, then logs in successfully, then all bets are off. i get a '404 page /protected_dir/null not found' message. of course, if they give it a duff username/pass they get sent to my form-error-page, as expected. what should i do to work around this? is there some way to point the login page to a Struts Action servlet? i figured the *only* action i was allowed to use with JDBCRealms was 'j_security_check', with the requisite 'j_username' and 'j_password' form fields. no struts actions allowed. is that right? or is there some way - using a JDBCRealm - to set a default page that login would go to on a successful login, in the cases where a user hasn't previously tried accessing a protected area, but instead simply tried loading the login.jsp page itself? any help anyone can give would be greatly appreciated. thanks in advance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
bypass form login page
Hi, I build an application with a private zone (protected by a FORM-LOGIN page). Is there a method to redirect automaticly a user in the private zone (after his inscription for exemple), without display the form-login-page ? (like a POST to j_security_check ...) Thks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bypass form login page
maybe: - recognize user already registered (cookie?) - start a session - add auth=yes or sth like that to the sessions-params - foward to the desired page rgds, henning Maxime Colas des Francs wrote: Hi, I build an application with a private zone (protected by a FORM-LOGIN page). Is there a method to redirect automaticly a user in the private zone (after his inscription for exemple), without display the form-login-page ? (like a POST to j_security_check ...) Thks - 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]
login error: direct reference to form login page
Hi All, I'm using Tomcat 4.1.12/JDK1.4.0_01/Struts I have multiple webapps where one of the webapps is the main entry point for the other webapps (contains menu, etc...). I use security constraints and form-based login to control access to the applications with SingleSignOn. Customers requirement is: after logging of, they want to return to the login page, so that a new user can immidiately login to the application. The application is running on a PocketPC 2002 handterminal with Pocket IE. Problem: the time between the last action (logout) and the new action (login) might be longer than the session timeout. In that case, the url originally requested is not available in the users session anymore, causing a 400-error:incorrect direct reference to form login page. I checked the FormAuthenticator class, and the behaviour is correct from that point of view (savedRequestURL(Session session) returns null). Is there a solution which lets the user be on the loginpage, while keeping the target url somewhere hidden (in a form-field in the login-page?), which is the alternative if no url is found in the session? Or maybe something else? Your input is highly appreciated! Regards, Klaas _ MSN 8 with e-mail virus protection service: 3 months FREE*. http://join.msn.com/?page=features/virusxAPID=42PS=47575PI=7324DI=7474SU= http://www.hotmail.msn.com/cgi-bin/getmsgHL=1216hotmailtaglines_eliminateviruses_3mf -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Workaround for login page direct reference
I'm going to have to sort this myself in the near future, but I don't quite see how the fact that you can forward to the protected resource is going to help? Isn't Tomcat going to automatically redirect (not forward - the distinction is important since redirecting will result in the login page's URL showing up in the browser's address bar) to the login page you've configured? Actually... since redirecting causes the browser to initiate a new request (for your WEB-INF/login page in this case), won't you get a 404-type error? Someone posted in a similar thread the other day that they intended to check a couple of things in the login page: 1. request.getRequestedSessionId() is *NULL* and 2. There is *NO* cookie named JSESSIONID I think the theory was that these would both be true on the first occasion the login page was accessed, but that if the user was already authenticated then the conditions wouldn't hold so the page should redirect to the index page. It's not nice to be relying on a cookie name (what if they change it between versions, or if cookies are turned off (though I'm not sure the authentication works then anyway!)?) but I'm inclined to move in that direction when it's my turn Mike. - Original Message - From: Ben Jessel [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED]; Brett M. Bergquist [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 10:55 AM Subject: Re: Workaround for login page direct reference I'll give that a go. Thanks Ben - Original Message - From: Brett M. Bergquist [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED]; Ben Jessel [EMAIL PROTECTED] Sent: Monday, December 16, 2002 8:54 PM Subject: Re: Workaround for login page direct reference Ben, I'm not sure but I believe that I've seen mention that you can forward to a page that is not accessible to the outside. That is, put the Login.jsp page within WEB-INF of your web app and it will not be available to the outside world but you can forward to it from inside the web app. I don't know if this will work because I have not tried it but it might. Brett ... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Workaround for login page direct reference
Thanks Mike, I guess, another workaround is that you could just invalidate their session if they go to the login page Now, I still don't see how all this is going help that direct reference to login pageas it seems that I get this error if I go to login.jsp and then enter in my details. - Say the user goes to /login.jsp directly - If we've protecteed that page Tomcat goes, no - that's a protected resource, and forwards to /login.jsp Otherwise, tomcat just goes to the login page. - You enter the user details, and then tomcat tries to forward to the page you came from ( i.e login.jsp ), but detects this is invalid ( presumably by comparing against login-page in the web.xml, and displays an error - direct reference to login page What I'd really, really, like, is some way of having an intermediate page where I can check the requestURI to find out what page tomcat is going to redirect me *after* login, so tomcat would give me login.jsp?page_to_forward_to=blah.jsp... but alas, I don't think I can... - Original Message - From: Mike W-M [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 11:28 AM Subject: Re: Workaround for login page direct reference I'm going to have to sort this myself in the near future, but I don't quite see how the fact that you can forward to the protected resource is going to help? Isn't Tomcat going to automatically redirect (not forward - the distinction is important since redirecting will result in the login page's URL showing up in the browser's address bar) to the login page you've configured? Actually... since redirecting causes the browser to initiate a new request (for your WEB-INF/login page in this case), won't you get a 404-type error? Someone posted in a similar thread the other day that they intended to check a couple of things in the login page: 1. request.getRequestedSessionId() is *NULL* and 2. There is *NO* cookie named JSESSIONID I think the theory was that these would both be true on the first occasion the login page was accessed, but that if the user was already authenticated then the conditions wouldn't hold so the page should redirect to the index page. It's not nice to be relying on a cookie name (what if they change it between versions, or if cookies are turned off (though I'm not sure the authentication works then anyway!)?) but I'm inclined to move in that direction when it's my turn Mike. - Original Message - From: Ben Jessel [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED]; Brett M. Bergquist [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 10:55 AM Subject: Re: Workaround for login page direct reference I'll give that a go. Thanks Ben - Original Message - From: Brett M. Bergquist [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED]; Ben Jessel [EMAIL PROTECTED] Sent: Monday, December 16, 2002 8:54 PM Subject: Re: Workaround for login page direct reference Ben, I'm not sure but I believe that I've seen mention that you can forward to a page that is not accessible to the outside. That is, put the Login.jsp page within WEB-INF of your web app and it will not be available to the outside world but you can forward to it from inside the web app. I don't know if this will work because I have not tried it but it might. Brett .. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Workaround for login page direct reference
Some more ideas... In my application I never have a direct link to the login.jsp. Try to link either to any file that will be accessed after login (e.g. content.jsp) or link only to the secure directory that you mapped and let the welcome-file redirect link to index.jsp or whatever. Doesn't solve the back button issue (check tomcat bug list), doesn't prohibit users to bookmark the login.jsp, but improves usability at least a bit by avoiding some opportunities to get errors. For your intermediate page thing I would suggest looking into using filters. Unfortunately nothing can prohibit the anyone from using the browser back button and try to relog again because in that back button case the login.jsp isn't even loaded again; so you can't even check for that error by any means. Michael -Original Message- From: Ben Jessel [mailto:[EMAIL PROTECTED]] Sent: Dienstag, 17. Dezember 2002 13:43 To: Tomcat Users List Subject: Re: Workaround for login page direct reference Thanks Mike, I guess, another workaround is that you could just invalidate their session if they go to the login page Now, I still don't see how all this is going help that direct reference to login pageas it seems that I get this error if I go to login.jsp and then enter in my details. - Say the user goes to /login.jsp directly - If we've protecteed that page Tomcat goes, no - that's a protected resource, and forwards to /login.jsp Otherwise, tomcat just goes to the login page. - You enter the user details, and then tomcat tries to forward to the page you came from ( i.e login.jsp ), but detects this is invalid ( presumably by comparing against login-page in the web.xml, and displays an error - direct reference to login page What I'd really, really, like, is some way of having an intermediate page where I can check the requestURI to find out what page tomcat is going to redirect me *after* login, so tomcat would give me login.jsp?page_to_forward_to=blah.jsp... but alas, I don't think I can... - Original Message - From: Mike W-M [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 11:28 AM Subject: Re: Workaround for login page direct reference I'm going to have to sort this myself in the near future, but I don't quite see how the fact that you can forward to the protected resource is going to help? Isn't Tomcat going to automatically redirect (not forward - the distinction is important since redirecting will result in the login page's URL showing up in the browser's address bar) to the login page you've configured? Actually... since redirecting causes the browser to initiate a new request (for your WEB-INF/login page in this case), won't you get a 404-type error? Someone posted in a similar thread the other day that they intended to check a couple of things in the login page: 1. request.getRequestedSessionId() is *NULL* and 2. There is *NO* cookie named JSESSIONID I think the theory was that these would both be true on the first occasion the login page was accessed, but that if the user was already authenticated then the conditions wouldn't hold so the page should redirect to the index page. It's not nice to be relying on a cookie name (what if they change it between versions, or if cookies are turned off (though I'm not sure the authentication works then anyway!)?) but I'm inclined to move in that direction when it's my turn Mike. - Original Message - From: Ben Jessel [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED]; Brett M. Bergquist [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 10:55 AM Subject: Re: Workaround for login page direct reference I'll give that a go. Thanks Ben - Original Message - From: Brett M. Bergquist [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED]; Ben Jessel [EMAIL PROTECTED] Sent: Monday, December 16, 2002 8:54 PM Subject: Re: Workaround for login page direct reference Ben, I'm not sure but I believe that I've seen mention that you can forward to a page that is not accessible to the outside. That is, put the Login.jsp page within WEB-INF of your web app and it will not be available to the outside world but you can forward to it from inside the web app. I don't know if this will work because I have not tried it but it might. Brett .. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-user- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Workaround for login page direct reference
Thanks mech, that's very interesting, however, i simply just can't believe that there are Tomcat instances out there in a live production environment with configured realms that suffer from this problem. Surely there must be something - Original Message - From: mech [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED]; 'Ben Jessel' [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 12:57 PM Subject: RE: Workaround for login page direct reference Some more ideas... In my application I never have a direct link to the login.jsp. Try to link either to any file that will be accessed after login (e.g. content.jsp) or link only to the secure directory that you mapped and let the welcome-file redirect link to index.jsp or whatever. Doesn't solve the back button issue (check tomcat bug list), doesn't prohibit users to bookmark the login.jsp, but improves usability at least a bit by avoiding some opportunities to get errors. For your intermediate page thing I would suggest looking into using filters. Unfortunately nothing can prohibit the anyone from using the browser back button and try to relog again because in that back button case the login.jsp isn't even loaded again; so you can't even check for that error by any means. Michael -Original Message- From: Ben Jessel [mailto:[EMAIL PROTECTED]] Sent: Dienstag, 17. Dezember 2002 13:43 To: Tomcat Users List Subject: Re: Workaround for login page direct reference Thanks Mike, I guess, another workaround is that you could just invalidate their session if they go to the login page Now, I still don't see how all this is going help that direct reference to login pageas it seems that I get this error if I go to login.jsp and then enter in my details. - Say the user goes to /login.jsp directly - If we've protecteed that page Tomcat goes, no - that's a protected resource, and forwards to /login.jsp Otherwise, tomcat just goes to the login page. - You enter the user details, and then tomcat tries to forward to the page you came from ( i.e login.jsp ), but detects this is invalid ( presumably by comparing against login-page in the web.xml, and displays an error - direct reference to login page What I'd really, really, like, is some way of having an intermediate page where I can check the requestURI to find out what page tomcat is going to redirect me *after* login, so tomcat would give me login.jsp?page_to_forward_to=blah.jsp... but alas, I don't think I can... - Original Message - From: Mike W-M [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 11:28 AM Subject: Re: Workaround for login page direct reference I'm going to have to sort this myself in the near future, but I don't quite see how the fact that you can forward to the protected resource is going to help? Isn't Tomcat going to automatically redirect (not forward - the distinction is important since redirecting will result in the login page's URL showing up in the browser's address bar) to the login page you've configured? Actually... since redirecting causes the browser to initiate a new request (for your WEB-INF/login page in this case), won't you get a 404-type error? Someone posted in a similar thread the other day that they intended to check a couple of things in the login page: 1. request.getRequestedSessionId() is *NULL* and 2. There is *NO* cookie named JSESSIONID I think the theory was that these would both be true on the first occasion the login page was accessed, but that if the user was already authenticated then the conditions wouldn't hold so the page should redirect to the index page. It's not nice to be relying on a cookie name (what if they change it between versions, or if cookies are turned off (though I'm not sure the authentication works then anyway!)?) but I'm inclined to move in that direction when it's my turn Mike. - Original Message - From: Ben Jessel [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED]; Brett M. Bergquist [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 10:55 AM Subject: Re: Workaround for login page direct reference I'll give that a go. Thanks Ben - Original Message - From: Brett M. Bergquist [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED]; Ben Jessel [EMAIL PROTECTED] Sent: Monday, December 16, 2002 8:54 PM Subject: Re: Workaround for login page direct reference Ben, I'm not sure but I believe that I've seen mention that you can forward to a page that is not accessible to the outside. That is, put the Login.jsp page within WEB-INF of your web app and it will not be available to the outside world but you can forward to it from
Re: Workaround for login page direct reference
Agreed. Don't forget that the beauty of open-source is that we can look at what Tomcat's doing... It throws the invalid reference error from the FormAuthenticator class, if no original request details have been saved as an internal note within the session. It doesn't immediately look like it's easy to get access to that information. As a last resort, it looks easy to alter that behaviour (assuming one can manage to recompile Tomcat). If no-one comes up with a better resolution to the problem (which, like you say, must be one that's cropped up many times before) then it would seem smart to try and get the developers to code in something a little more configurable. [I don't recall the spec says this behaviour is required, but...] i.e. it defaults to the current action unless you've specified a defaultPostLoginPage property of something or other. Still, the code had Craig's name on the top of it. Hopefully he'll come to our rescue Mike. - Original Message - From: Ben Jessel [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 2:16 PM Subject: Re: Workaround for login page direct reference Thanks mech, that's very interesting, however, i simply just can't believe that there are Tomcat instances out there in a live production environment with configured realms that suffer from this problem. Surely there must be something - Original Message - From: mech [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED]; 'Ben Jessel' [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 12:57 PM Subject: RE: Workaround for login page direct reference Some more ideas... In my application I never have a direct link to the login.jsp. Try to link either to any file that will be accessed after login (e.g. content.jsp) or link only to the secure directory that you mapped and let the welcome-file redirect link to index.jsp or whatever. Doesn't solve the back button issue (check tomcat bug list), doesn't prohibit users to bookmark the login.jsp, but improves usability at least a bit by avoiding some opportunities to get errors. For your intermediate page thing I would suggest looking into using filters. Unfortunately nothing can prohibit the anyone from using the browser back button and try to relog again because in that back button case the login.jsp isn't even loaded again; so you can't even check for that error by any means. Michael -Original Message- From: Ben Jessel [mailto:[EMAIL PROTECTED]] Sent: Dienstag, 17. Dezember 2002 13:43 To: Tomcat Users List Subject: Re: Workaround for login page direct reference Thanks Mike, I guess, another workaround is that you could just invalidate their session if they go to the login page Now, I still don't see how all this is going help that direct reference to login pageas it seems that I get this error if I go to login.jsp and then enter in my details. - Say the user goes to /login.jsp directly - If we've protecteed that page Tomcat goes, no - that's a protected resource, and forwards to /login.jsp Otherwise, tomcat just goes to the login page. - You enter the user details, and then tomcat tries to forward to the page you came from ( i.e login.jsp ), but detects this is invalid ( presumably by comparing against login-page in the web.xml, and displays an error - direct reference to login page What I'd really, really, like, is some way of having an intermediate page where I can check the requestURI to find out what page tomcat is going to redirect me *after* login, so tomcat would give me login.jsp?page_to_forward_to=blah.jsp... but alas, I don't think I can... - Original Message - From: Mike W-M [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 11:28 AM Subject: Re: Workaround for login page direct reference I'm going to have to sort this myself in the near future, but I don't quite see how the fact that you can forward to the protected resource is going to help? Isn't Tomcat going to automatically redirect (not forward - the distinction is important since redirecting will result in the login page's URL showing up in the browser's address bar) to the login page you've configured? Actually... since redirecting causes the browser to initiate a new request (for your WEB-INF/login page in this case), won't you get a 404-type error? Someone posted in a similar thread the other day that they intended to check a couple of things in the login page: 1. request.getRequestedSessionId() is *NULL* and 2. There is *NO* cookie named JSESSIONID I think the theory was that these would both be true on the first occasion the login page was accessed, but that if the user was already authenticated then the conditions wouldn't hold so the page should redirect
Workaround for login page direct reference
Hi, I've got a realm set up on Tomcat. It works fine - whenever I go to a protected page, I am forwarded to the login.jsp page. However, if I go to the login.jsp page directly and fill in my details I get Invalid direct reference to form login page. not surprising really as tomcat would get itself into an endless cycle. Now what are the strategies for hiding this page, so a hapless user who goes directly to the login page and enters his details doesn't get this message. I'd want to forward them onto the index page. Any ideas? Would I explicity bar the request of the requesting of the login page using my web server?..I doubt it, as I reckon tht the realm probably uses a sendRedirect(). I guess that I could check the refering page...hmm dunno...any ideas? Thanks -b
Re: Workaround for login page direct reference
Ben, I'm not sure but I believe that I've seen mention that you can forward to a page that is not accessible to the outside. That is, put the Login.jsp page within WEB-INF of your web app and it will not be available to the outside world but you can forward to it from inside the web app. I don't know if this will work because I have not tried it but it might. Brett - Original Message - From: Ben Jessel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 16, 2002 11:14 AM Subject: Workaround for login page direct reference Hi, I've got a realm set up on Tomcat. It works fine - whenever I go to a protected page, I am forwarded to the login.jsp page. However, if I go to the login.jsp page directly and fill in my details I get Invalid direct reference to form login page. not surprising really as tomcat would get itself into an endless cycle. Now what are the strategies for hiding this page, so a hapless user who goes directly to the login page and enters his details doesn't get this message. I'd want to forward them onto the index page. Any ideas? Would I explicity bar the request of the requesting of the login page using my web server?..I doubt it, as I reckon tht the realm probably uses a sendRedirect(). I guess that I could check the refering page...hmm dunno...any ideas? Thanks -b -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
How to reference a form login page?
Hi, I have a external site which is hosted on a server seperate from my tomcat server. That server should provide a login form that can be used to log in into an application on the tomcat web server. However, I could not figure out how to log in from an external host. The following code caused an error 400 Invalid direct reference to form login page: ... form method=POST action=http://mytomcatserver/mywebapp/j_security_check; input type=text name=j_username input type=password name=j_password /form ... The first server has its own domain name and is hosted by a big web hoster. On every web page there should be a login form that allows the user to log in on one of the tomcat web applications. The tomcat server has just an IP address and holds the web applications. How can I realize a login form that sits on a different server than the tomcat server. Thank You in advance, Hans -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: SSL security contraint for just the login page.
HAVENS,PETER (HP-Cupertino,ex3) wrote: I am using form based authentication on my Tomcat 4.0.4 server and I am trying to figure out how to set up a security constraint that would apply only to the login page. My global web.xml has a security constraint that points to a login.jsp page as the form-login-page. As I understand it, the global web.xml can only have one security-constraint. What I want to do is configure this login.jsp page to be served up via HTTPS only. This way users will not be submitting password as plain text. I know about using the user-data-constraint transport-guarantee, but I do not want to require SSL for all pages, just the login page. Is this possible? I don't know whether this is possible - I tried for a while, thinking like you that it was sufficient to protect the login page, until I Saw The Light. If you only protected the login page, then although the user's password would not be sent in clear, the session id on subsequent pages would be. Since a hacker only needs the session id to masquerade as your logged-in user, you MUST encrypt the entire session after login. This is what the servlet spec mandates, and what Tomcat does. Martin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
SSL security contraint for just the login page.
I am using form based authentication on my Tomcat 4.0.4 server and I am trying to figure out how to set up a security constraint that would apply only to the login page. My global web.xml has a security constraint that points to a login.jsp page as the form-login-page. As I understand it, the global web.xml can only have one security-constraint. What I want to do is configure this login.jsp page to be served up via HTTPS only. This way users will not be submitting password as plain text. I know about using the user-data-constraint transport-guarantee, but I do not want to require SSL for all pages, just the login page. Is this possible? I have included the security constraint of my web.xml file Thanks in advance, -Peter --attached web.xml file- security-constraint display-nameGryphon Authentication /display-name web-resource-collection web-resource-nameProtected Area/web-resource-name !-- Define the context-relative URL(s) to be protected -- url-pattern*.jsp/url-pattern url-pattern*.class/url-pattern url-pattern*.html/url-pattern url-pattern*.shtml/url-pattern url-pattern*.htm/url-pattern url-pattern*.shtm/url-pattern url-pattern*.js/url-pattern url-pattern*.cgi/url-pattern url-pattern*.php/url-pattern !-- If you list http methods, only those methods are protected -- http-methodDELETE/http-method http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint !-- Anyone with one of the listed roles may access this area -- role-name*/role-name /auth-constraint /security-constraint !-- Default login configuration uses form-based authentication -- login-config auth-methodFORM/auth-method realm-nameGryphon Form-Based Authentication/realm-name form-login-config form-login-page/login.jsp/form-login-page form-error-page/error.jsp/form-error-page /form-login-config /login-config
SSL just for a login page
Hi I have been working with tomcat with a web site. There is a initial login page which sends the username and password to a servlet that checks them against a database. I want to have the informatin sent over ssl but then i want the user to be sent back to a none ssl page for the rest of the session. With out explicitly calling https:// and http:// within the redirects (ie i want all locations relative) how do i canfigure tomcat. I have configured it to the login page is on ssl but when the servlet sends the user back to a page that page is also ssl. I have added this to my web.xml file security-constraint web-resource-collection web-resource-nameDataPortal/web-resource-name url-pattern/*/url-pattern /web-resource-collection user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint security-constraint web-resource-collection web-resource-nameDataPortal/web-resource-name url-pattern/Login.html/url-pattern url-pattern/servlet/LoginServlet/url-pattern http-methodGET/http-method /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint Also the second problem when i take off the Login page and off the CONFIDENTIAL section so a person goes to the login page and then enters the username and password, the information is sent to the server over ssl but my LoginServlet code cannot pick out the parameters passed to it??? Can anybosy help me with this Thanks glen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
AW: SSL just for a login page
Don't do it. It has been pointed out several times that it is not recommanded to switch from https to http and stay in the same session. That would open a !!!BIG!!! security hole. If you really know what you are doing, you can write a filter that redirects every request that came in over HTTPS (except the ones for your login pages) to HTTP. -Ursprüngliche Nachricht- Von: Drinkwater, GJ (Glen) [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 9. August 2002 15:11 An: '[EMAIL PROTECTED]' Betreff: SSL just for a login page initial login page which sends the username and password to a servlet that checks them against a database. I want to have the informatin sent over ssl but then i want the user to be sent -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: SSL just for a login page
Hi I am not am expert in the security of the web at the moment. Could you explain to me why this would open such a big secuirty hole from swapping from https to https. I was suggesting this because it read this i a 'professional j2ee' book?!! The problem i have is that i need the username and password to be encrypted but i have heard that ssl hits performance quite badly!! I dont think that i could handle filtering, so what do you suggest for the security?? What is the 'norm' for these such problems. Thanks Glen. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: SSL just for a login page
the problem is your own encryption isn't signed by a third party, which means if someone hack into your server, they could compromise the security. Hackers are smart and have tons of free time. If there's a hole, it will be found and exploited. Most big e-comm sites use hardware acceleration to improve the performance. If you're going to handle moderate SSL traffic, you should get hardware acceleration that sits between the webservers and the browser. Look at BigIP, network SSL modules or other hardware solutions. there are companies selling ssl ethernet cards for systems if you don't need heavy duty SSL. peter lin Drinkwater, GJ (Glen) wrote: Hi I am not am expert in the security of the web at the moment. Could you explain to me why this would open such a big secuirty hole from swapping from https to https. I was suggesting this because it read this i a 'professional j2ee' book?!! The problem i have is that i need the username and password to be encrypted but i have heard that ssl hits performance quite badly!! I dont think that i could handle filtering, so what do you suggest for the security?? What is the 'norm' for these such problems. Thanks Glen. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: SSL just for a login page
Why don't you just build your redirect after they log in. response.sendRedirect(http://; + request.getHostName() + /myApp/home.jsp); -Original Message- From: Drinkwater, GJ (Glen) [mailto:[EMAIL PROTECTED]] Sent: Friday, August 09, 2002 8:52 AM To: 'Tomcat Users List' Subject: RE: SSL just for a login page Hi I am not am expert in the security of the web at the moment. Could you explain to me why this would open such a big secuirty hole from swapping from https to https. I was suggesting this because it read this i a 'professional j2ee' book?!! The problem i have is that i need the username and password to be encrypted but i have heard that ssl hits performance quite badly!! I dont think that i could handle filtering, so what do you suggest for the security?? What is the 'norm' for these such problems. Thanks Glen. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: SSL just for a login page
Hi Let me reply to a few of the emails. the problem is your own encryption isn't signed by a third party, which means if someone hack into your server, they could compromise the security. wouldn't this still be a problem if my public key was signed by a CA?? isn't the cert. for the client to verify who i am, this would not effect the SSL encryption?? Why don't you just build your redirect after they log in. response.sendRedirect(http://; + request.getHostName() + /myApp/home.jsp); i have tried this. What i am doing is using the login to set up a session and adding a attribute to this session. Every jsp checks the session for this object to verify that the user has logged in, if they have not or they have logged out the user is unable to bookmark or go backward into the website. Using the redirect like this some how interferes with the session and messes up the checking. I am not sure why this happens? Glen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: SSL just for a login page
Drinkwater, GJ (Glen) wrote: Hi Let me reply to a few of the emails. the problem is your own encryption isn't signed by a third party, which means if someone hack into your server, they could compromise the security. wouldn't this still be a problem if my public key was signed by a CA?? isn't the cert. for the client to verify who i am, this would not effect the SSL encryption?? For more details on SSL, here's the spec. http://wp.netscape.com/eng/ssl3/draft302.txt Remember that using SSL include a lot than just encrypting data. It includes establishing secure session, cert management and other processes. In theory, if a hacker compromises your server they can break both a custom encryption ans ssl. But breaking SSL is harder than just decompiling java code to see which algo/padding/key scheme you are using. Whereas breaking SSL would require much more work. In reality, a hacker would more likely break into your database than mess with decompiling your code. Casual hackers will be discouraged by SSL. Hardcore hackers are hard to protect against. good luck with what ever you choose. peter -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: SSL just for a login page
Well, obviously the only thing being protected here is the login and password, user activity after the login will be open to snooping, hijacking, etc. So here's what I think you should do. 1) User logs in through ssl. 2) After a successful login, (still ssl, don't put anything session yet) pass the user's ID and a one-way hashed version of their password to a non ssl page that authenticates this information and sets up their session. Dave -Original Message- From: Drinkwater, GJ (Glen) [mailto:[EMAIL PROTECTED]] Sent: Friday, August 09, 2002 9:19 AM To: 'Tomcat Users List' Subject: RE: SSL just for a login page Hi Let me reply to a few of the emails. the problem is your own encryption isn't signed by a third party, which means if someone hack into your server, they could compromise the security. wouldn't this still be a problem if my public key was signed by a CA?? isn't the cert. for the client to verify who i am, this would not effect the SSL encryption?? Why don't you just build your redirect after they log in. response.sendRedirect(http://; + request.getHostName() + /myApp/home.jsp); i have tried this. What i am doing is using the login to set up a session and adding a attribute to this session. Every jsp checks the session for this object to verify that the user has logged in, if they have not or they have logged out the user is unable to bookmark or go backward into the website. Using the redirect like this some how interferes with the session and messes up the checking. I am not sure why this happens? Glen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
AW: SSL just for a login page
That's no solution, as now the oneway hash can be snooped and hijacked. You win absolutly nothing but wasted efford. -Ursprüngliche Nachricht- Von: Durham David Cntr 805CSS/SCBE [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 9. August 2002 16:30 An: Tomcat Users List Betreff: RE: SSL just for a login page 2) After a successful login, (still ssl, don't put anything session yet) pass the user's ID and a one-way hashed version of their password to a non ssl page that authenticates this information and sets up their session. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
AW: SSL just for a login page
If you switch from HTTPs to HTTP and keep the session, that means that now the sessionid is send unencrypted (either as cookie or as part of the url). So now everybody who can listen to your traffic, can take that data and steel the session and act as the owner of the session, and there is nothing you can do about it. Yes SSL has some effect on the performance, but to really feal it, you must get a high load on the server. In typical applications the main load comes from other hot spots. The higher the needed tranfer rate is the higher will the risk be that you experience some penalties, but I think it's cheaper to solve them by scaling the hardware. I think you should stresstest your application with both protocols and judge on your own, what impact HTTPs has and what you are willing to invest (in work or hardware) to reduce the impact. -Ursprüngliche Nachricht- Von: Drinkwater, GJ (Glen) [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 9. August 2002 15:52 An: 'Tomcat Users List' Betreff: RE: SSL just for a login page Could you explain to me why this would open such a big secuirty hole from swapping from https to https. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
AW: SSL just for a login page
Yes, I know, if you spend some more effort, you get a bit more security. (- define a time window where the code is valid) (- make the client IP part of the hashcode) But in the end all variants are less secure than https. -Ursprüngliche Nachricht- Von: Ralph Einfeldt Gesendet: Freitag, 9. August 2002 16:38 An: Tomcat Users List Betreff: AW: SSL just for a login page That's no solution, as now the oneway hash can be snooped and hijacked. You win absolutly nothing but wasted efford. -Ursprüngliche Nachricht- Von: Durham David Cntr 805CSS/SCBE [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 9. August 2002 16:30 An: Tomcat Users List Betreff: RE: SSL just for a login page 2) After a successful login, (still ssl, don't put anything session yet) pass the user's ID and a one-way hashed version of their password to a non ssl page that authenticates this information and sets up their session. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: SSL just for a login page
Like I said, you're session is open to snooping and hijacking, but your password is not revealed. -Original Message- From: Ralph Einfeldt [mailto:[EMAIL PROTECTED]] Sent: Friday, August 09, 2002 9:38 AM To: Tomcat Users List Subject: AW: SSL just for a login page That's no solution, as now the oneway hash can be snooped and hijacked. You win absolutly nothing but wasted efford. -Ursprüngliche Nachricht- Von: Durham David Cntr 805CSS/SCBE [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 9. August 2002 16:30 An: Tomcat Users List Betreff: RE: SSL just for a login page 2) After a successful login, (still ssl, don't put anything session yet) pass the user's ID and a one-way hashed version of their password to a non ssl page that authenticates this information and sets up their session. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: SSL just for a login page
what's to stop a hacker from stealing the session, then going to the user profile page and looking at the password? Of course if you do pass the user to http from https, you can still require profile management go through https, or simply never print the password to the browser. I personally wouldn't want to use a insecure site for anything with personal information. as others have said, you have to weigh the cost vs advantage of tight security. if you're prohibited by cost, ie paying for cert, and hardware, then you really don't have a choice. peter Durham David Cntr 805CSS/SCBE wrote: Like I said, you're session is open to snooping and hijacking, but your password is not revealed. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: SSL just for a login page
Yes, you are probably right, I will have to use ssl. Does anybody know of some good stress testing free software??? How does this sound. 1)User logs on and username and password send over ssl. password md5 hashed and compared against users on a database. 2)If valid user logs on, if not user sent to error page. 3) rest of session ssl. if database compromised, hash value would be no use??? Lastly, how do i enforce that the whole of the web site must be over ssl, except the initial welcome page so the user doesn't have to type in port numbers is it something like this in the web.xml file. security-constraint web-resource-collection web-resource-name***/web-resource-name url-pattern/index.html/url-pattern /web-resource-collection user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint security-constraint web-resource-collection web-resource-name***/web-resource-name url-pattern/*/url-pattern //or will this overwrite the index.html url-pattern/*jsp/url-pattern //should it be like this url-pattern/data/*/url-pattern url-pattern/etc/*/url-pattern //etc http-methodGET/http-method http-methodPOST/http-method /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: SSL just for a login page
And what happens with the user session ??? Every single page a verify if the user session is Ok, if not I have to redirect him to the login page. But if I do what you are saying I will lost the user session. Junior On Fri, 9 Aug 2002 09:08:22 -0500 Durham David Cntr 805CSS/SCBE [EMAIL PROTECTED] wrote: Why don't you just build your redirect after they log in. response.sendRedirect(http://; + request.getHostName() + /myApp/home.jsp); -Original Message- From: Drinkwater, GJ (Glen) [mailto:[EMAIL PROTECTED]] Sent: Friday, August 09, 2002 8:52 AM To: 'Tomcat Users List' Subject: RE: SSL just for a login page Hi I am not am expert in the security of the web at the moment. Could you explain to me why this would open such a big secuirty hole from swapping from https to https. I was suggesting this because it read this i a 'professional j2ee' book?!! The problem i have is that i need the username and password to be encrypted but i have heard that ssl hits performance quite badly!! I dont think that i could handle filtering, so what do you suggest for the security?? What is the 'norm' for these such problems. Thanks Glen. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] - Prefiro as lágrimas da derrota do que a vergonha de não ter lutado... Willan Brook - Don't E-Mail, ZipMail! http://www.zipmail.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
