RE: Tomcat started and localhost:8080 is loading
I have the same issues. Everything worked fine with Tomcat 4.1 but since Tomcat 7.0 not. I checked all below. Nothing, yet when you look at Tomcat's listening connection log file, there is communication with Tomcat, but no page is displayed. Philip Coetzee -Technical Manager, Southern African Region Oberthur Technologies, South Africa (Pty) Ltd 10 Cleveland Rd., Cleveland Johannesburg. South Africa Cell: +27 82 870 5904 l +27 11 622-0400 l Fax: +27 11 622-5874 email: p.coet...@oberthur.com - www.oberthur.com -Original Message- From: beau.hutche...@thomsonreuters.com [mailto:beau.hutche...@thomsonreuters.com] Sent: 15 September 2011 08:40 PM To: users@tomcat.apache.org Subject: RE: Tomcat started and localhost:8080 is loading I had some issues regarding Eclipse and Tomcat. Try setting the IP address for your tomcat to 127.0.0.1 Access it from your browser by the same ip and your port and you should be able to load the tomcat welcome page. --b -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Monday, August 29, 2011 5:17 PM To: Tomcat Users List Subject: Re: Tomcat started and localhost:8080 is loading Hi. At the beginning, you said : When I start startup.sh, I can load the localhost:8080 page. But when I start Tomcat from Eclipse, it is able to start but I'm unable to load the localhost page. Explorer says, could not connect to localhost:8080. That seems to indicate that Tomcat is not listening on port 8080, when you start it from Eclipse. I am not an Eclipse user, but from similar previous posts on this list, that seems to indicate that Eclipse is using another set of configuration files for Tomcat, than the ones that are used when you start Tomcat from startup.sh. You did not say on which platform you are running this, but try the following to confirm : A) 1) start Tomcat with startup.sh 2) in a command window, enter netstat -pan (Linux) or netstat -aopn (Windows), and look for lines containing the word LISTEN. You should see a line containing the port :8080. That is Tomcat, and its PID is at the end of the same line. 3) stop Tomcat B) 1) start Tomcat with Eclipse 2) in a command window, enter netstat -pan (Linux) or netstat -aopn (Windows), and look for lines containing the word LISTEN. Do you see a line containing the port :8080 ? If not, and you see for instance a line with port :80 instead, then it means that Tomcat is started differently. (And try http://localhost:80;) If so, search the archives of this list as to how to correct that issue. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat started and localhost:8080 is loading
Guys, if you want help, you are going to have to make an effort and be a bit systematic in your answers. Phrases like it does'nt work and there is communication with Tomcat don't help, because they don't really mean anything to someone trying to help you. So could you, for example, go through the checklist A B which I indicated at the end, item by item, and tell us what you do, and what happens (precisely) at each step. Do not be afraid to cut-and-paste what you see on the screen at each step. Do not interpret if you are not sure, give us facts. If you mention a message in the logfile, paste the real message here, not what you think it means. Do not send files or screenshots as attachments, the list strips them. Do not be afraid to repeat which versions of Tomcat and Java you are using, on which platform, and if your browser is running on the same host as Tomcat or not. It all saves time. Thanks. COETZEE Philip wrote: I have the same issues. Everything worked fine with Tomcat 4.1 but since Tomcat 7.0 not. I checked all below. Nothing, yet when you look at Tomcat's listening connection log file, there is communication with Tomcat, but no page is displayed. Philip Coetzee -Technical Manager, Southern African Region Oberthur Technologies, South Africa (Pty) Ltd 10 Cleveland Rd., Cleveland Johannesburg. South Africa Cell: +27 82 870 5904 l +27 11 622-0400 l Fax: +27 11 622-5874 email: p.coet...@oberthur.com - www.oberthur.com -Original Message- From: beau.hutche...@thomsonreuters.com [mailto:beau.hutche...@thomsonreuters.com] Sent: 15 September 2011 08:40 PM To: users@tomcat.apache.org Subject: RE: Tomcat started and localhost:8080 is loading I had some issues regarding Eclipse and Tomcat. Try setting the IP address for your tomcat to 127.0.0.1 Access it from your browser by the same ip and your port and you should be able to load the tomcat welcome page. --b -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Monday, August 29, 2011 5:17 PM To: Tomcat Users List Subject: Re: Tomcat started and localhost:8080 is loading Hi. At the beginning, you said : When I start startup.sh, I can load the localhost:8080 page. But when I start Tomcat from Eclipse, it is able to start but I'm unable to load the localhost page. Explorer says, could not connect to localhost:8080. That seems to indicate that Tomcat is not listening on port 8080, when you start it from Eclipse. I am not an Eclipse user, but from similar previous posts on this list, that seems to indicate that Eclipse is using another set of configuration files for Tomcat, than the ones that are used when you start Tomcat from startup.sh. You did not say on which platform you are running this, but try the following to confirm : A) 1) start Tomcat with startup.sh 2) in a command window, enter netstat -pan (Linux) or netstat -aopn (Windows), and look for lines containing the word LISTEN. You should see a line containing the port :8080. That is Tomcat, and its PID is at the end of the same line. 3) stop Tomcat B) 1) start Tomcat with Eclipse 2) in a command window, enter netstat -pan (Linux) or netstat -aopn (Windows), and look for lines containing the word LISTEN. Do you see a line containing the port :8080 ? If not, and you see for instance a line with port :80 instead, then it means that Tomcat is started differently. (And try http://localhost:80;) If so, search the archives of this list as to how to correct that issue. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Http connector and remote user information
Hi everyone, I'm actually using Tomcat on my environment platform (Tomcat 5.5 / Tomcat 6 and soon Tomcat 7). I have a frontend Apache http Server using the jk connector to communicate with Tomcat instance. I'd like to change this connector and use the mod_proxy one for several reasons. The main difficulty to handle is relative to the remote-user information. Indeed the jk connector automatically transmits the information so that the application can retrieve it using a request.getRemoteUser() method call. If i'm not using the ajp connector anymore, i need to handle something on the tomcat side to set the remote user in the request object. I thought i could use a valve to do this. And that's where the road ends, i have watched the ajp conenctor code in order to see how the remote user is set in the request but i can't find it. Could you please tell me how i can do this ? Best regards. Sylvain
Re: Http connector and remote user information
Sylvain Goulmy wrote: Hi everyone, I'm actually using Tomcat on my environment platform (Tomcat 5.5 / Tomcat 6 and soon Tomcat 7). I have a frontend Apache http Server using the jk connector to communicate with Tomcat instance. I'd like to change this connector and use the mod_proxy one for several reasons. The main difficulty to handle is relative to the remote-user information. Indeed the jk connector automatically transmits the information so that the application can retrieve it using a request.getRemoteUser() method call. If i'm not using the ajp connector anymore, i need to handle something on the tomcat side to set the remote user in the request object. I thought i could use a valve to do this. And that's where the road ends, i have watched the ajp conenctor code in order to see how the remote user is set in the request but i can't find it. You are not finding it, because you are looking in the wrong place. If mod_jk can pass the authenticated user to Tomcat, via the AJP channel, it is because the user (or request) has been authenticated on the Apache side, before the request is forwarded through mod_jk to Tomcat. The AJP connector on the Tomcat side then picks up this user-id from the request coming in on the AJP channel, and sets the UserPrincipal in Tomcat accordingly. That's why a subsequent getRemoteUser() can pick it up in Tomcat. If you want to switch to mod_proxy instead of mod_jk, the question is : can mod_proxy forward the Apache user-id to Tomcat ? The question is slightly more complicated, because there are two methods of connecting Apache to Tomcat using mod_proxy : a) mod_proxy_http (protocol = HTTP, over Tomcat HTTP Connector) b) mod_proxy_ajp (protocol = AJP, over Tomcat's AJP Connector (the same as the one used with mod_jk) If you are using the second one (AJP), then we know that the AJP protocol /can/ carry the Apache user-id to Tomcat (because that is what mod_jk does). The question is whether mod_proxy_ajp has some setting to tell it to do that (or does it by default). If you are using the first one (HTTP), then one way would be to force Apache to add a HTTP header to the request, containing the user-id; and on the Tomcat side, have something that picks up this HTTP header, and stuffs its content in the UserPrincipal object. I don't know if something like that exists ready-made, but a custom Valve or servlet filter should be able to do that. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Example to logout on Tomcat 7 and SSL + Realm
Hello: Ive got a web application running on Tomcat 7, with SSL (https) and realm for authentication/authorization When I invalidate() a session ( session.invalidate() ) , Tomcat doesn't know it and thinks that user is still logged in So, that user can get protected pages. Tomcat should return him a login window but doesn't If Tomcat doesn't use SSL , works fine, so I guess I'm not ending sessions properly with SSL activated Any example about how do it ? Anyone did it ? Thanks and regards - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Example to logout on Tomcat 7 and SSL + Realm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chema, On 9/16/2011 7:37 AM, Chema wrote: Ive got a web application running on Tomcat 7, with SSL (https) and realm for authentication/authorization Presumably, you are using CLIENT-CERT as your auth-method? When I invalidate() a session ( session.invalidate() ) , Tomcat doesn't know it and thinks that user is still logged in So, that user can get protected pages. Tomcat should return him a login window but doesn't. Why do you think that HttpSession.invalidate() should act as a log out mechanism when using CLIENT-CERT authentication? If Tomcat doesn't use SSL , works fine, so I guess I'm not ending sessions properly with SSL activated. SSL session != HttpSession You need to terminate the SSL session. See a separate thread SSLSession invalidate for a discussion about how this is (not) working. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5zg3IACgkQ9CaO5/Lv0PDZbQCff4qRtUf6fbOeJwDByeiDYyC7 GqsAnRY74JnQqgvzoyI/0MPJZOCFzOcu =+ytG -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Example to logout on Tomcat 7 and SSL + Realm
Presumably, you are using CLIENT-CERT as your auth-method? Not , FORM method When I invalidate() a session ( session.invalidate() ) , Tomcat doesn't know it and thinks that user is still logged in So, that user can get protected pages. Tomcat should return him a login window but doesn't. SSL session != HttpSession You need to terminate the SSL session. See a separate thread SSLSession invalidate for a discussion about how this is (not) working. Well, I don't know what I have to terminate I only want to know what do to inform Tomcat that an user logs out ( user clicks a Logout button ) I tried to invalidate SSL session with this code session.invalidate(); org.apache.tomcat.util.net.SSLSessionManager mgr =(org.apache.tomcat.util.net.SSLSessionManager)request.getAttribute(javax.servlet.request.ssl_session_mgr); mgr.invalidateSession(); response.setHeader(Connection, close); but didnt work. does anyone have worked with realm + SSL ? anyone ? Thanks and regards - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Availability of Apache Tomcat 6.0.34?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shanti, On 9/15/2011 4:21 AM, Yajnik, Shanti wrote: Does anyone know when the fix for the specific vulnerability: CVE-2011-3190 will be available for the 6.0.33 version of Apache Tomcat? The Tomcat team does not release binary patches, so there will never be a fix available for 6.0.33. Instead, you will either have to wait for 6.0.34 to become available, or download the source code from subversion and compile it yourself. If you want to create your own 6.0.33 + fix-for-CVE-2011-3190, you'll need to get the 6.0.33 tag and then manually merge-in the relevant commits for that bug, then recompile everything. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5ziAIACgkQ9CaO5/Lv0PCK+QCdEUvoqK1oPOY0ZsX42AsWAuL5 eR0AoKhm2/vul13vjQ60w/Vyyf6nmw85 =gInY -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Clustering / High Availability edge cases?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 9/15/2011 3:17 AM, Mark Thomas wrote: On 14/09/2011 23:03, Christopher Schultz wrote: John, On 9/13/2011 5:51 AM, John Bass wrote: In the event of a node failure, I'm assuming that there's no way to recover from that and the failure will be visible to a client application. Correct: no other node in the cluster can serve the response being generated by a dying Tomcat instance. As Pid points out, this isn't unique to Tomcat. Wrong. See my longer response. To pick a nit, the dying Tomcat dies. No other server can send it's response. Instead, your load-balancer can retry the request on another server. That's not the same thing -- especially when OP is talking about long-running requests. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5ziGMACgkQ9CaO5/Lv0PBvCgCcDKrLZwF2mZI7VnAA4mLDLYEC S0AAoIf96gjZdnesKzor34CtG1QZhwRU =eaLo -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Example to logout on Tomcat 7 and SSL + Realm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chema, On 9/16/2011 1:25 PM, Chema wrote: Presumably, you are using CLIENT-CERT as your auth-method? No, [I am using] FORM method Hmm. HttpSession.invalidate() *is* the proper way to terminate a FORM authentication login. session.invalidate(); org.apache.tomcat.util.net.SSLSessionManager mgr =(org.apache.tomcat.util.net.SSLSessionManager)request.getAttribute(javax.servlet.request.ssl_session_mgr); mgr.invalidateSession(); You don't need this SSL stuff. HttpSession.invalidate() ought to do the trick. response.setHeader(Connection, close); This is optional, and not usually necessary. but didnt work. does anyone have worked with realm + SSL ? anyone ? This definitely works. Are you saying that when you use HTTP instead of HTTPS, logouts work? That sounds really strange. Please post the relevant sections of web.xml and server.xml, and be sure to remove any sensitive information. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5ziX4ACgkQ9CaO5/Lv0PCitQCgwgv0Khtvabe0xJK0A5SYe0u0 BlAAnRno9V/PAwyRKIs1s4cC/2oFz0GK =pshV -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Example to logout on Tomcat 7 and SSL + Realm
Chris, Christopher Schultz wrote: ... Why do you think that HttpSession.invalidate() should act as a log out mechanism when using CLIENT-CERT authentication? I guess that where the OP (and I) get a little confused is in the distinction between the state of having a session and being logged-in, and maybe the sequence in which these things happen. But we are willing to be educated (or at least I am) (and the other thread you mention is not really very explcit in that respect). So let's say 1) a browser sends a first request to Tomcat, and this happens to be directed to an application which requires authentication (container-driven). 2) Tomcat intercepts the request (because of the authentication requirement), sends back something to the browser which tells the browser (or the user) to supply credentials. 3) the browser (or the user) supplies the credentials along with a subsequent request 4) Tomcat intercepts this again, verifies the credentials, and if they fit, allows the request (now authenticated) to proceed to the application which had been requested in the first place. (and I know that there is some variety in the above, depending on the type of authentication, but roughly that's it, no ?) 5) then the request hits the application, and it is the application which decides if a session is created or not. Yes ? And if it decides so, this creates some storage place for this session thing, and makes it so that a cookie will later be sent back to the browser, with an id pointing to this session storage thing, so that a subsequent request which provides this cookie, allows the application to retrieve the saved session and its contents prior to handling the next request. Now what is maybe less clear, is whether the session thing which was created, contains or not the authentication data. And if yes : a session invalidate should delete the session thing (and the contained authentication info), and this should have the effect that when the browser sends a subsequent request, it will find a no session yet situation. Obviously though, no session does not necessarily mean not authenticated, but this is I believe where the OP (and I) are getting confused. Can you enlighten us ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Availability of Tomcat 5.5.34
I am TRing 5.5.34 today... - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Example to logout on Tomcat 7 and SSL + Realm
Here goes web.xml and servlet.xml I will note that server.xml contains SingleSignOn because I've got two applications which share logging ?xml version=1.0 encoding=UTF-8? web-app !-- Authentication -- servlet servlet-nameLoginServlet/servlet-name servlet-classcom.server.servlet.LoginServlet/servlet-class /servlet servlet-mapping servlet-nameLoginServlet/servlet-name url-pattern/login.do/url-pattern /servlet-mapping servlet servlet-nameLogoutServlet/servlet-name servlet-classcom.server.servlet.LogoutServlet/servlet-class /servlet servlet-mapping servlet-nameLogoutServlet/servlet-name url-pattern/logout.do/url-pattern /servlet-mapping !-- Default page to serve -- welcome-file-list welcome-fileindex.jsp/welcome-file /welcome-file-list security-role role-nameadmin/role-name /security-role security-constraint web-resource-collection web-resource-namessl/web-resource-name url-pattern/*/url-pattern /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint security-constraint web-resource-collection web-resource-nameadmin/web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-nameadmin/role-name /auth-constraint /security-constraint login-config auth-methodFORM/auth-method realm-namerealm/realm-name form-login-config form-login-page/login.do/form-login-page form-error-page/error.do/form-error-page /form-login-config /login-config /web-app *** Connector connectionTimeout=2 port=8080 protocol=HTTP/1.1 redirectPort=8443/ Connector SSLEnabled=true clientAuth=false keystoreFile=C:\keystore.jks keystorePass=tomcat maxThreads=150 port=8443 protocol=HTTP/1.1 scheme=https secure=true sslProtocol=TLS/ !-- Define an AJP 1.3 Connector on port 8009 -- Connector port=8009 protocol=AJP/1.3 redirectPort=8443/ Engine defaultHost=localhost name=Catalina Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ Host appBase=webapps autoDeploy=true name=localhost unpackWARs=true Realm className=com.realm.CustomRealm dataSourceName=ds_admin digest=SHA roleNameCol=role userCredCol=password userNameCol=email userRoleTable=group_role_user userTable=user/ Valve className=org.apache.catalina.authenticator.SingleSignOn/ Context crossContext=true path=/login reloadable=true/ Context crossContext=true path=/admin reloadable=true //Host /Engine 2011/9/16 Christopher Schultz ch...@christopherschultz.net: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chema, On 9/16/2011 1:25 PM, Chema wrote: Presumably, you are using CLIENT-CERT as your auth-method? No, [I am using] FORM method Hmm. HttpSession.invalidate() *is* the proper way to terminate a FORM authentication login. session.invalidate(); org.apache.tomcat.util.net.SSLSessionManager mgr =(org.apache.tomcat.util.net.SSLSessionManager)request.getAttribute(javax.servlet.request.ssl_session_mgr); mgr.invalidateSession(); You don't need this SSL stuff. HttpSession.invalidate() ought to do the trick. response.setHeader(Connection, close); This is optional, and not usually necessary. but didnt work. does anyone have worked with realm + SSL ? anyone ? This definitely works. Are you saying that when you use HTTP instead of HTTPS, logouts work? That sounds really strange. Please post the relevant sections of web.xml and server.xml, and be sure to remove any sensitive information. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5ziX4ACgkQ9CaO5/Lv0PCitQCgwgv0Khtvabe0xJK0A5SYe0u0 BlAAnRno9V/PAwyRKIs1s4cC/2oFz0GK =pshV -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Example to logout on Tomcat 7 and SSL + Realm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 9/16/2011 1:38 PM, André Warnier wrote: I guess that where the OP (and I) get a little confused is in the distinction between the state of having a session and being logged-in, and maybe the sequence in which these things happen. 1) a browser sends a first request to Tomcat, and this happens to be directed to an application which requires authentication (container-driven). 2) Tomcat intercepts the request (because of the authentication requirement), sends back something to the browser which tells the browser (or the user) to supply credentials. 3) the browser (or the user) supplies the credentials along with a subsequent request 4) Tomcat intercepts this again, verifies the credentials, and if they fit, allows the request (now authenticated) to proceed to the application which had been requested in the first place. (and I know that there is some variety in the above, depending on the type of authentication, but roughly that's it, no ?) This is all correct for BASIC, FORM, and CLIENT-CERT authentication strategies. The difference is how the server requests the credentials and how the client provides them. For instance, BASIC uses a 401 server response to request credentials and the client provides them in an WWW-Authenticate header with a subsequent response. FORM responds with a login form and the client sends credentials using POST or query data (aka parameters). For CLIENT-CERT, the server requests the certificate as part of the SSL negotiation, and the certificate is sent as part of the SSL negotiation. 5) then the request hits the application, and it is the application which decides if a session is created or not. Yes ? Here's where things change. For FORM authentication, an HttpSession is created and corresponds directly to the user's privileged status. Once the HttpSession is invalidated, the login expires and the user is logged-out. And if it decides so, this creates some storage place for this session thing, and makes it so that a cookie will later be sent back to the browser, with an id pointing to this session storage thing, so that a subsequent request which provides this cookie, allows the application to retrieve the saved session and its contents prior to handling the next request. The JSESSIONID is used to associated HttpSessions with requests. You can have an HttpSession without having authenticated, but for a FORM authentication, you must have an HttpSession after (and, in Tomcat, /before/) you are successfully authenticated (Servlet spec 3.0 allows you to perform a programmatic login, but I'll ignore that for the purposes of this discussion). Now what is maybe less clear, is whether the session thing which was created, contains or not the authentication data. For FORM authentication, it does. And if yes : a session invalidate should delete the session thing (and the contained authentication info), and this should have the effect that when the browser sends a subsequent request, it will find a no session yet situation. There will be no existing session to fetch in any case. For FORM authentication, that also means that you will have to re-authenticate in order to get to a privileged resource again. Obviously though, no session does not necessarily mean not authenticated, but this is I believe where the OP (and I) are getting confused. For FORM authentication, no session - not authenticated. Technically speaking, the servlet spec defines being logged into an application as [corresponding] precisely to there being a valid non-null caller identity associated with the request as may be determined by calling getRemoteUser or getUserPrincipal on the request (section 13.10). Tomcat implements FORM login by attaching principal information to the session, so when the session dies, so does the login. This is not the case with the other authentication mechanisms (BASIC and CLIENT-CERT): the existence of an HttpSession for a request is independent of the login. This is because the client sends a WWW-Authenticate header (for BASIC) or a client certificate (for CLIENT-CERT) for every request after authentication. The only way to terminate a BASIC login is to issue another 401 response, and the only way to terminate a CLIENT-CERT login is to disrupt the SSL session (I don't know how to do that). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5zkEEACgkQ9CaO5/Lv0PBNdACfS39J4iloiOxkFu9Ru9ncQDUS OZIAnRLnQndKHCBeXG7dBCUG56lG/kKH =IzSM -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
How to Configure Tomcat 7.0 for SSL
Version of Tomcat: Apache Tomcat 7.0 Server: Windows 2003 Problem: Configuring Tomcat 7.0 SSL using Apr Implementation Apache Tomcat splash screen (https://localhost:8443https://localhost:8443/) fails after including key, cert in server.xml configuration using following entries: Connector port=443 protocol=org.apache.coyote.http11.Http11AprProtocol maxHttpHeaderSize=8192 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false disableUploadTimeout=true acceptCount=100 scheme=https secure=true SSLEngine=on SSLCertificateFile=webapps\server.cert SSLCertificateKeyFile=webapps\server.key / Thanks, Gene
Re: Tomcat 7.0.21: BufferOverflowException in AjpAprProcessor.output()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Konstantin, On 9/15/2011 1:02 PM, verlag.preis...@t-online.de wrote: I would like to add that the Exceptions seems to have occured when the client aborted the connection, because at the same time of the exception, in the ISAPI log was the following: [Wed Sep 14 13:55:20.645 2011] [736:7288] [error] iis_write::jk_isapi_plugin.c (1337): Vector write of chunk encoded response failed with 995 (0x03e3) However it's still a bit strange, and I didn't see this Exception in previous versions of Tomcat, when a 995 error appeared in the ISAPI log. Does that mean that the client never sees an error? That would be good, as it makes the problem slightly less urgent :) Are you using unusually large requests, possibly including chains of client certs? If you mean SSL certificates: I don't have any SSL certificate / HTTPS connection on Tomcat. I just use a normal AJP-APR connector and clients connect to IIS through HTTP. Sometimes I send large requests, but I wouldn't expect such an Exception to occur. Ok. If you have a lot of info that needs to be forwarded from the proxy to Tomcat, you can exceed the max packet size of the connector, and it's possible you could get this exception (instead of a nicer error message). The default is 8k, so if you have large amounts of requests data, you could be overflowing this packet size. Have you set packetSize on your Connector? Have you set max_packet_size on any of your workers? If so, the worker.max_packet_size and Connector packetSize=... must agree. I don't have set any of these attributes. Okay, it looks like you have a fairly vanilla setup (which is good!). I can't think of what the problem may be, but it sounds like either some rare edge case or a regression. There has been a lot of work on merging code between all the various connectors wherever possible, and maybe some particular case wasn't merged properly. Would you be able to test with either/or the NIO or BIO AJP connector(s) and see if the same behavior occurs? Do you have a way to force the exception to occur? I wonder if it could be scripted. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5zt/YACgkQ9CaO5/Lv0PB60gCfaI3e5YNOvV+zku1p5cam0F92 lJUAn1kvxZNhpoX5vt0QgZuO7qzULtyV =dR/i -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to return jpg from another disk location
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeffrey, On 9/13/2011 1:21 PM, Jeffrey Janner wrote: Our app currently is not distributable as a war file due to some decisions made long ago (properties files that need to be modified stored in WEB-INF, etc.). [snip] However, there is one sticking point that is a problem. We allow the end user to replace a JPG file with one of their own, so that it gets displayed on certain pages instead of the default one we provide (a logo file). It currently resides in a sub-directory of the exploded war file. Rather than have the customer replace the file after every upgrade, I thought it would be nice to somehow define a location where the file exists, and the app could go get it when requested (sort of like a sym-link). How about setting the URL of the logo in one of those properties files you mentioned above, and then using that URL in your pages? Then the client can even host the image anywhere they want. Presumably, you have some kind of protection against clobbering client preferences: just use that same protection to avoid clobbering their logo URL. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5zuW0ACgkQ9CaO5/Lv0PApDgCfU08u+dV5Onk6lYS/rb7jeOWF GSgAniaeYNwk/Tem1KrBYCVEc4D9Wz2o =Eqnh -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
