Turning off jsessionid on URL?
Is there a configuration parameter to ONLY send the jsessionid by cookie, not on the URL bar? Picture this, user goes to your site http://www.yoursite.com/yourapp yoursite redirects to the menu page, which gives a jsessionid. That page is under an auth-constraint and requires login, so you get displayed the login page, but the URL you've been redirected to includes the jsessionid - like: http://www.yoursite.com/yourapp/Menu.do;jessionid=D2DC09EB64CBC7690BCEA68CA484B4C3 User wants to share the site with their friends, so they copy/paste from the URL bar. Then they log in - their session is now logged in, AND they have the same session ID. And yes, this does work - I'm able to copy/paste between different browsers (exploder and firefox) and the session works fine. Is there a way to turn that feature off? w - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Turning off jsessionid on URL?
I only sent the message once. I apologize for any inconvenience, but I wonder if gmail and/or ezmlm are having issues today - I've received the welcome message from ezmlm four times now. w On 7/7/05, Tim Funk [EMAIL PROTECTED] wrote: Please stop posting the same question 4 times and please wait for a response. The answer to the question below is no. There is no switch. To not use URL rewriting, do not utilize the method HttpServletResponse.encodeURL(). Of course - this requires a code rewrite. The easier solution is to implement a servlet filter which creates a HttpServletResponseWrapper which overrides encodeURL and encodeRedirectURL -Tim William Stranathan wrote: Is there a configuration parameter to ONLY send the jsessionid by cookie, not on the URL bar? Picture this, user goes to your site http://www.yoursite.com/yourapp yoursite redirects to the menu page, which gives a jsessionid. That page is under an auth-constraint and requires login, so you get displayed the login page, but the URL you've been redirected to includes the jsessionid - like: http://www.yoursite.com/yourapp/Menu.do;jessionid=D2DC09EB64CBC7690BCEA68CA484B4C3 User wants to share the site with their friends, so they copy/paste from the URL bar. Then they log in - their session is now logged in, AND they have the same session ID. And yes, this does work - I'm able to copy/paste between different browsers (exploder and firefox) and the session works fine. Is there a way to turn that feature off? - 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]
New Session on Authentication?
Is there a configuration setting to force Tomcat to expire the old session and put the user in a new one when they log in using any of the Realm's? For example, this is a problem: - User tries to access a restricted page - no session set up - Tomcat redirects to the login page, appends ;jsessionid=id to the URL - User successfully authenticates Now, a URL with a valid session ID is in the user's history, might be logged, and an unknowing user could copy/paste that URL to somebody say in a newsgroup or something. I'm using mod-rewrite on an Apache server in front of Tomcat to fix the jsessionid going in the URL, but is there any way to force Tomcat to make a new session upon authentication? I know that this is not always desirable - a user may have preferences in their session before they authenticate, so I think it should be optional. Thanks for any help. Will Stranathn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JNDI Realm Issue with 5.5.7
I haven't tried this out myself, but here are several possibilities: 1) Does /main/index.jsp exist? That's where your servlet points to 2) There doesn't appear to be a welcome-file configured - depending on what URL you're using, it may be that it's looking for a welcome file, but since there's not one configured, it can't be found. This doesn't APPEAR to be a JNDI issue. Have you tried this configuration WITHOUT the security-constraint yet to eliminate AAA as the cause of the issues? w On Fri, 25 Mar 2005 20:17:19 -0800 (PST), Ole Ersoy [EMAIL PROTECTED] wrote: I think I must be missing something obvious in the configuration files, because I get the login error page when entering non user information, and when I type in the correct username and password, tomcat gives me this: HTTP Status 403 - Access to the requested resource has been denied - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to trap errors while authenticating user : Custon Authentication mechanism ?
Besides, giving to the USER a different authentication failure message
is a bad idea - hackers use that information to know which accounts to
try to hack.
On the other hand, though, custom handling of the error would be nice
- the LDAP servers I use disconnect silently without traffic for some
amount of time, but there's no way for me to trap that error - it just
appears as an authentication failure to the user, and they have to try
to authenticate again so Tomcat can establish a new connection.
w
On Mon, 21 Mar 2005 13:27:50 -0900, Erik Fiegel
[EMAIL PROTECTED] wrote:
That seems like overkill. Did you try turning up the debug level of
your Realm?
Realm className=org.apache.catalina.realm.JNDIRealm
debug=9
connectionURL=ldap://localhost:389;
userBase=ou=people,dc=mycompany,dc=com
userSearch=(mail={0})
userRoleName=memberOf
roleBase=ou=groups,dc=mycompany,dc=com
roleName=cn
roleSearch=(uniqueMember={0})
/
- Erik
[EMAIL PROTECTED] wrote:
Hello,
I'm trying to use a Novell LDAP server, and let it manage the Passwords
instead of my webapp. Unfortunately I've found that the JNDIRealm doesn't
tell me the reason of the failure when authenticating a user.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: image upload
Use javax.imageio.ImageIO to read the image from an input stream - you get back a BufferedImage from which you can determine the dimensions. w On Tue, 22 Mar 2005 08:57:36 -0500, Shannon Scott [EMAIL PROTECTED] wrote: Thank you for pointing me to the JCFU. I plan to use it for uploading images. I could not find a method that would allow me to determine or control pixel dimensions for uploaded images ( only file size ). How do others filter images based on actual image size ( pixel dimensions ). Thank you again. S - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
LDAP Realm Issues
I apologize for posting this again - I just didn't hear anything (a lot of sprited discussions going on at the time) and wanted to give this one more shot here before sending to the developer list. I opened a bug on this a couple of weeks ago, but it hasn't been touched. Maybe other folks have seen this behavior... I'm using the LDAP realm for AAA in my application. However, the LDAP server it connects to drops stale sessions after a pretty short time. Evidently, Tomcat tries to keep connections open so it doesn't have to connect later on. Unfortunately, this causes authentication failures because the host it wants to connect with is no longer there (er...the connection isn't, anyhow). After one failure, Tomcat drops the connection, the user tries again, and gets in. But 5 minutes later, the next user will have to try again. Here's the stack trace that get's logged: 2005-03-11 08:33:47 JNDIRealm[/iso]: Searching for billybob 2005-03-11 08:33:47 JNDIRealm[/iso]: base: ou=users,dc=mycompany,dc=com filter: ((objectClass=appUser)(uid=billybob)) 2005-03-11 08:33:47 JNDIRealm[/iso]: Exception performing authentication javax.naming.CommunicationException: Request: 7 cancelled; remaining name 'ou=users,dc=mycompany,dc=com' at com.sun.jndi.ldap.LdapRequest.getReplyBer(LdapRequest.java:60) at com.sun.jndi.ldap.Connection.readReply(Connection.java:405) at com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:611) at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:534) at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1944) at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1806) at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1731) at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:368) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:338) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:321) at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:248) at org.apache.catalina.realm.JNDIRealm.getUserBySearch(JNDIRealm.java:1074) at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:967) at org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:916) at org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:809) at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:235) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:446) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.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(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.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(StandardValveContext.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.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:300) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:374) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:675) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) 2005-03-11 08:33:47 JNDIRealm[/iso]: Closing directory context Any magic undocumented setting that will work around this? Thanks, Will - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
LDAP Realm issues
I opened a bug on this a couple of weeks ago, but it hasn't been touched. Maybe other folks have seen this behavior... I'm using the LDAP realm for AAA in my application. However, the LDAP server it connects to drops stale sessions after a pretty short time. Evidently, Tomcat tries to keep connections open so it doesn't have to connect later on. Unfortunately, this causes authentication failures because the host it wants to connect with is no longer there (er...the connection isn't, anyhow). After one failure, Tomcat drops the connection, the user tries again, and gets in. But 5 minutes later, the next user will have to try again. Here's the stack trace that get's logged: 2005-03-11 08:33:47 JNDIRealm[/iso]: Searching for billybob 2005-03-11 08:33:47 JNDIRealm[/iso]: base: ou=users,dc=mycompany,dc=com filter: ((objectClass=appUser)(uid=billybob)) 2005-03-11 08:33:47 JNDIRealm[/iso]: Exception performing authentication javax.naming.CommunicationException: Request: 7 cancelled; remaining name 'ou=users,dc=mycompany,dc=com' at com.sun.jndi.ldap.LdapRequest.getReplyBer(LdapRequest.java:60) at com.sun.jndi.ldap.Connection.readReply(Connection.java:405) at com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:611) at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:534) at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1944) at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1806) at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1731) at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:368) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:338) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:321) at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:248) at org.apache.catalina.realm.JNDIRealm.getUserBySearch(JNDIRealm.java:1074) at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:967) at org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:916) at org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:809) at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:235) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:446) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.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(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.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(StandardValveContext.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.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:300) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:374) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:675) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) 2005-03-11 08:33:47 JNDIRealm[/iso]: Closing directory context Any magic undocumented setting that will work around this? Thanks, Will - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat freezes when accessing db after several queries
Also, make sure you have a finally block that always closes the
connection so the connection is returned to the pool.
Will Stranathan
On Mon, 14 Mar 2005 15:27:29 -0700, George Sexton
[EMAIL PROTECTED] wrote:
Look for something like this:
Try {
statement.execUupdate(some statement);
} catch (SQLException se){
}
Make sure that the catch has:
conn.rollback();
-Original Message-
From: Larry Johnson [mailto:[EMAIL PROTECTED]
Subject: tomcat freezes when accessing db after several queries
Hi all,
I've encountered a rather strange error that I need some help
getting to the bottom of. Recently I lost the hard drive on
one of my tomcat
application servers. I've since reinstalled and set everything on the
effected machine to mirror the configuration of my other app
servers (which
are working fine). However, now when I access the webapp on
this server
tomcat seems to freeze (like it's waiting for something) after several
queries to the database are executed. After this happens I am
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
