Re: j_security_check requires session
... or simply switch to BASIC auth-method. Rossen - Original Message - From: Christopher Schultz [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, September 25, 2008 6:42:40 PM GMT -05:00 US/Canada Eastern Subject: Re: j_security_check requires session -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul, [EMAIL PROTECTED] wrote: It seems that tomcat expects that I already have a session established before posting the username and password. If I don't already have a JSESSIONID cookie, j_security_check returns a 408. This behavior adheres to the Servlet Specification. See section 12.5.3. There is no provision for drive-by logins. Unfortunately, I have another application attempting to talk to this one that requires that the first thing it does is post credentials to the j_security_check, so I have no mechanism of hitting another page first to establish a session. This is non-portable (as you have seen from moving between servlet containers). I think you have a couple of options: 1. Change your remote client to first request the desired secure resource from the server, then submit the credentials with a second request (and you'll be sent to the originally-requested resource, as per the spec) 2. Switch to using securityfilter (which allows drive-bys, and which Mark already plugged) 3. Remove the security constraint from your target service and implement an alternate authentication and authorization strategy (such as checking the credentials yourself in the service) manually This mechanism worked fine with BEA Weblogic, but it seems that tomcat's handling of j_security_check is different. Does anyone know of any options to modify the behavior of j_security_check so that it would just do the authentication and establish the session in one shot at the time of the POST request? There are no spec-compliant options. BEA's behavior is an extension to the servlet specification so whatever you do will be container-specific, unless you go outside the container-managed security provider (say, by using something like securityfilter). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjcE+AACgkQ9CaO5/Lv0PCrUgCgrHAzHozD9/JjmHRlZE/Jpl2X aucAn2mBQ/dIqkYQo2Nn9bYt8dBPUKM/ =g6J7 -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJP encryption
Bill, The VPN and the ssh tunnels encrypt the traffic between the servers but anybody with enough access can listen on the interface and intercept the traffic. For example ngrep -d tun0 would revile all the communications over Open VPN. The encryption of the direct communications between the web and the app server would not allow that and as a result brings extra protection. Having said that I can work on the Java side of the connectors to add optional encryption, but my C is a little bit rusty and it'll be nice if somebody else would be able to help it... Before to jump on it, are you aware of anything already planned or the stuff you mentioned was just proposed? Is there any type of initial documentation on what to and how to? Rossen - Original Message - From: Bill Barker [EMAIL PROTECTED] To: users@tomcat.apache.org Sent: Thursday, June 19, 2008 11:45:08 PM GMT -05:00 US/Canada Eastern Subject: Re: AJP encryption Rossen Raykov [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi All, Is there anybody interested in encrypting the AJP communication channel? Is anything like that planned for the next release? It's on the wishlist for AJP/1.4 (as well as compression). However there hasn't been much developer traction on AJP/1.4 for years. The general consence on [EMAIL PROTECTED] has been to not add it to an AJP/1.3 release, so the answer to your second question is likely: no. The answer to your first question (based on this list) is likely: yes. AJP is designed to work over high-speed, secure, internal networks. In this type of environment, if a black-hat can manage to sniff AJP traffic, you have much bigger problems on your hands ;). However, if you want to submit patches to add encryption, I'm sure that you will find tomcat developers that are interested in reviewing them. As Markus said, there are plenty of ways to encrypt AJP traffic today. Just judging from this list, SSH tunnelling is popular, as well as Markus' suggestion of OpenVPN. Rossen - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AJP encryption
Hi All, Is there anybody interested in encrypting the AJP communication channel? Is anything like that planned for the next release? Rossen - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
