Re: How do I redirect all tomcat ports to use SSL?
The below security-constraint will make Tomcat require the use of SSL. To have Tomcat automaitcally redirect for SSL, you must code redirectPort=443 as part of your port=80 connector definition in the server.xml file. Regards, Bob Feretich Subject: Re: How do I redirect all tomcat ports to use SSL? From: Fabian Pena [EMAIL PROTECTED] Date: Thu, 05 May 2005 14:20:28 -0300 To: Tomcat Users List tomcat-user@jakarta.apache.org This is an example security-constraint web-resource-collection web-resource-namesecurePages/web-resource-name url-pattern/index.jsp/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-name*/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint Fabian http://www.manentiasoftware.com Donny R Rota wrote: Thanks, I use security-constraints now, and I've been looking for this answer for weeks. I've not found that option available. Can you send me an URL to this? In the mean time, I'm going to see if I can find that option in my other sources. thanks! ...Don... -- Don Rota, CTG Operations Rational Software, IBM Software Group 20 Maguire Road, Lexington, MA 02421-3104 Tel: 781 676 2655, Fax: 781 676 7645 [EMAIL PROTECTED] Fabian Pena [EMAIL PROTECTED] 05/04/2005 04:51 PM Please respond to Tomcat Users List To Tomcat Users List tomcat-user@jakarta.apache.org cc Subject Re: How do I redirect all tomcat ports to use SSL? In a web application, you can edit your web.xml file and add a security-constraint to redirect all application requests to SSL. I Hope this help Fabian Donny R Rota wrote: This weeks puzzler 8^) I want all my Tomcat requests to go through SSL. I setup tomcat, and got port 80 and port 443 (SSL) working. But I cannot redirect port 80 to 443. I keep getting refused: Is there a way in Tomcat to redirect all port 80 requests to SSL(443)? I know you can do it the other way around 8443 - 80. I'm just running standalone Tomcat, no Apache. advTHANKSance! ...Don... -- Don Rota, CTG Operations Rational Software, IBM Software Group 20 Maguire Road, Lexington, MA 02421-3104 Tel: 781 676 2655, Fax: 781 676 7645 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving from http to https doesnt expire session
If you start a session under http, Tomcat will maintain the session into
https. This is the desired behavior for most users. Most e-commerce
sites use shopping cart models and don't switch to https until you
want to check out. If the session was changed on the transition, you
would lose the shopping cart contents just as it was time to pay. Also,
maintaining the session from http to https does not create a security
hazard.
Tomcat does not permit a session to be maintained across a https to http
transition for security reasons.
To force a session to expire when moving from http to https...
For https pages, at the top of your servlet/jsp, where request is the
HttpServletRequest object. Insert...
if (!request.isSecure() ) // not needed if page is a secure resource
{code to redirect back to the same page under https}
// get the browser's cookies
Cookie[] cookies = request.getCookies();
if (cookies==null)
{code to tell user to enable cookies}
// check session
HttpSession session = request.getSession(false);
if (session!=null) {
// Find the JSESSIONID cookie
for (int i=0; icookies.length; i++) {
if (JSESSIONID.equals(cookies[i].getName() ) ) {
if (!cookies[i].getsecure() ) {
// invalidate non-secure session
session().invalidate();
// see below Note 1.
break;
} // if cookie[]
} // if found cookie
} // for i
} // if session
session = request.getSession(true);
Note 1. At this spot in my servlet, I have code to redirect back to the
sevlet under https. It shouldn't be required, but I may have suspected
that session.invalidate() immediately followed by a
request.getSession(true) didn't work.
Hope this helps.
Bob Feretich
Subject: Moving from http to https doesnt expire session
From:Fabian Pena [EMAIL PROTECTED]
Date:Mon, 02 May 2005 09:54:29 -0300
To:tomcat-user@jakarta.apache.org
hi all
I have a simple question, at least I think that.
I am developing an applicatin that contains confidential information,
and I'm having a simple problem.
when a user move from http to https de session doesnt expire, the
jsessionid is the same.
I want generate a new session and of course change de jsessionid in the
first https request.
Any one can help me.
Thanks in advance
Fabian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session lost when switching from https to http in Tomcat 5.
Tomcat (starting with Tomcat 4) stores the JSESSIONID cookie as a secure cookie that is tagged for port 443 (or 8443) when the session begins under HTTPS. Browsers are not allowed to send secure cookies under plain HTTP, so your session is lost. For Tomcat 4 or 5 you must start your session under HTTP, then switch to HTTPS to maintain a session across both. Tomcat 3 had a config.xml option to always store JSESSIONID as non-secure. It's a long story. See the mailing list archive for the rants. In the its current state, Tomcat's implementation does not agree with published Best Practices and the *proposed* State Management standard, but the decision was made to err on the side of security. I have modified Tomcat 4 to permit sessions that span HTTP and HTTPS. The changes are not difficult, but you must implement your own mechanism to prevent session hijacking. Non-secure JSESSIONID cookies create a security hole. The committees are supposed address the security vs. state management issue in the next Servlet Spec. Regards, Bob Feretich I have a servlet/JSP application in which users establish their servlet session using https but conduct the rest of their interactions using http. The session appears not to be preserved between https and http, ie. after switching from back to http the request.getSession(false) call returns null. Can anyone shed light on this for me? Is this expected? Is there a workaround/configuration/setting in Tomcat 5 I might have missed? Thanks Anthony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Limiting number of login attempts
I did it by providing a custom JDBC realm? If you use the existing realm as a model, the changes are not that difficult. The server.xml file allows you to specify the class path of the custom realm and pass database column names for failed_login_count and last_failed_login_timestamp as parameters. I placed my custom realm in $CATALINA_HOME/shared/classes/ and everything worked OK. Note that this will make your web application Tomcat dependent. Regards, Bob Feretich Subject: Limiting number of login attempts From: Anderson, M. Paul [EMAIL PROTECTED] Date: Thu, 10 Mar 2005 12:54:41 -0500 To: Tomcat Users List tomcat-user@jakarta.apache.org Is there a way to limit the number of login attempts for a user when using a JDBC realm? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SystemThreadList.java update?
Thanks Ronald.
I made a couple mods.
I added the below to the Group fields:
Comparator threadComparitor =
new Comparator() {
public int compare(Object o1, Object o2) {
return (((Thread) o1).getName()).compareTo
(((Thread) o2).getName());
} // end compare method
};
Then I was able to sort the Thread array directly...
java.util.Arrays.sort(ta, 0, nr, threadComparitor);
I also added another tab before the printing of Thread lines so that
they appear to be contained in their ThreadGroup rather than appearing
as a peer to it.
out.println(prefix + \tT + ta[i].toString() );
Regards,
Bob Feretich
Ronald Klop wrote:
Hello,
I use the attached .jsp to view all the threads.
Ronald.
On Fri Jan 28 12:33:10 CET 2005 Tomcat Users List
tomcat-user@jakarta.apache.org wrote:
There is a June 2002 mail thread that discusses How to list all
Threads
in the JVM?. It includes a handy Java class that is supposed to return
all sorts of information on these threads.
But, the class does not seem to examine the entire ThreadGroup tree.
The constructor creates an ArrayList of ThreadGroups along a tree
branch
from the current thread to the root, but other tree branches are
ignored.
Unfortunately, the mail thread ended without any further discussion.
Is there some significance between this branch of the ThreadGroup tree
and the way Tomcat creates ThreadGroups or is this a bug in the
suggested code?
Also getThreadCount() seems to return the number of ThreadGroups in the
branch rather than the number of Threads in the JVM.
Regards,
Bob Feretich
package com.mpi.chemi.portal.util;
import java.util.ArrayList;
import java.util.List;
import org.apache.log4j.Logger;
public class SystemThreadList
{
/**
* The list of threads.
*/
private ArrayList _threads;
/**
* Constructor. Creates a list of all the
* threads running in the JVM in the system.
*/
public SystemThreadList()
{
_threads = new ArrayList();
ThreadGroup tg = Thread.currentThread().getThreadGroup();
if(tg != null)
{
_threads.add(tg);
while(tg.getParent() != null)
{
tg = tg.getParent();
if(tg != null)
{
_threads.add(tg);
}
}
}
}
/**
* Returns the thread count.
*
* @return int
*/
public int getThreadCount()
{
if(_threads == null)
return -1;
else
return _threads.size();
}
/**
* Returns the thread group at the given index.
*
* @param index
* @return ThreadGroup
*/
public ThreadGroup getThreadGroup(int index)
{
if(getThreadCount() 1)
return null;
else if((index 0) || (index (getThreadCount() - 1)))
return null;
else
return (ThreadGroup)_threads.get(index);
}
/**
* Prints out the list of threads.
*/
public void printThreads()
{
System.out.println(toString());
}
/**
* Returns a String representation of this
* SystemThreadList.
*
* @return String
*/
public String toString()
{
StringBuffer sb = new StringBuffer([SystemThreadList:\n);
if(getThreadCount() 1)
{
sb.append( No Threads );
}
else
{
for(int i = 0; i getThreadCount(); i++)
{
sb.append( ThreadGroup + i + = );
sb.append(getThreadGroup(i).toString());
sb.append(, activeCount = + getThreadGroup(i).activeCount());
sb.append(\n);
}
}
// Total active count
sb.append( totalActiveCount = + getTotalActiveCount() + \n);
sb.append( (End of SystemThreadList)]);
return sb.toString();
}
/**
* Returns the total active count: goes over
* every group in the list, and sums their activeCount()
* results.
*
* @return int
*/
public int getTotalActiveCount()
{
if(getThreadCount() 1)
return 0;
else
{
int totalActiveCount = 0;
ThreadGroup tg = null;
for(int i = 0; i getThreadCount(); i++)
{
tg = getThreadGroup(i);
totalActiveCount += tg.activeCount();
}
return totalActiveCount;
}
}
/**
* Returns the root thread group, i.e.
* the one whose parent is null.
*
* @return ThreadGroup
*/
public ThreadGroup getRootThreadGroup()
{
if(getThreadCount() 1)
return null;
else
{
ThreadGroup tg = null;
for(int i = 0; i getThreadCount(); i++)
{
tg = getThreadGroup(i);
if(tg.getParent() == null)
{
return tg;
}
}
// If we got here, we didn't find one, so return null.
return null;
}
}
/**
* Gets all the threads.
*
* @return Thread[]
*/
public Thread[] getAllThreads()
{
int estimatedCount = getTotalActiveCount();
// Start with array twice size of estimated,
// to be safe. Trim later
SystemThreadList.java update?
There is a June 2002 mail thread that discusses How to list all Threads
in the JVM?. It includes a handy Java class that is supposed to return
all sorts of information on these threads.
But, the class does not seem to examine the entire ThreadGroup tree.
The constructor creates an ArrayList of ThreadGroups along a tree branch
from the current thread to the root, but other tree branches are ignored.
Unfortunately, the mail thread ended without any further discussion.
Is there some significance between this branch of the ThreadGroup tree
and the way Tomcat creates ThreadGroups or is this a bug in the
suggested code?
Also getThreadCount() seems to return the number of ThreadGroups in the
branch rather than the number of Threads in the JVM.
Regards,
Bob Feretich
package com.mpi.chemi.portal.util;
import java.util.ArrayList;
import java.util.List;
import org.apache.log4j.Logger;
public class SystemThreadList
{
/**
* The list of threads.
*/
private ArrayList _threads;
/**
* Constructor. Creates a list of all the
* threads running in the JVM in the system.
*/
public SystemThreadList()
{
_threads = new ArrayList();
ThreadGroup tg = Thread.currentThread().getThreadGroup();
if(tg != null)
{
_threads.add(tg);
while(tg.getParent() != null)
{
tg = tg.getParent();
if(tg != null)
{
_threads.add(tg);
}
}
}
}
/**
* Returns the thread count.
*
* @return int
*/
public int getThreadCount()
{
if(_threads == null)
return -1;
else
return _threads.size();
}
/**
* Returns the thread group at the given index.
*
* @param index
* @return ThreadGroup
*/
public ThreadGroup getThreadGroup(int index)
{
if(getThreadCount() 1)
return null;
else if((index 0) || (index (getThreadCount() - 1)))
return null;
else
return (ThreadGroup)_threads.get(index);
}
/**
* Prints out the list of threads.
*/
public void printThreads()
{
System.out.println(toString());
}
/**
* Returns a String representation of this
* SystemThreadList.
*
* @return String
*/
public String toString()
{
StringBuffer sb = new StringBuffer([SystemThreadList:\n);
if(getThreadCount() 1)
{
sb.append( No Threads );
}
else
{
for(int i = 0; i getThreadCount(); i++)
{
sb.append( ThreadGroup + i + = );
sb.append(getThreadGroup(i).toString());
sb.append(, activeCount = + getThreadGroup(i).activeCount());
sb.append(\n);
}
}
// Total active count
sb.append( totalActiveCount = + getTotalActiveCount() + \n);
sb.append( (End of SystemThreadList)]);
return sb.toString();
}
/**
* Returns the total active count: goes over
* every group in the list, and sums their activeCount()
* results.
*
* @return int
*/
public int getTotalActiveCount()
{
if(getThreadCount() 1)
return 0;
else
{
int totalActiveCount = 0;
ThreadGroup tg = null;
for(int i = 0; i getThreadCount(); i++)
{
tg = getThreadGroup(i);
totalActiveCount += tg.activeCount();
}
return totalActiveCount;
}
}
/**
* Returns the root thread group, i.e.
* the one whose parent is null.
*
* @return ThreadGroup
*/
public ThreadGroup getRootThreadGroup()
{
if(getThreadCount() 1)
return null;
else
{
ThreadGroup tg = null;
for(int i = 0; i getThreadCount(); i++)
{
tg = getThreadGroup(i);
if(tg.getParent() == null)
{
return tg;
}
}
// If we got here, we didn't find one, so return null.
return null;
}
}
/**
* Gets all the threads.
*
* @return Thread[]
*/
public Thread[] getAllThreads()
{
int estimatedCount = getTotalActiveCount();
// Start with array twice size of estimated,
// to be safe. Trim later.
Thread[] estimatedThreads = new Thread[estimatedCount * 2];
// Locate root group
ThreadGroup rootGroup = getRootThreadGroup();
if(rootGroup == null)
{
return null;
}
int actualCount = rootGroup.enumerate(estimatedThreads, true);
// Check that something was returned
if(actualCount 1
Re: Rejected client certificate by the server
I was hoping someone more knowledgeable would address your question, but I didn't see a response, so I'll try. I just worked through a week of SSL hell trying to get my Tomcat Application to act as an SSL client to another server that performed client certificate authentication. I am using Tomcat 4.1.x, which does not support OpenSSL key formats. So again, there may be some difference due to that. The Java JSSE documentation distinguishes between KeyStores and TrustStores. The KeyStore contains your private key and your certificate /public key. The TrustStore contains trusted root certificates. If a certificate that is submitted to your server is chained to one of the certificates in your TrustStore, it will be accepted. The TrustStore and KeyStore may be in one physical file (keystore file). From your e-mail you do not state that Apache is brokering your Tomcat requests. If it then this answer will not apply, because Apache will be handling your SSL connection, not Tomcat. During the SSL handshake Tomcat will send your certificate/public key to the client. If the browser client does not trust your certificate (by tracing its chain back to a trusted root) it will typically pop up a window asking you whether it should be accepted or not. If client authentication is turned on, a request for the client certificate is attached to the transmission of your certificate/public key. The browser should then transmit the client certificate/client public key. When Tomcat receives it, it looks in the TrustStore (same file as its KeyStore) to see if the certificate is chained to a trusted certificate. It seems that your error message is stating that Tomcat is not finding the trusted root in its keystore file. Since your e-mail doesn't state that you imported the client certificate into your Tomcat keystore file, this is the likely cause. To fix it, import your client certificate into your Tomcat TrustStore (keystore file). Note that the J2SDK is shipped with a keystore file that contains all of the major CA roots. ($java_home/lib/security/cacerts) For production, you may need to merge your keys and certificates with the ones in this file. Also note that the Verisign certificates in many the early 1.4.x JREs have expired. Download the latest cacerts file for production. Hope this helped. Regards, Bob Feretich Subject: Rejected client certificate by the server From: Carlos Bracho [EMAIL PROTECTED] Date: Wed, 26 Jan 2005 14:49:24 -0400 To: tomcat-user@jakarta.apache.org Hello everyone. I writing you because a I have a big problem using ssl and client authenticate. I created a connector for the client connections: Connector port=9443 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 keystoreFile=C:/WINDOWS/security/server.ks keystorePass=* enableLookups=false disableUploadTimeout=true acceptCount=100 debug=0 scheme=https secure=true clientAuth=true sslProtocol=SSL / As it is for educational proposes, I created my own self-signed CA using openssl and generate a certificate request for the web server and then I signed with the self-signed CA. Then I created a client certificate and I signed with the self-signed CA, I import the self-signed CA in firefox as a certificate authority and the client certificate as a client certificate, but when I try to establish a connection I got this error message: Could not establish an encrypted connection because your certificate was rejected by agatha. Error Code -12271 (agatha is the apache server). I got a openssl manual and I saw I followed the right steps to create the CA and the client certificate, I also read that the common name of the client must match an entry in tomcat-users.xml, I created an entry with this common name and the error message still appears. When I use Internet Explorer I get a error page with this title: The page cannot be displayed I opened the stdout.log file and there is a exception repeated 5 times: NotifyUtil::java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(Unknown Source) at java.net.PlainSocketImpl.connectToAddress(Unknown Source) at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at sun.net.NetworkClient.doConnect(Unknown Source) at sun.net.www.http.HttpClient.openServer(Unknown Source) at sun.net.www.http.HttpClient.openServer(Unknown Source) at sun.net.www.http.HttpClient.init(Unknown Source) at sun.net.www.http.HttpClient.init(Unknown Source) at sun.net.www.http.HttpClient.New(Unknown Source) at sun.net.www.http.HttpClient.New(Unknown Source) at sun.net.www.http.HttpClient.New(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source
Re: extend JDBCRealm?
I extended it and placed the class com.xxx.realm.classname in the server/classes folder for Tomcat 4.1.24. It's working, but I don't use any of the class methods in my application. And you need to name the class in server.xml as Pandu states. Host ... Context... Realm className=com.xxx.realm.classname ... Regards, Bob Feretich Yes it is. You will have to change the name in server.xml file also to your class name. Also the class/jar file should be placed in the common folder since tomcat needs access to it. Pandu From: Ilja Smoli [EMAIL PROTECTED] Reply-To: Tomcat Users List tomcat-user@jakarta.apache.org To: tomcat-user@jakarta.apache.org Subject: extend JDBCRealm? Date: Mon, 27 Dec 2004 13:49:23 +0200 Hi Question is: is it possible to extend org.apache.catalina.realm.JDBCRealm and override method authenticate(String username, String credentials)? And if it is possible (i guess it is), where to put it and etc... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SSL encryption
A general solution for this will probably not be available until/unless rfc-2965 is approved. There is currently no standard that states the scope of a session as related to protocol or port. The servlet working group delayed clarifying this until Java Servlet Spec 2.5. Best practice rfc-2964 states that you should write as if a session scope can span accesses in different protocols and ports (state management and authentication are independent). Tomcat disabled the ability to have sessions span protocols (http/https) in Tomcat 4. Tomcat 3 had a server configuration flag that controlled it. It is not just a Tomcat problem. IE and Netscape/Firefox have come down on different sides of the issue in the way they permit cookie access. The easy work around is to require your users to use IE, have cookies enabled and initiate all sessions on a non-secure page (using http). That way your JSESSIONID cookie is stored as non secure. This seemed to work on Tomcat 4. If you set these requirements you need to modify Tomcat AuthenticatorBase SSL redirection and the HttpResponse URL rewriting methods. Tomcat 5 seems to have rewritten these classes, so I don't know the precise changes. You will probably have to install a http sniffer to see what Tomcat and the browser are doing and make changes until Tomcat performs the way you need it to. If you make JSESSIONID cookies non secure, then your application is exposed to hijacking. You should also implement a security mechanism to provide hijack protection. Regards, Bob Feretich Hi all. I would like to encrypt my login process so that login and password are not visible on the network. That's why I defined a SSL connector on port 8443 in my server.xml. My problem is that after the user logged in, request keep on using the https protocol on port 8443. Does someone know how to encrypt only the login process and afterwards use the http protocol again, on port 8080 ? Thanks. Fred. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat lost request parameters
I don't think that this will help much, but your problem seems like a multi-threading problem rather than a lost request parameter problem. Have you tried inserting in some debug code to write request parameters to the log from the first servlet that receives them? Regards, Bob Feretich Original message - Subject: Tomcat lost request parameters From: Roberto Rios [EMAIL PROTECTED] Date: Wed, 22 Dec 2004 18:51:16 -0200 To: [EMAIL PROTECTED] Hi, I know that my subject sounds crazy, but I'm going nuts... I have an application, 100% java (jsp 1.2 and servlet 2.3). This application has more or less 1,5 years. So it is stable. I always used tomcat as my web server (without apache because I don't have static html to be served) with no problem. We are using TC 4.1.31, with J2SDK1.4.2_03 on a W2K/SP4 box (Xeon 3.0Ghz with 2GB mem). At this time we had more or less 25 concurrent users. We were happy... Recently, another department in company started to use the application. So now we have more or less 100 concurrent users. Since then the problems began raising. Most of then when we try to insert/update data in database. Generally we receive errors telling that we tried to insert null values into a not null field (BTW we are using oracle 8.1.7 with JDBC - classes12.jar). My point is that application was working. Nothing changed (except the number of users). So, I'm sure that the fields are being properly filled. What I would like to ask you, is if someone has experienced this kind of problem. I was wondering if tomcat could lost request parameters under heavy traffic... I don't have any prove that it actually lost something. As I said, I'm just wondering. Maybe the JDBC... Searching into the mailing list archive, I found a thread about performance. I have changed the connector maxProcessors to 150 and also add maxKeepAliveRequests=1 to it after reading it. Nothing change. Does someone has some advice? I know that my posting is vague, but I don't where to look anymore... I was thinking about to do a tomcat upgrade (to 5.0.X). TIA, Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] HTTP Sniffers
I use Ethereal on my Windows client. It works well, but only for communication across a real port. It does not work if your accessing a site that is running on the client computer. The Follow TCP Stream tool assembles the entire request/response communication for easy viewing or saving to disk. Regards, Bob Feretich On Wed, 2004-12-15 at 15:17, Didier McGillis wrote: Considering this is a pretty knowledgable group is there a good free HTTP Sniffer application I can use, I need to see what the HTTP headers are returning on my site. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Form Authentication Trouble with Firefox
I experienced as problem that might be similar to yours. I was testing with Netsacpe 7 (Mozilla based like Foxfire) and IE. My form authentication worked with IE, but not Netscape. It occurred quite a while ago (using Tomcat 4.1.x), so I am not clear on the exact details. My debug showed that Netscape was not handling the session cookies the same way as IE. I think that Netscape only returned non-secure cookies via a non-secure port (80 for me). 1) I would start a session on a non-protected page (http - port 80). 2) The user would select a link to a protected page. 3) Control would be passed to my login form (https - port 443), but the non-secure jsessionid cookie would not be received, so Tomcat would start a new session and store a secure jsessionid cookie. I think this is a bug in both the Mozilla and Tomcat. Netscape should return a cookie stored by port 80 cookie on port 443 as long as the stored cookie is not designated for port 80 only. Tomcat should follow RFC-2964 Use of HTTP State Management and never be mark session tracking cookies secure. We may have to wait for RFC-2965 to be adopted before all this gets fixed. If this is your problem, you can either run your whole application under https or zap the Tomcat AuthenticatorBase code. I think I changed it to: 1) append ;jsessionid=... to URLs when they are redirected to the https port. 2) remove the addition of the redirectPort to that same URL. Regards, Bob Feretich Peter Neu wrote: Hello everybody, I'm using form authentication to log on the users to my website. Until now I was using Mozilla Firefox for developement but now I came across this problem that Firefox doesn't allow a clean log in and always redirects to the error.jsp. The authentication is correct because it works with the IE. Does anyone have this problem, too ? If not this means I can't serve any Firfox clients. Regards, Peter - 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: Form Authentication Trouble with Firefox
I have not examined Tomcat 5. My hosting provider doen't support it, yet.
For Tomcat 4.1.21 (and may be the same for Tomcat 5):
1) Download the source tree from the jakarta.apache.org site.
2) AuthenticatorBase can be found at
catalina/src/share/org/apache/catalina/authenticator/
3) After you make your changes and compile, place the resulting classes
in the server/classes/org/apache/catalina/authenticator/ directory of
the Tomcat binary you are using. (The server directory is a peer to the
conf directory, where your server.xml file resides.)
4) I made these changes (you will probably have to modify them for Tomcat5):
protected boolean checkUserData(
...
// RF changes because Netscape will not return cookies from non secure
// if ((requestedSessionId != null)
// hrequest.isRequestedSessionIdFromURL()) {
if ((requestedSessionId != null) ) { // replaces above two lines
file.append(;jsessionid=);
file.append(requestedSessionId);
}
String queryString = hrequest.getQueryString();
if (queryString != null) {
file.append('?');
file.append(queryString);
}
URL url = null;
try {
// url = new URL(protocol, host, redirectPort, file.toString());
url = new URL(protocol, host, file.toString()); // replace above
...
Good luck,
Bob Feretich
Peter Neu wrote:
Hi Bob,
I can't switch to https in this case (not a technical problem). So where
do I have to apply the changes
you suggested in my Tomcat 5.0.28 ? Where can I find the
AuthenticatorBase code? And what do I have to change?
Regards,
Swen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpSession creation: When How]
When Tomcat intercepts an access to a protected resource and redirects to your login form, it saves your initial request by attaching it to the session object. If the login is successful, it retrieves the saved request and redirects to it. If you don't have an active session, it creates one to perform the save. The basic HttpSession object is for state management, not evidence of authentication (see best practice RFC-2964 2.2.2). (You may attach authentication info to the session object.) Regards, Bob Feretich Dennis Payne wrote: You can use the session.invalidate() if you need to before creating a new session (I did not use this approach). With my system, if the session exists we check for required elements and place them there if they are missing. Every thirty minutes the session automatically invalidates. At that point we create a new session and simply repeat the check for required elements. All of this is invisible to the user who logs in only once. The only information that stays from session to session is data that is persisted in (written to) the database and put in the session for servlet/JSP use. If I understand correctly the HTTP Session is initiated by the web server when authentication takes place (I only have experience with basic authentication). Other wiser sources may clarify... [EMAIL PROTECTED] 11-29-2004 17:31 Good evening. My question is about HttpSession objects creation and destruction within a Servlet/JSP container. I'm using the JBoss/Tomcat bundle (versions 3.2.3/4.1.29) with a database realm properly configured. Here's how things work so far: 1. User goes to a predefined Welcome File (index.html) 2. Within the welcome file there's a link to a protected resource (wich happens to be the application's main screen) 3. The user clicks the link and the login page appears. 4. The user enters login/password and logs on successfully or is redirected to an error page. Up to this point everything works fine, but the thing that I don't understand is that the moment the user clicks the link that points to a protected resource an HttpSession object is created by the server even though the user hasn't been authenticated. This behavior kinda ruin my plans because I have a Session Creation/Destruction Listener that is supposed to detect a session creation event in order to be able to place some things (objects) in that user session, but it seems that the created session for the unauthenticated is recycled after authentication and my session lifecycle listener is no longer useful (the session already exists) I've looked into the Servlet spec but couldn't find anything clarifying enough... I'f anyone has any comments, tips, thoughts on this issue I'd like to hear'em... :^) Regards, Carlos... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat session continuation from https to http
The Tomcat code distinguishes between http and https accesses, with respect to session continuation. Specifically, when HttpServeletResponse.encodeRedirectURL(} or HttpServeletResponse.encodeURL() are called for URL rewriting (client has cookies turned off), if the current servlet is accessed via https and the new URL is accessed via http (or visa versa) HttpResponseBase.isEncodeable(} determines that the sessionId should not be appended to the URL, causing session continuity to be lost. Why? My web application has mostly non-secure pages, but some pages need SSL security. I would like to avoid the SSL overhead on non-secure pages. However, my client sessions must span access to both types of pages. How am I to do this with Tomcat? (The latest level of Tomcat my hosting service supports is Tomcat 4.1.24.) I have noticed, that with cookies turned on, there is no problem maintaining the session. Regards, Bob Feretich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
