Re: Need Help : Tomcat 9.0.75 not honoring session timeout configured in tomcat web.xml for FORM Authentication
Channa, On 10/27/23 00:07, Channa Puchakayala wrote: Tomcat Version : 9.0.75 Operating System: Windows and Linux Bits: 64 Tomcat 9.0.75 not honoring session timeout configured in tomcat/conf/web.xml for FORM Authentication and it is effecting customers. == 30 // 30 minutes = Verified the Tomcat source code -FormAuthenticator overriding above configured session timeout setting (30 minutes) with value (120 seconds) -As per FormAuthenticator.Java, this change/issue started from Tomcat Version : 9.0.74 for FORM Authentication and it overwrites the original session-timeout value -This issue/behavior not observed in 9.0.73 Verified the Tomcat documentation -Verified the tomcat changelog, there is a fix/change went in Tomcat 9.0.74 below related to FORM Based Authentication Session @ https://tomcat.apache.org/tomcat-9.0-doc/changelog.html <https://tomcat.apache.org/tomcat-9.0-doc/changelog.html>, looks which is causing this issue. Can you please state clearly what the issue actually is? This is documented behavior of Tomcat. There is a well-documented setting that you can adjust if necessary. Are you reporting a problem? If so, it is not clear from your message above. What test did you perform? What did you expect to happen? What actually happened that was different from your expectation? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Need Help : Tomcat 9.0.75 not honoring session timeout configured in tomcat web.xml for FORM Authentication
1. Do not cross-post the same question to multiple lists. 2. Do not post the same question multiple times if you don't get an answer as quickly as you would like. We all all volunteers here. If you want a guaranteed SLA then pick you preferred vendor and pay for support. Mark 27 Oct 2023 05:07:20 Channa Puchakayala : Hi All, Tomcat Version : 9.0.75 Operating System: Windows and Linux Bits: 64 Tomcat 9.0.75 not honoring session timeout configured in tomcat/conf/web.xml for FORM Authentication and it is effecting customers. == 30 // 30 minutes = Verified the Tomcat source code - FormAuthenticator overriding above configured session timeout setting (30 minutes) with value (120 seconds) - As per FormAuthenticator.Java, this change/issue started from Tomcat Version : 9.0.74 for FORM Authentication and it overwrites the original session-timeout value - This issue/behavior not observed in 9.0.73 Verified the Tomcat documentation - Verified the tomcat changelog, there is a fix/change went in Tomcat 9.0.74 below related to FORM Based Authentication Session @ https://tomcat.apache.org/tomcat-9.0-doc/changelog.html, looks which is causing this issue. -- Harden the FORM authentication process against DoS attacks by using a reduced session timeout if the FORM authentication process creates a session. The duration of this timeout is configured by the *authenticationSessionTimeout* attribute of the FORM authenticator. (markt) - Is it bug ? Could you please help/suggest. Thanks Channa This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Need Help : Tomcat 9.0.75 not honoring session timeout configured in tomcat web.xml for FORM Authentication
Hi All, Tomcat Version : 9.0.75 Operating System: Windows and Linux Bits: 64 Tomcat 9.0.75 not honoring session timeout configured in tomcat/conf/web.xml for FORM Authentication and it is effecting customers. == 30 // 30 minutes = Verified the Tomcat source code -FormAuthenticator overriding above configured session timeout setting (30 minutes) with value (120 seconds) -As per FormAuthenticator.Java, this change/issue started from Tomcat Version : 9.0.74 for FORM Authentication and it overwrites the original session-timeout value -This issue/behavior not observed in 9.0.73 Verified the Tomcat documentation -Verified the tomcat changelog, there is a fix/change went in Tomcat 9.0.74 below related to FORM Based Authentication Session @ https://tomcat.apache.org/tomcat-9.0-doc/changelog.html, looks which is causing this issue. -- Harden the FORM authentication process against DoS attacks by using a reduced session timeout if the FORM authentication process creates a session. The duration of this timeout is configured by the authenticationSessionTimeout attribute of the FORM authenticator. (markt) - Is it bug ? Could you please help/suggest. Thanks Channa -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. smime.p7s Description: S/MIME Cryptographic Signature
RE: Form authentication with Tomcat 7.0.63 behind Apache HTTPD and mod_jk
Mark Look for *** for my response. -Original Message- From: Mark Eggers [mailto:its_toas...@yahoo.com.INVALID] Sent: Monday, July 13, 2015 2:13 PM To: Tomcat Users List Subject: Re: Form authentication with Tomcat 7.0.63 behind Apache HTTPD and mod_jk -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Folks, I have resolved the issue: On 7/10/2015 11:27 AM, Mark Eggers wrote: Now with the shipped examples goodness: On 7/9/2015 10:39 PM, Konstantin Kolinko wrote: 2015-07-10 2:35 GMT+03:00 Mark Eggers its_toas...@yahoo.com.invalid: Folks, I seem to be having a problem trying to use form-based authentication. What worked in 7.0.62 no longer works in 7.0.63. Using 7.0.62 I can successfully authenticate in my toy application and the latest version of Jenkins. Using 7.0.63 I end up on the form error page in my toy application and the latest version of Jenkins. [SNIP] I'll try to start working through the code changes to see where the likely culprit is. . . . just my puzzled 2 cents /mde/ It would have helped (and not wasted everyone's time) if I had read the changelog carefully. - From the changelog: fix 57938: Correctly handle empty form fields when a form is submitted as multipart/form-data, the maxPostSize attribute of the Connector has been set to a negative value and the Context has been configured with a value of true for allowCasualMultipartParsing. The meaning of the value zero for the maxPostSize has also been changed to mean a limit of zero rather than no limit to align it with maxSavePostSize and to be more intuitive. (markt) My AJP connector (since I have to support some oddly-written application s): Connector URIEncoding=UTF-8 connectionTimeout=60 maxPostSize=0 port=8009 protocol=AJP/1.3 redirectPort=8443 / Since 0 now really means 0, I was not getting any POST parameters throug h. It now reads: Connector URIEncoding=UTF-8 connectionTimeout=60 maxPostSize=-1 port=8009 protocol=AJP/1.3 redirectPort=8443 / and everything works. Sorry for the noise. *** No problem - even your noise is educational for me. :-) *** . . . documentation, it's not just for breakfast anymore /mde/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJVo/+3AAoJEEFGbsYNeTwtPn4IAK0tdY22hwq/LRr71ozShRgx XiCiHB/X79P71VIbs8rQ5Ao3RNG6quEzsZQXWXFNvvWq4uSh3cUivRLd53LylST2 aGrdn1UhJCGOmI5zaLiPo+XOlhLkp2DdGVUwfMjwmO0g/4Ogfqq2NBR2BZ4JTwyd tX0GraXUc04ORErFiJdHx2vxx9lf9ysbvjts4ARE+w2ugV2Us7ZziCmu7uiOEALm 5Fozif5GYbQb2npssyszgA4brI8UWIChlpcr8QQP6IpuKmZK3yeRNzV5yC9UyfCg NhrOl6UDdStqekQTgxdORezgz5vJTxREnJbEHYKJ3XIB0nM9ObXhObwPA46Jx64= =kKwI -END PGP SIGNATURE-
Re: Form authentication with Tomcat 7.0.63 behind Apache HTTPD and mod_jk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Folks, I have resolved the issue: On 7/10/2015 11:27 AM, Mark Eggers wrote: Now with the shipped examples goodness: On 7/9/2015 10:39 PM, Konstantin Kolinko wrote: 2015-07-10 2:35 GMT+03:00 Mark Eggers its_toas...@yahoo.com.invalid: Folks, I seem to be having a problem trying to use form-based authentication. What worked in 7.0.62 no longer works in 7.0.63. Using 7.0.62 I can successfully authenticate in my toy application and the latest version of Jenkins. Using 7.0.63 I end up on the form error page in my toy application and the latest version of Jenkins. I've not changed any of the configuration files. I run Tomcat using $CATALINA_HOME and $CATALINA_BASE. To upgrade Tomcat, I just install a new version and move some links around. Here is a rundown of my environment: [] How it fails? (Steps, maybe also Access Log output) Quick test with direct access to Tomcat and examples webapp = success. (http://localhost:8080/examples/jsp/security/protected/index.jsp) Architecture where this works: -- Browser -- Apache HTTPD -- mod-jk -- Tomcat 7.0.62 -- examples Browser -- Tomcat 7.0.62 -- examples Browser -- Tomcat 7.0.63 -- examples Architecture where this fails (brings up invalid login page) Browser -- Apache HTTPD -- mod-jk -- Tomcat 7.0.63 -- examples Possible areas to test: 1. httpd / mod_jk : Do you have failure with direct access to Tomcat ? 2. cookie / set-cookie headers e.g. see AccessLogValve configuration here: https://bz.apache.org/bugzilla/show_bug.cgi?id=57872#c0 3. Realm Best regards, Konstantin Kolinko So it does appear to be an issue with the supplied examples as well. I didn't see anything obviously wrong with my mod-jk configuration (posted in the first email). I'll try to start working through the code changes to see where the likely culprit is. . . . just my puzzled 2 cents /mde/ It would have helped (and not wasted everyone's time) if I had read the changelog carefully. - From the changelog: fix 57938: Correctly handle empty form fields when a form is submitted as multipart/form-data, the maxPostSize attribute of the Connector has been set to a negative value and the Context has been configured with a value of true for allowCasualMultipartParsing. The meaning of the value zero for the maxPostSize has also been changed to mean a limit of zero rather than no limit to align it with maxSavePostSize and to be more intuitive. (markt) My AJP connector (since I have to support some oddly-written application s): Connector URIEncoding=UTF-8 connectionTimeout=60 maxPostSize=0 port=8009 protocol=AJP/1.3 redirectPort=8443 / Since 0 now really means 0, I was not getting any POST parameters throug h. It now reads: Connector URIEncoding=UTF-8 connectionTimeout=60 maxPostSize=-1 port=8009 protocol=AJP/1.3 redirectPort=8443 / and everything works. Sorry for the noise. . . . documentation, it's not just for breakfast anymore /mde/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJVo/+3AAoJEEFGbsYNeTwtPn4IAK0tdY22hwq/LRr71ozShRgx XiCiHB/X79P71VIbs8rQ5Ao3RNG6quEzsZQXWXFNvvWq4uSh3cUivRLd53LylST2 aGrdn1UhJCGOmI5zaLiPo+XOlhLkp2DdGVUwfMjwmO0g/4Ogfqq2NBR2BZ4JTwyd tX0GraXUc04ORErFiJdHx2vxx9lf9ysbvjts4ARE+w2ugV2Us7ZziCmu7uiOEALm 5Fozif5GYbQb2npssyszgA4brI8UWIChlpcr8QQP6IpuKmZK3yeRNzV5yC9UyfCg NhrOl6UDdStqekQTgxdORezgz5vJTxREnJbEHYKJ3XIB0nM9ObXhObwPA46Jx64= =kKwI -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form authentication with Tomcat 7.0.63 behind Apache HTTPD and mod_jk
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Konstantin,
On 7/9/2015 10:39 PM, Konstantin Kolinko wrote:
2015-07-10 2:35 GMT+03:00 Mark Eggers
its_toas...@yahoo.com.invalid:
Folks,
I seem to be having a problem trying to use form-based
authentication. What worked in 7.0.62 no longer works in 7.0.63.
Using 7.0.62 I can successfully authenticate in my toy
application and the latest version of Jenkins. Using 7.0.63 I end
up on the form error page in my toy application and the latest
version of Jenkins.
I've not changed any of the configuration files. I run Tomcat
using $CATALINA_HOME and $CATALINA_BASE. To upgrade Tomcat, I
just install a new version and move some links around.
Here is a rundown of my environment:
[]
How it fails? (Steps, maybe also Access Log output)
Steps to fail:
Use the following architecture:
Browser -- Apache HTTPD -- mod-jk -- Tomcat 7.0.63 -- Application
1. Access main page of application
2. Select the login link
3. Fill out the login form (username and password)
4. Click on the login button
5. Get the error login page
Quick test with direct access to Tomcat and examples webapp =
success.
(http://localhost:8080/examples/jsp/security/protected/index.jsp)
Possible areas to test: 1. httpd / mod_jk : Do you have failure
with direct access to Tomcat ?
No, direct access to Tomcat 7.0.63 on port 8080 works as expected. In
other words:
Browser -- Tomcat 7.0.63 -- Application
works.
2. cookie / set-cookie headers e.g. see AccessLogValve
configuration here:
https://bz.apache.org/bugzilla/show_bug.cgi?id=57872#c0
Here's what I placed in the pattern attribute of the AccessLogValve
(all one line):
%a - - %t %m %U %H %s %B
SessionId: %S
Cookie received: %{cookie}i
Set-Cookie sent: %{set-cookie}o
Here's the log output in the following scenario:
Browser -- Apache HTTPD -- mod-jk -- Tomcat 7.0.63 -- Application
192.168.0.250 - - [10/Jul/2015:01:19:39 -0700] GET /RPets HTTP/1.1 302 0
SessionId: -
Cookie received: -
Set-Cookie sent: -
192.168.0.250 - - [10/Jul/2015:01:19:39 -0700]
GET /RPets/ HTTP/1.1 200 1595
SessionId: 38503E0B0A32A870DABE772453A5A553
Cookie received: JSESSIONID=38503E0B0A32A870DABE772453A5A553
Set-Cookie sent: -
192.168.0.250 - - [10/Jul/2015:01:19:43 -0700]
GET /RPets/protected/personalize.jsp HTTP/1.1 304 0
SessionId: F1DCC3FDF2DD75F563A67430BA985287
Cookie received: JSESSIONID=38503E0B0A32A870DABE772453A5A553
Set-Cookie sent:
JSESSIONID=F1DCC3FDF2DD75F563A67430BA985287; Path=/RPets/; HttpOnly
192.168.0.250 - - [10/Jul/2015:01:19:53 -0700]
POST /RPets/protected/j_security_check HTTP/1.1 200
SessionId: F1DCC3FDF2DD75F563A67430BA985287
Cookie received: JSESSIONID=F1DCC3FDF2DD75F563A67430BA985287
Set-Cookie sent: -
[ and the error page for a failed login is displayed ]
Here's the log output in the following scenario:
Browser -- Tomcat 7.0.63 -- Application
192.168.0.250 - - [10/Jul/2015:01:32:44 -0700]
GET /RPets HTTP/1.1 302 0
SessionId: -
Cookie received: -
Set-Cookie sent: -
192.168.0.250 - - [10/Jul/2015:01:32:44 -0700]
GET /RPets/ HTTP/1.1 200 1595
SessionId: F1DCC3FDF2DD75F563A67430BA985287
Cookie received: JSESSIONID=F1DCC3FDF2DD75F563A67430BA985287
Set-Cookie sent: -
192.168.0.250 - - [10/Jul/2015:01:32:47 -0700]
GET /RPets/protected/personalize.jsp HTTP/1.1 200 1090
SessionId: 6E42788DECF5F96688EF7D51FC41EA0F
Cookie received: JSESSIONID=F1DCC3FDF2DD75F563A67430BA985287
Set-Cookie sent:
JSESSIONID=6E42788DECF5F96688EF7D51FC41EA0F; Path=/RPets/; HttpOnly
192.168.0.250 - - [10/Jul/2015:01:32:56 -0700]
POST /RPets/protected/j_security_check HTTP/1.1 302 0
SessionId: 6E42788DECF5F96688EF7D51FC41EA0F
Cookie received: JSESSIONID=6E42788DECF5F96688EF7D51FC41EA0F
Set-Cookie sent: -
192.168.0.250 - - [10/Jul/2015:01:32:56 -0700]
GET /RPets/protected/personalize.jsp HTTP/1.1 200 2405
SessionId: CC61312515FED5CF197475B41AA7B017
Cookie received: JSESSIONID=F1DCC3FDF2DD75F563A67430BA985287
Set-Cookie sent:
JSESSIONID=CC61312515FED5CF197475B41AA7B017; Path=/RPets/; HttpOnly
192.168.0.250 - - [10/Jul/2015:01:32:57 -0700]
GET /RPets/protected/css/pbasic.css HTTP/1.1 304 0
SessionId: CC61312515FED5CF197475B41AA7B017
Cookie received: JSESSIONID=CC61312515FED5CF197475B41AA7B017
Set-Cookie sent: -
[ login succeeds and the personalize.jsp page is displayed ]
Here's the log output in the following scenario:
Browser -- Apache HTTPD -- mod-jk -- Tomcat 7.0.62 -- Application
192.168.0.250 - - [10/Jul/2015:01:54:24 -0700]
GET /RPets HTTP/1.1 302 0
SessionId: -
Cookie received: -
Set-Cookie sent: -
192.168.0.250 - - [10/Jul/2015:01:54:25 -0700]
GET /RPets/ HTTP/1.1 200 1595
SessionId: -
Cookie received: -
Set-Cookie sent: -
192.168.0.250 - - [10/Jul/2015:01:54:29 -0700]
GET /RPets/protected/personalize.jsp HTTP/1.1 304 0
SessionId: 11AD7E9AE579C904277AB59A8DAC0F58
Cookie received: -
Set-Cookie sent:
JSESSIONID=11AD7E9AE579C904277AB59A8DAC0F58; Path=/RPets/; HttpOnly
192.168.0.250 - - [10/Jul/2015:01:54:38 -0700]
Re: Form authentication with Tomcat 7.0.63 behind Apache HTTPD and mod_jk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Now with the shipped examples goodness: On 7/9/2015 10:39 PM, Konstantin Kolinko wrote: 2015-07-10 2:35 GMT+03:00 Mark Eggers its_toas...@yahoo.com.invalid: Folks, I seem to be having a problem trying to use form-based authentication. What worked in 7.0.62 no longer works in 7.0.63. Using 7.0.62 I can successfully authenticate in my toy application and the latest version of Jenkins. Using 7.0.63 I end up on the form error page in my toy application and the latest version of Jenkins. I've not changed any of the configuration files. I run Tomcat using $CATALINA_HOME and $CATALINA_BASE. To upgrade Tomcat, I just install a new version and move some links around. Here is a rundown of my environment: [] How it fails? (Steps, maybe also Access Log output) Quick test with direct access to Tomcat and examples webapp = success. (http://localhost:8080/examples/jsp/security/protected/index.jsp) Architecture where this works: - -- Browser -- Apache HTTPD -- mod-jk -- Tomcat 7.0.62 -- examples Browser -- Tomcat 7.0.62 -- examples Browser -- Tomcat 7.0.63 -- examples Architecture where this fails (brings up invalid login page) - Browser -- Apache HTTPD -- mod-jk -- Tomcat 7.0.63 -- examples Possible areas to test: 1. httpd / mod_jk : Do you have failure with direct access to Tomcat ? 2. cookie / set-cookie headers e.g. see AccessLogValve configuration here: https://bz.apache.org/bugzilla/show_bug.cgi?id=57872#c0 3. Realm Best regards, Konstantin Kolinko So it does appear to be an issue with the supplied examples as well. I didn't see anything obviously wrong with my mod-jk configuration (posted in the first email). I'll try to start working through the code changes to see where the likely culprit is. . . . just my puzzled 2 cents /mde/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJVoA6LAAoJEEFGbsYNeTwtgcEH/1Rb2Wji7oSELJgeUgTfdTRm oDCnPQ5f11RBnx/7+0SHFN/4qu1VIOce0dckPIRM2KIkNI9mNsKPF2Bgt1Ixejvw IaqlafbRgQTqXoomEB/Y3vxpzhRvo0sQCwJN4O81JLUcnT5wIgnaZr8Gwd0vkzMF dktu5TEAIAiHRIWudFPpSuO5tWvJAu4FWzay4YPqfic4wGtCNGXtZQCeuL3bq6Jl Hc51dvNMdkF1gWqDNNzarQu9POLb1qDW2Ezy4grlRKIHCUQWALoxqTZj3IL8g0Sc phdi3pqd54pe5VDNc7l3mIdOCaYY+f529vz0CGBzzKox7qaa3/Lvpqy6CcQ5xtU= =+F5Q -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form authentication with Tomcat 7.0.63 behind Apache HTTPD and mod_jk
2015-07-10 2:35 GMT+03:00 Mark Eggers its_toas...@yahoo.com.invalid: Folks, I seem to be having a problem trying to use form-based authentication. What worked in 7.0.62 no longer works in 7.0.63. Using 7.0.62 I can successfully authenticate in my toy application and the latest version of Jenkins. Using 7.0.63 I end up on the form error page in my toy application and the latest version of Jenkins. I've not changed any of the configuration files. I run Tomcat using $CATALINA_HOME and $CATALINA_BASE. To upgrade Tomcat, I just install a new version and move some links around. Here is a rundown of my environment: [] How it fails? (Steps, maybe also Access Log output) Quick test with direct access to Tomcat and examples webapp = success. (http://localhost:8080/examples/jsp/security/protected/index.jsp) Possible areas to test: 1. httpd / mod_jk : Do you have failure with direct access to Tomcat ? 2. cookie / set-cookie headers e.g. see AccessLogValve configuration here: https://bz.apache.org/bugzilla/show_bug.cgi?id=57872#c0 3. Realm Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Form authentication with Tomcat 7.0.63 behind Apache HTTPD and mod_jk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Folks, I seem to be having a problem trying to use form-based authentication. What worked in 7.0.62 no longer works in 7.0.63. Using 7.0.62 I can successfully authenticate in my toy application and the latest version of Jenkins. Using 7.0.63 I end up on the form error page in my toy application and the latest version of Jenkins. I've not changed any of the configuration files. I run Tomcat using $CATALINA_HOME and $CATALINA_BASE. To upgrade Tomcat, I just install a new version and move some links around. Here is a rundown of my environment: Structure - - CentOS 6.6 - latest updates Apache HTTPD 2.2.15-39.el6.centos.x86_64 mod_jk 1.2.40 Tomcat 7.0.62 (7.0.63) JRE 1.8.0_45 uriworkermap.properties - --- /jenkins|/*=loki /RPets|/*=loki worker.properties - - worker.list=jk-status,jk-manager,loki worker.jk-status.type=status worker.jk-status.read_only=true worker.jk-manager.type=status worker.template.type=ajp13 worker.template.host=127.0.0.1 worker.template.socket_connect_timeout=5000 worker.template.socket_keepalive=true worker.template.ping_mode=A worker.template.ping_timeout=1 worker.template.connection_pool_minsize=0 worker.template.connection_pool_timeout=600 worker.template.reply_timeout=30 worker.template.recovery_options=3 worker.loki.reference=worker.template worker.loki.port=8009 modjk.conf - -- LoadModule jk_module modules/mod_jk.so IfModule jk_module JkWorkersFile conf.d/workers.properties JkLogFile logs/mod_jk.log JkLogLevel info JkOptions +RejectUnsafeURI JkWatchdogInterval 60 Location /jk-status JkMount jk-status Order Deny,Allow Deny from all Allow from 127.0.0.1 Allow from 192.168.0.0/255.255.255.0 /Location Location /jk-manager JkMount jk-manager Order deny,allow Deny from all Allow from 127.0.0.1 Allow from 192.168.0.0/255.255.255.0 /Location JkMountFile conf.d/uriworkermap.properties /IfModule server.xml (sorry for the wrapping) - -- ?xml version=1.0 encoding=utf-8 standalone=no? Server port=8005 shutdown=SHUTDOWN Listener className=org.apache.catalina.startup.VersionLoggerListener / Listener SSLEngine=on className=org.apache.catalina.core.AprLifecycleListener / Listener className=org.apache.catalina.core.JasperListener / Listener className=org.apache.catalina.core.JreMemoryLeakPreventionListener / Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener/ Listener className=org.apache.catalina.core.ThreadLocalLeakPreventionListener/ GlobalNamingResources Resource auth=Container description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory name=UserDatabase pathname=conf/tomcat-users.xml type=org.apache.catalina.UserDatabase / /GlobalNamingResources Service name=Catalina Connector URIEncoding=UTF-8 address=192.168.0.202 connectionTimeout=2 maxConnections=4 port=8080 protocol=HTTP/1.1 redirectPort=8443 / Connector URIEncoding=UTF-8 connectionTimeout=60 maxPostSize=0 port=8009 protocol=AJP/1.3 redirectPort=8443 / Engine defaultHost=localhost name=Catalina Realm className=org.apache.catalina.realm.LockOutRealm Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase / /Realm Host appBase=webapps autoDeploy=true name=localhost unpackWARs=true Valve className=org.apache.catalina.valves.AccessLogValve directory=logs pattern=combined prefix=localhost-access- suffix=.log / /Host Host appBase=/home/tcadmin/Platforms/loki/vhosts/loki/webapps autoDeploy=true name=loki unpackWARs=true Valve className=org.apache.catalina.valves.AccessLogValve directory=logs pattern=combined prefix=loki-access- suffix=.log / Aliasloki.mdeggers.org/Alias /Host /Engine /Service /Server Working - --- Browser -- Apache HTTPD -- mod_jk -- Tomcat 7.0.62 -- application Browser -- Tomcat 7.0.62 -- application Browser -- Tomcat 7.0.63 -- application Failing - --- Browser -- Apache HTTPD -- mod_jk -- Tomcat 7.0.63 -- application I've tried the above with and without Tomcat native being present. The success and failure pattern is the same. If just my application was failing I would say that I need to learn more about J2EE authentication and
Re: Form Authentication and Cache-Control
Hi. I've solved my problem. The correct attitude is to have all contexts unauthenticated and only few restrict. In my case restricted urls are /index.jsp, /admin/*, /user/* In the original web.xml I had all contexts restricted and static context /common/* was masked out. Although the /common/* was not under authetication, Tomcat was adding the Cache-Control: private, Expires: 1.1.1970 headers. So I personally think this is a bug. Thanks to Christopher Schultz who gave me a clue. Jan. === My aps has these part /* - common authenticated content /user/* - content for user /admin/* - content for admin /common/* - common unauthenticated static content like images, css, etc My web.xml security-constraint web-resource-collection web-resource-nameMyApp/web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-namemyapp-admin-role/role-name role-namemyapp-user-role/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameMyApp/web-resource-name url-pattern/admin/*/url-pattern /web-resource-collection auth-constraint role-namemyapp-admin-role/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameMyApp/web-resource-name url-pattern/user/*/url-pattern /web-resource-collection auth-constraint role-namemyapp-user-role/role-name /auth-constraint /security-constraint !-- do not authenticate common -- security-constraint web-resource-collection web-resource-nameMyApp/web-resource-name url-pattern/common/*/url-pattern /web-resource-collection /security-constraint login-config auth-methodFORM/auth-method form-login-config form-login-page/login.jsp/form-login-page form-error-page/login_failed.jsp/form-error-page /form-login-config /login-config security-role role-namemyapp-admin-role/role-name /security-role security-role role-namemyapp-user-role/role-name /security-role Jan. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication and Cache-Control
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jan, On 7/16/13 3:55 AM, Jan Vávra wrote: I've solved my problem. The correct attitude is to have all contexts unauthenticated and only few restrict. In my case restricted urls are /index.jsp, /admin/*, /user/* In the original web.xml I had all contexts restricted and static context /common/* was masked out. Although the /common/* was not under authetication, Tomcat was adding the Cache-Control: private, Expires: 1.1.1970 headers. So I personally think this is a bug. No, you told Tomcat that the entire site was under a security constraint. The fact that you didn't have any required roles was irrelevant. The cache-control headers are added for security-constrained resources. Tomcat is behaving properly. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJR5XjZAAoJEBzwKT+lPKRYGt4QALeNapyXezWDsn0jEl7Oyd1S a9mA89Ovc13nQiZF/ys/dmX4U9MsbzbBBArPmQaWzbdqZjcp2WlhUVgCmfA7mD33 8wAgE5M56R8uXm7NA2tDdrLX3jAYHrbG2TRO0x7rQZQIkNC9tEiAl1xCyDdiYehm i3X3oH9ujluf7f/ducgTkr0NpYBL0SNjoi5DmBVws7ke5tbkLrY+zvPfwd/h9q5J WenOI1MKJh7OHw6MVToe346f6ERdT85fc4UG4kaKEwq0cwak4JXyLr+PG9dsoMUQ SoWS05adtYNZHRCfSTDdrmuv5CPch5/oP6AEQI3Y338+zsDo13aS/N2FRwFNygUB kwzvP7HIEetT4VjpHSg21X9x0c6lqHlpHkQQjj9ZW6FY+af4Io/J0joihVMWTpfe 2zYpu5ZCRxPPd0j39YS2vc+9aV7eRmxEjpSIGbJbKqEQolTk3fN8Wqcug3pcKkNL rcXx2d0c28obqIY5SkiLn676NAzXXTa5g5zXVt/08tBcouLv/dXfILwKe7Gg9cWn jGe46l4XrGzvXugNemLv6eBKDZ5HGIfCeHzmO47E2X2UOY/+xUVqAh7npMcMWrUg inZcOmtqKcALJcLI276R0d2z2qJnE4Wv//NlfdZBLVZZWhV8GDCQ0nKLaSF6FSET QwDfaEHUXJKIa1onK7Yy =OXjQ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication and Cache-Control
Hi. Note that Cache-Control:private does not disable caching. Instead, it disables public-caching for proxies. The browser is still free to cache the document in certain ways. True disabling of the cache would be to set Cache-Control to no-cache or no-store (though no-store is usually more appropriate for controlling proxies and not browsers). Ok. I thought it controls browser caching. If I add disableProxyCaching=false to Valve className=org.apache.catalina.authenticator.FormAuthenticator characterEncoding=utf-8/ at my context.xml the response headers change to: HTTP/1.1 304 Not Modified Server: Apache-Coyote/1.1 ETag: W/3907-1372233712661 Date: Wed, 26 Jun 2013 11:25:23 GMT and browser in the next request doesn't asks for this image. Is it safe to override default bahaviour via disableProxyCaching? Or I am something missing? Or there is a best practice to place images, css styles into another application? What happens with dynamic resources? The reason that cache-disabling is on by default is that having proxies and/or browsers caching resources that were protected by authentication is a potential security or privacy problem. From the documentation for disableProxyCaching: Controls the caching of pages that are protected by security constraints. Setting this to false may help work around caching issues in some browsers but will also cause secured pages to be cached by proxies which will almost certainly be a security issue. securePagesWithPragma offers an alternative, secure, workaround for browser caching issues. If not set, the default value of true will be used. Tomcat can't tell which resources are okay to allow the browser to cache and which aren't. Why we cannot tell tomcat what resources are okay? I was playing with Expiration Filter for /common/* but with no effect. IMO, you might want to think about using a fronting web server to serve your static content (which will not include any headers that would otherwise be sent by Tomcat) and map all dynamic requests to Tomcat. There are certainly other ways to get this done as well, but you may find that configuring your way around this problem is more difficult than you imagined. One way that I have in mind is to make second tomcat application /myapp-static that contains static images etc. And link all images to this context. But this is ugly. Is there actually a /problem/ with having Cache-Control:private set on your resources? Have you tried playing with the securePagesWithPragma setting? The problem is only the effectivity of network traffic. For one page load the browser asks for each image, ccs all the time ( after click, not Ctrl+R for refresh). Why Tomcat is also responding header Expires: Thu, 01 Jan 1970 00:00:00 UTC ? I think all this behaviour is somehow connected to form based auth. I must prove it by more tests. === My aps has these part /* - common authenticated content /user/* - content for user /admin/* - content for admin /common/* - common unauthenticated static content like images, css, etc My web.xml security-constraint web-resource-collection web-resource-nameMyApp/web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-namemyapp-admin-role/role-name role-namemyapp-user-role/role-name /auth-constraint /security-constraint Technically, the above web-resource-collection is protected, which includes everything on your site. Instead of blanketing the whole site with what amounts to a black-list and then white-listing other resources, why not do the reverse and only use a white-list? That will avoid protecting resources that need not be protected. security-constraint web-resource-collection web-resource-nameMyApp/web-resource-name url-pattern/admin/*/url-pattern /web-resource-collection auth-constraint role-namemyapp-admin-role/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameMyApp/web-resource-name url-pattern/user/*/url-pattern Umm... you have the same url-pattern (/*) in two separate web-resource-collections. Is that intentional? I have /* allowed for admin and user roles. There are only login, logout, j_sercurity_check pages. And after succ. login user is redirected to his context (/user or /admin). /admin/* is only for admin and /user/* only for user role. And also I do not want to allow for admin accessing the /user/* pages and vice versa. I do not have /* twice or I don't fully understand you. Jan. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication and Cache-Control
On 6/27/2013 9:37 AM, Jan Vávra wrote: Hi. Note that Cache-Control:private does not disable caching. Instead, it disables public-caching for proxies. The browser is still free to cache the document in certain ways. True disabling of the cache would be to set Cache-Control to no-cache or no-store (though no-store is usually more appropriate for controlling proxies and not browsers). Ok. I thought it controls browser caching. If I add disableProxyCaching=false to Valve className=org.apache.catalina.authenticator.FormAuthenticator characterEncoding=utf-8/ at my context.xml the response headers change to: HTTP/1.1 304 Not Modified Server: Apache-Coyote/1.1 ETag: W/3907-1372233712661 Date: Wed, 26 Jun 2013 11:25:23 GMT and browser in the next request doesn't asks for this image. Is it safe to override default bahaviour via disableProxyCaching? Or I am something missing? Or there is a best practice to place images, css styles into another application? What happens with dynamic resources? The reason that cache-disabling is on by default is that having proxies and/or browsers caching resources that were protected by authentication is a potential security or privacy problem. From the documentation for disableProxyCaching: Controls the caching of pages that are protected by security constraints. Setting this to false may help work around caching issues in some browsers but will also cause secured pages to be cached by proxies which will almost certainly be a security issue. securePagesWithPragma offers an alternative, secure, workaround for browser caching issues. If not set, the default value of true will be used. Tomcat can't tell which resources are okay to allow the browser to cache and which aren't. Why we cannot tell tomcat what resources are okay? I was playing with Expiration Filter for /common/* but with no effect. IMO, you might want to think about using a fronting web server to serve your static content (which will not include any headers that would otherwise be sent by Tomcat) and map all dynamic requests to Tomcat. There are certainly other ways to get this done as well, but you may find that configuring your way around this problem is more difficult than you imagined. One way that I have in mind is to make second tomcat application /myapp-static that contains static images etc. And link all images to this context. But this is ugly. Hi, Jan- If you're packaging the app as a WAR, it means two instead of one - and the work that goes along with generating, maintaining and distributing the extra WAR. It does add complexity. -Terence Bandoian Is there actually a /problem/ with having Cache-Control:private set on your resources? Have you tried playing with the securePagesWithPragma setting? The problem is only the effectivity of network traffic. For one page load the browser asks for each image, ccs all the time ( after click, not Ctrl+R for refresh). Why Tomcat is also responding header Expires: Thu, 01 Jan 1970 00:00:00 UTC ? I think all this behaviour is somehow connected to form based auth. I must prove it by more tests. === My aps has these part /* - common authenticated content /user/* - content for user /admin/* - content for admin /common/* - common unauthenticated static content like images, css, etc My web.xml security-constraint web-resource-collection web-resource-nameMyApp/web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-namemyapp-admin-role/role-name role-namemyapp-user-role/role-name /auth-constraint /security-constraint Technically, the above web-resource-collection is protected, which includes everything on your site. Instead of blanketing the whole site with what amounts to a black-list and then white-listing other resources, why not do the reverse and only use a white-list? That will avoid protecting resources that need not be protected. security-constraint web-resource-collection web-resource-nameMyApp/web-resource-name url-pattern/admin/*/url-pattern /web-resource-collection auth-constraint role-namemyapp-admin-role/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameMyApp/web-resource-name url-pattern/user/*/url-pattern Umm... you have the same url-pattern (/*) in two separate web-resource-collections. Is that intentional? I have /* allowed for admin and user roles. There are only login, logout, j_sercurity_check pages. And after succ. login user is redirected to his context (/user or /admin). /admin/* is only for admin and /user/* only for user role. And also I do not want to allow for admin accessing the /user/* pages and vice versa. I do not have /* twice or I don't fully understand you. Jan. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands,
Form Authentication and Cache-Control
Hello, If I use auth-method FORM, all requests return with headers denying caching on the browser side although I have excluded some part of my app from authentication. The headers for a png image are: HTTP/1.1 304 Not Modified Server: Apache-Coyote/1.1 Cache-Control: private Expires: Thu, 01 Jan 1970 00:00:00 UTC ETag: W/3907-1372233712661 Date: Wed, 26 Jun 2013 11:06:17 GMT If I add disableProxyCaching=false to Valve className=org.apache.catalina.authenticator.FormAuthenticator characterEncoding=utf-8/ at my context.xml the response headers change to: HTTP/1.1 304 Not Modified Server: Apache-Coyote/1.1 ETag: W/3907-1372233712661 Date: Wed, 26 Jun 2013 11:25:23 GMT and browser in the next request doesn't asks for this image. Is it safe to override default bahaviour via disableProxyCaching? Or I am something missing? Or there is a best practice to place images, css styles into another application? === My aps has these part /* - common authenticated content /user/* - content for user /admin/* - content for admin /common/* - common unauthenticated static content like images, css, etc My web.xml security-constraint web-resource-collection web-resource-nameMyApp/web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-namemyapp-admin-role/role-name role-namemyapp-user-role/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameMyApp/web-resource-name url-pattern/admin/*/url-pattern /web-resource-collection auth-constraint role-namemyapp-admin-role/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameMyApp/web-resource-name url-pattern/user/*/url-pattern /web-resource-collection auth-constraint role-namemyapp-user-role/role-name /auth-constraint /security-constraint !-- do not authenticate common -- security-constraint web-resource-collection web-resource-nameMyApp/web-resource-name url-pattern/common/*/url-pattern /web-resource-collection /security-constraint login-config auth-methodFORM/auth-method form-login-config form-login-page/login.jsp/form-login-page form-error-page/login_failed.jsp/form-error-page /form-login-config /login-config security-role role-namemyapp-admin-role/role-name /security-role security-role role-namemyapp-user-role/role-name /security-role Jan. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication and Cache-Control
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jan, On 6/26/13 7:36 AM, Jan Vávra wrote: If I use auth-method FORM, all requests return with headers denying caching on the browser side although I have excluded some part of my app from authentication. The headers for a png image are: HTTP/1.1 304 Not Modified Server: Apache-Coyote/1.1 Cache-Control: private Note that Cache-Control:private does not disable caching. Instead, it disables public-caching for proxies. The browser is still free to cache the document in certain ways. True disabling of the cache would be to set Cache-Control to no-cache or no-store (though no-store is usually more appropriate for controlling proxies and not browsers). If I add disableProxyCaching=false to Valve className=org.apache.catalina.authenticator.FormAuthenticator characterEncoding=utf-8/ at my context.xml the response headers change to: HTTP/1.1 304 Not Modified Server: Apache-Coyote/1.1 ETag: W/3907-1372233712661 Date: Wed, 26 Jun 2013 11:25:23 GMT and browser in the next request doesn't asks for this image. Is it safe to override default bahaviour via disableProxyCaching? Or I am something missing? Or there is a best practice to place images, css styles into another application? What happens with dynamic resources? The reason that cache-disabling is on by default is that having proxies and/or browsers caching resources that were protected by authentication is a potential security or privacy problem. From the documentation for disableProxyCaching: Controls the caching of pages that are protected by security constraints. Setting this to false may help work around caching issues in some browsers but will also cause secured pages to be cached by proxies which will almost certainly be a security issue. securePagesWithPragma offers an alternative, secure, workaround for browser caching issues. If not set, the default value of true will be used. Tomcat can't tell which resources are okay to allow the browser to cache and which aren't. IMO, you might want to think about using a fronting web server to serve your static content (which will not include any headers that would otherwise be sent by Tomcat) and map all dynamic requests to Tomcat. There are certainly other ways to get this done as well, but you may find that configuring your way around this problem is more difficult than you imagined. Is there actually a /problem/ with having Cache-Control:private set on your resources? Have you tried playing with the securePagesWithPragma setting? === My aps has these part /* - common authenticated content /user/* - content for user /admin/* - content for admin /common/* - common unauthenticated static content like images, css, etc My web.xml security-constraint web-resource-collection web-resource-nameMyApp/web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-namemyapp-admin-role/role-name role-namemyapp-user-role/role-name /auth-constraint /security-constraint Technically, the above web-resource-collection is protected, which includes everything on your site. Instead of blanketing the whole site with what amounts to a black-list and then white-listing other resources, why not do the reverse and only use a white-list? That will avoid protecting resources that need not be protected. security-constraint web-resource-collection web-resource-nameMyApp/web-resource-name url-pattern/admin/*/url-pattern /web-resource-collection auth-constraint role-namemyapp-admin-role/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameMyApp/web-resource-name url-pattern/user/*/url-pattern Umm... you have the same url-pattern (/*) in two separate web-resource-collections. Is that intentional? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRyvXoAAoJEBzwKT+lPKRYzUQP/i6zg6UOJbnTUujxHGMGAQSQ 2iQTUMwtBi9mBgmA68EidFFvH48hbD18sZ2GB0A9+JrySy3R2nPC5VphTe2oQ9f8 KY3mVeKeElxTJD03MsufpqcAJQMaffcs9bOEWjzeKmYccZ/ww0UkbIN64oVOcMn5 VJOcm4sqWkLxV4EDAfV3G1DaSkpkhqH3rM3F0FRM1T8eu/TIrVtMdww+BEqzFDr/ wc5qxdjGzWfpctw2J50pk5HV6CmmgFKC1CDe4KS69vQRx6rcQ7HYiERc0NrS2Q2d 8G2KIssa6f210LeVIi5Brp6BK69hkgIPX5OP2ymplCrXLPAIJYgtmiy1RdjP2O3o JCibXKw9VEl+GuvnPR52/6DOTLrzzaSaC1dBqNUADYocywwmwfNQHSJvInlSRqef 77vWTkSs0q+tNCHlg+abfjkh9SsKyyzPxa1hyU7G24bInWWqpNEauM66VUPBdIfq yijA1BovLBgbD0vp4Vw9KmtQwkXys5kCQkwjzChCzWdsCDA5NqTCIz65/Ma1i3K8 pWaBC9l8xHvAMT1G/x0iOqHed2uOJi0Vg1NWmPbnL2aze8BTTMBipQgQAVt9w8/D 38oqEvMwStcbEvH16M0TfzrRB3poAUOlFv3F3Phmb/ERgxPrH156fGa2lOir/8hU epBzsQzMy59rHrcVZe1a =PwLe -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail:
Form Authentication
This is driving me crazy! I have configured from authentication in my web.xml with a number of security constraints. None of the constraints map to any CSS files. However, when I bring up the application the CSS files are hitting the authentication. Since my form has styling this is a problem of the chicken-and-egg sort since the CSS files are not authenticated yet. On top of that, when I do successfully authenticate, the CSS file is the one that has been saved by the authenticator and is the one that is returned so the browser just brings up the raw CSS file. Any thoughts? Ideas? = The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair ---* Douglas Adams*
Re: Form Authentication
Hello, Without knowing how are your security-constraint, and where are the css file, I don't think anyone could help you. Did you try as a last measure to force css file to pass through the authentification, something as : security-constraint web-resource-collectionurl-pattern*.css/url-pattern/web-resource-collection /security-constraint (probably not a valid security-constraint, just to give the idea) I did this kind of thing for the favicon. We had a webapp entirely protected by form authentication and on firefox after authentication we were directed to the favicon.ico (when one existed). Firefox seems to get the favicon after the first request even when the status is 401... So we had to add a special security-constraint for the favicon for our application to work correctly and correct that firefox behavior (I want to say bug, but I'm sure there is a very good explanation for this :). 2013/4/18 Barbara Newton barbara.new...@gmail.com: This is driving me crazy! I have configured from authentication in my web.xml with a number of security constraints. None of the constraints map to any CSS files. However, when I bring up the application the CSS files are hitting the authentication. Since my form has styling this is a problem of the chicken-and-egg sort since the CSS files are not authenticated yet. On top of that, when I do successfully authenticate, the CSS file is the one that has been saved by the authenticator and is the one that is returned so the browser just brings up the raw CSS file. Any thoughts? Ideas? = The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair ---* Douglas Adams* - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication
Thank you for your reply. I figured it out...someone had put a security constrain on / which meant everything ended up passing through the form authenticator. Once I removed the constraint everything started working. So yay for me. = The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair ---* Douglas Adams* On Thu, Apr 18, 2013 at 11:16 AM, Cédric Couralet cedric.coura...@gmail.com wrote: Hello, Without knowing how are your security-constraint, and where are the css file, I don't think anyone could help you. Did you try as a last measure to force css file to pass through the authentification, something as : security-constraint web-resource-collectionurl-pattern*.css/url-pattern/web-resource-collection /security-constraint (probably not a valid security-constraint, just to give the idea) I did this kind of thing for the favicon. We had a webapp entirely protected by form authentication and on firefox after authentication we were directed to the favicon.ico (when one existed). Firefox seems to get the favicon after the first request even when the status is 401... So we had to add a special security-constraint for the favicon for our application to work correctly and correct that firefox behavior (I want to say bug, but I'm sure there is a very good explanation for this :). 2013/4/18 Barbara Newton barbara.new...@gmail.com: This is driving me crazy! I have configured from authentication in my web.xml with a number of security constraints. None of the constraints map to any CSS files. However, when I bring up the application the CSS files are hitting the authentication. Since my form has styling this is a problem of the chicken-and-egg sort since the CSS files are not authenticated yet. On top of that, when I do successfully authenticate, the CSS file is the one that has been saved by the authenticator and is the one that is returned so the browser just brings up the raw CSS file. Any thoughts? Ideas? = The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair ---* Douglas Adams* - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Form Authentication question
I'm looking at the org.apache.catalina.authenticator.FormAuthenticator
class from the 7.0.29 src. This portion of the authenticate method
starting around line 301 is where I'm having a little problem:
if (log.isDebugEnabled()) {
log.debug(Authentication of ' + username + ' was successful);
}
if (session == null) {
session = request.getSessionInternal(false);
}
if (session == null) {
if (containerLog.isDebugEnabled()) {
containerLog.debug
(User took so long to log on the session expired);
}
if (landingPage == null) {
response.sendError(HttpServletResponse.SC_REQUEST_TIMEOUT,
sm.getString(authenticator.sessionExpired));
} else {
// Make the authenticator think the user originally requested
// the landing page
String uri = request.getContextPath() + landingPage;
SavedRequest saved = new SavedRequest();
saved.setMethod(GET);
saved.setRequestURI(uri);
request.getSessionInternal(true).setNote(
Constants.FORM_REQUEST_NOTE, saved);
response.sendRedirect(response.encodeRedirectURL(uri));
}
return (false);
}
If the user sits too long on the login page the session times out, even
if their credentials were authenticated successfully, and sends them
back to the login page where they must re-enter their credentials. It
works this way even if I define a landingPage. Without a landingPage I
get the dreaded 408 error.
Can anyone enlighten me as to why it's a bad idea if:
if (session == null) {
session = request.getSessionInternal(false);
}
is instead:
if (session == null) {
session = request.getSessionInternal(true);
}
Thanks,
Kris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication question
On 30/07/2012 21:24, Kris Easter wrote:
I'm looking at the org.apache.catalina.authenticator.FormAuthenticator
class from the 7.0.29 src. This portion of the authenticate method
starting around line 301 is where I'm having a little problem:
if (log.isDebugEnabled()) {
log.debug(Authentication of ' + username + ' was successful);
}
if (session == null) {
session = request.getSessionInternal(false);
}
if (session == null) {
if (containerLog.isDebugEnabled()) {
containerLog.debug
(User took so long to log on the session expired);
}
if (landingPage == null) {
response.sendError(HttpServletResponse.SC_REQUEST_TIMEOUT,
sm.getString(authenticator.sessionExpired));
} else {
// Make the authenticator think the user originally requested
// the landing page
String uri = request.getContextPath() + landingPage;
SavedRequest saved = new SavedRequest();
saved.setMethod(GET);
saved.setRequestURI(uri);
request.getSessionInternal(true).setNote(
Constants.FORM_REQUEST_NOTE, saved);
response.sendRedirect(response.encodeRedirectURL(uri));
}
return (false);
}
If the user sits too long on the login page the session times out, even
if their credentials were authenticated successfully, and sends them
back to the login page where they must re-enter their credentials. It
works this way even if I define a landingPage. Without a landingPage I
get the dreaded 408 error.
Can anyone enlighten me as to why it's a bad idea if:
if (session == null) {
session = request.getSessionInternal(false);
}
is instead:
if (session == null) {
session = request.getSessionInternal(true);
}
Because the session defines where to go after the authentication i.e.
which page the user requested originally. I suppose we could allow the
user to transition to the landing page in that case.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication question
On Mon, 2012-07-30 at 14:36 -0600, Mark Thomas wrote:
On 30/07/2012 21:24, Kris Easter wrote:
...
If the user sits too long on the login page the session times out, even
if their credentials were authenticated successfully, and sends them
back to the login page where they must re-enter their credentials. It
works this way even if I define a landingPage. Without a landingPage I
get the dreaded 408 error.
Can anyone enlighten me as to why it's a bad idea if:
if (session == null) {
session = request.getSessionInternal(false);
}
is instead:
if (session == null) {
session = request.getSessionInternal(true);
}
Because the session defines where to go after the authentication i.e.
which page the user requested originally. I suppose we could allow the
user to transition to the landing page in that case.
Mark
That would be preferable for my use case.
Kris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
I've done all the basic troubleshooting tweaks I can think of, trying 7.0.25 and 7.0.23, switching my web.xml back to the 2.5 spec level, reducing from a combination of 2 JNDI realms to 1, cranking lots of loggers up to full verbosity, etc. In all cases I lose the POST parameters. I guess I either ignore this (ouch) or really dig into debugging Tomcat's internals (which while far easier than trying to do so with httpd is still not where I'd wanted to spend my time). -- Jess Holle On 2/4/2012 5:49 PM, Jess Holle wrote: Yes, I'm using Tomcat authentication. Yes, the issue is after authentication on the POST retry. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
2012/2/5 Jess Holle je...@ptc.com: I've done all the basic troubleshooting tweaks I can think of, trying 7.0.25 and 7.0.23, switching my web.xml back to the 2.5 spec level, reducing from a combination of 2 JNDI realms to 1, cranking lots of loggers up to full verbosity, etc. In all cases I lose the POST parameters. 1. You have to pay attention to Cookie/Set-Cookie headers that are sent between Server and Client. The value there is session id. Just a note: upon successful authentication there should be one more Set-Cookie header sent by the server, because session id will be changed (but not the session itself). You can use browser plugins (like Firefox Live Http Headers or Firebug), network sniffers (Wireshark) or just configure your access log to log those headers. The standard Tomcat Manager web application can be used to inspect active sessions and their attributes. 2. Enable debug logging for FormAuthenticator class. org.apache.catalina.authenticator.FormAuthenticator.level=FINE If you configure logging to use OneLineFormatter, it will include thread id and it will be easier to match it against access log (if access log is configured to print thread ids as well). E.g. 1catalina.org.apache.juli.FileHandler.formatter = org.apache.juli.OneLineFormatter I guess I either ignore this (ouch) or really dig into debugging Tomcat's internals (which while far easier than trying to do so with httpd is still not where I'd wanted to spend my time). http://wiki.apache.org/tomcat/FAQ/Developing#Debugging Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
On 2/5/2012 8:29 AM, Konstantin Kolinko wrote: 2012/2/5 Jess Holleje...@ptc.com: I've done all the basic troubleshooting tweaks I can think of, trying 7.0.25 and 7.0.23, switching my web.xml back to the 2.5 spec level, reducing from a combination of 2 JNDI realms to 1, cranking lots of loggers up to full verbosity, etc. In all cases I lose the POST parameters. 1. You have to pay attention to Cookie/Set-Cookie headers that are sent between Server and Client. The value there is session id. Just a note: upon successful authentication there should be one more Set-Cookie header sent by the server, because session id will be changed (but not the session itself). You can use browser plugins (like Firefox Live Http Headers or Firebug), network sniffers (Wireshark) or just configure your access log to log those headers. The standard Tomcat Manager web application can be used to inspect active sessions and their attributes. Nothing appears to be amiss with respect to Set-Cookie and Cookie headers. 2. Enable debug logging for FormAuthenticator class. org.apache.catalina.authenticator.FormAuthenticator.level=FINE If you configure logging to use OneLineFormatter, it will include thread id and it will be easier to match it against access log (if access log is configured to print thread ids as well). E.g. 1catalina.org.apache.juli.FileHandler.formatter = org.apache.juli.OneLineFormatter I had already increased verbosity for FormAuthenticator -- nothing seemed amiss from what I could tell there. It /said/ it was restoring the original request from the session. I never see anything about a POST body being restored, but I'm not sure if there is any logging to this effect. http://wiki.apache.org/tomcat/FAQ/Developing#Debugging Thanks. I've got that part down. The harder part is rebuilding pieces of Tomcat with full debug information (I'm assuming Tomcat is normally not built with local variable debug information) and finding my way through unfamiliar code. But that's life :-) -- Jess Holle
Re: Form Authentication POST data not preserved?
2012/2/5 Jess Holle je...@ptc.com:
On 2/5/2012 8:29 AM, Konstantin Kolinko wrote:
2. Enable debug logging for FormAuthenticator class.
org.apache.catalina.authenticator.FormAuthenticator.level=FINE
(...)
I had already increased verbosity for FormAuthenticator -- nothing seemed
amiss from what I could tell there. It said it was restoring the original
request from the session. I never see anything about a POST body being
restored, but I'm not sure if there is any logging to this effect.
http://wiki.apache.org/tomcat/FAQ/Developing#Debugging
Thanks. I've got that part down. The harder part is rebuilding pieces of
Tomcat with full debug information (I'm assuming Tomcat is normally not
built with local variable debug information) and finding my way through
unfamiliar code. But that's life :-)
build.xml:
javac srcdir=java destdir=${tomcat.classes}
debug=${compile.debug}
deprecation=${compile.deprecation}
source=${compile.source}
target=${compile.target}
optimize=${compile.optimize}
excludes=**/.svn/**
encoding=ISO-8859-1
includeAntRuntime=true
build.properties.default:
compile.debug=true
Thus debug information should already be there.
I usually start with setting some breakpoints. In your case take a
look at FormAuthenticator#saveRequest() and #restoreRequest() methods
and where they are called from.
Building Tomcat is documented in BUILDING.txt and in webapps/docs/building.html
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
On 2/5/2012 9:26 AM, Konstantin Kolinko wrote:
build.xml:
javac srcdir=java destdir=${tomcat.classes}
debug=${compile.debug}
deprecation=${compile.deprecation}
source=${compile.source}
target=${compile.target}
optimize=${compile.optimize}
excludes=**/.svn/**
encoding=ISO-8859-1
includeAntRuntime=true
build.properties.default:
compile.debug=true
Thus debug information should already be there.
I usually start with setting some breakpoints. In your case take a
look at FormAuthenticator#saveRequest() and #restoreRequest() methods
and where they are called from.
Thanks. I've already seen via a heap dump that the request is saved
with the correct content body. So now the only question that remains is
why it does not get restored.
--
Jess Holle
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
On 2/5/2012 9:43 AM, Jess Holle wrote:
On 2/5/2012 9:26 AM, Konstantin Kolinko wrote:
build.xml:
javac srcdir=java destdir=${tomcat.classes}
debug=${compile.debug}
deprecation=${compile.deprecation}
source=${compile.source}
target=${compile.target}
optimize=${compile.optimize}
excludes=**/.svn/**
encoding=ISO-8859-1
includeAntRuntime=true
build.properties.default:
compile.debug=true
Thus debug information should already be there.
I usually start with setting some breakpoints. In your case take a
look at FormAuthenticator#saveRequest() and #restoreRequest() methods
and where they are called from.
Thanks. I've already seen via a heap dump that the request is saved
with the correct content body. So now the only question that remains
is why it does not get restored.
Diving in deeper, I see that AbstractAjpProcessor.action() is setting
the bodyBytes perfectly for the ActionCode.REQ_SET_BODY_REPLAY case here.
After that is done, however, I don't see anything that tries to read
AbstractAjpProcessor.bodyBytes.
org.apache.catalina.connector.Request.readPostBody() seems to completely
ignore this data.
I'm thinking some refactoring in this area completely broke this use
case at least for the AJP BIO path. Or can someone offer evidence that
the breakage is less general than this?
--
Jess Holle
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
On 2/5/2012 10:38 AM, Jess Holle wrote: Diving in deeper, I see that AbstractAjpProcessor.action() is setting the bodyBytes perfectly for the ActionCode.REQ_SET_BODY_REPLAY case here. After that is done, however, I don't see anything that tries to read AbstractAjpProcessor.bodyBytes. org.apache.catalina.connector.Request.readPostBody() seems to completely ignore this data. I'm thinking some refactoring in this area completely broke this use case at least for the AJP BIO path. Or can someone offer evidence that the breakage is less general than this? I'm not seeing any evidence as to how org.apache.catalina.connector.Request is convinced to use the new bodyBytes from AbstractAjpProcessor here, neither in 7.0.25 or looking back at previous tags. Am I missing something here? Note that I can see how the HTTP connectors could work in this regard -- I'm just not seeing how the AJP connectors could. -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
2012/2/5 Jess Holle je...@ptc.com:
On 2/5/2012 9:43 AM, Jess Holle wrote:
On 2/5/2012 9:26 AM, Konstantin Kolinko wrote:
build.xml:
javac srcdir=java destdir=${tomcat.classes}
debug=${compile.debug}
deprecation=${compile.deprecation}
source=${compile.source}
target=${compile.target}
optimize=${compile.optimize}
excludes=**/.svn/**
encoding=ISO-8859-1
includeAntRuntime=true
build.properties.default:
compile.debug=true
Thus debug information should already be there.
I usually start with setting some breakpoints. In your case take a
look at FormAuthenticator#saveRequest() and #restoreRequest() methods
and where they are called from.
Thanks. I've already seen via a heap dump that the request is saved with
the correct content body. So now the only question that remains is why it
does not get restored.
Diving in deeper, I see that AbstractAjpProcessor.action() is setting the
bodyBytes perfectly for the ActionCode.REQ_SET_BODY_REPLAY case here.
After that is done, however, I don't see anything that tries to read
AbstractAjpProcessor.bodyBytes.
org.apache.catalina.connector.Request.readPostBody() seems to completely
ignore this data.
I'm thinking some refactoring in this area completely broke this use case at
least for the AJP BIO path. Or can someone offer evidence that the breakage
is less general than this?
I think this issue is specific to AJP.
For HTTP connectors a similar issue was noted and fixed here:
https://issues.apache.org/bugzilla/show_bug.cgi?id=51940#c9
I think adding the following line to REQ_SET_BODY_REPLAY case in
AbstractAjpProcessor#action() will fix this bug:
endOfStream = false;
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
On 2/5/2012 11:15 AM, Konstantin Kolinko wrote: I think this issue is specific to AJP. For HTTP connectors a similar issue was noted and fixed here: https://issues.apache.org/bugzilla/show_bug.cgi?id=51940#c9 I think adding the following line to REQ_SET_BODY_REPLAY case in AbstractAjpProcessor#action() will fix this bug: endOfStream = false; That did the trick! [I just did this via the debugger without a rebuild, but same thing.] Could someone please patch this into trunk so it's in the next Tomcat release? Until then I can certainly patch it into my own Tomcat. I just don't want to maintain this patch forever (nor have everyone else suffer from this bug in the AJP case). -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
On 2/5/2012 11:22 AM, Jess Holle wrote: On 2/5/2012 11:15 AM, Konstantin Kolinko wrote: I think this issue is specific to AJP. For HTTP connectors a similar issue was noted and fixed here: https://issues.apache.org/bugzilla/show_bug.cgi?id=51940#c9 I think adding the following line to REQ_SET_BODY_REPLAY case in AbstractAjpProcessor#action() will fix this bug: endOfStream = false; That did the trick! [I just did this via the debugger without a rebuild, but same thing.] Could someone please patch this into trunk so it's in the next Tomcat release? By patch, I mean commit, of course :-) Until then I can certainly patch it into my own Tomcat. I just don't want to maintain this patch forever (nor have everyone else suffer from this bug in the AJP case). -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [somewhat OT] Form Authentication POST data not preserved?
Hi. I've just been following this thread, and this is not about the problem per se, but a comment about the overall design of the application. The fact that you do a POST without being authenticated, and that you rely on the server to save the POST content while the authentication is taking place, and to replay this POST after a succesful authentication, is not really a part of the HTTP protocol (as per RFC 2616). It is a nice feature of Tomcat, and it simplifies the design of an application, and it avoids some user frustration. And maybe the paragraph cited below from the Servlet Spec is what motivates Tomcat to implement this. But I don't think tjat you can count on this behaviour with all HTTP servers, or all authentication schemes. For example, if instead of using Tomcat's container-driven authentication (declarative security), your application came at some point to have to use a servlet-filter based authentication mechanism (programmatic security), this design may not work anymore (unless the filter itself had some POST-saving scheme). Just thought I'd point that out. Servlet Spec 3.0, 13.6.3.1 : ... If the form based login is invoked because of an HTTP request, the original request parameters must be preserved by the container for use if, on successful authentication, it redirects the call to the requested resource. ... Note the if. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
On 2/5/2012 11:24 AM, Jess Holle wrote: On 2/5/2012 11:22 AM, Jess Holle wrote: On 2/5/2012 11:15 AM, Konstantin Kolinko wrote: I think this issue is specific to AJP. For HTTP connectors a similar issue was noted and fixed here: https://issues.apache.org/bugzilla/show_bug.cgi?id=51940#c9 I think adding the following line to REQ_SET_BODY_REPLAY case in AbstractAjpProcessor#action() will fix this bug: endOfStream = false; That did the trick! [I just did this via the debugger without a rebuild, but same thing.] Could someone please patch this into trunk so it's in the next Tomcat release? By patch, I mean commit, of course :-) Until then I can certainly patch it into my own Tomcat. I just don't want to maintain this patch forever (nor have everyone else suffer from this bug in the AJP case). Also it strikes me that maxSavePostSize should really be backed up by a use of a SoftReference in SavedRequest. This would allow one to allow relatively large POST bodies to be saved unless/until this threatened to consume the JVM's overall memory resources, at which point the POST bodies could be dropped. As it stands now one has to choose between vicious treatment of large POST bodies (i.e. dropping all the user's data) and opening oneself wide open to quick and easy (and possibly accidental) DOS attacks. -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
2012/2/5 Jess Holle je...@ptc.com: On 2/5/2012 11:15 AM, Konstantin Kolinko wrote: I think this issue is specific to AJP. For HTTP connectors a similar issue was noted and fixed here: https://issues.apache.org/bugzilla/show_bug.cgi?id=51940#c9 I think adding the following line to REQ_SET_BODY_REPLAY case in AbstractAjpProcessor#action() will fix this bug: endOfStream = false; That did the trick! [I just did this via the debugger without a rebuild, but same thing.] Could someone please patch this into trunk so it's in the next Tomcat release? Until then I can certainly patch it into my own Tomcat. I just don't want to maintain this patch forever (nor have everyone else suffer from this bug in the AJP case). I filed a bug https://issues.apache.org/bugzilla/show_bug.cgi?id=52606 It would be nice to know whether this problem is observable with 6.0.35 or not. 2012/2/5 Jess Holle je...@ptc.com: Also it strikes me that maxSavePostSize should really be backed up by a use of a SoftReference in SavedRequest. This would allow one to allow relatively large POST bodies to be saved unless/until this threatened to consume the JVM's overall memory resources, at which point the POST bodies could be dropped. As it stands now one has to choose between vicious treatment of large POST bodies (i.e. dropping all the user's data) and opening oneself wide open to quick and easy (and possibly accidental) DOS attacks. Interesting idea. I think it is worth filing an enhancement request. Though I see the following caveat: Using SoftReference here will lead to non-deterministic behaviour. I wonder whether admins will be puzzled by this feature. Though this can be solved by logging an INFO message wrapped by org.apache.juli.logging.UserDataHelper. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [somewhat OT] Form Authentication POST data not preserved?
On 2/5/2012 12:04 PM, André Warnier wrote: Hi. I've just been following this thread, and this is not about the problem per se, but a comment about the overall design of the application. The fact that you do a POST without being authenticated, and that you rely on the server to save the POST content while the authentication is taking place, and to replay this POST after a succesful authentication, is not really a part of the HTTP protocol (as per RFC 2616). Form-based authentication is not part of the HTTP protocol. The entirety of form-based authentication is a complete hack of an application convention. Some specifications, e.g. the Java servlet specification, provide /some/ rules for form-based authentication within their realm, but in general form-based authentication is an anything goes that a user running an interactive browser session can follow convention. It is a nice feature of Tomcat, and it simplifies the design of an application, and it avoids some user frustration. And maybe the paragraph cited below from the Servlet Spec is what motivates Tomcat to implement this. But I don't think tjat you can count on this behaviour with all HTTP servers, or all authentication schemes. For example, if instead of using Tomcat's container-driven authentication (declarative security), your application came at some point to have to use a servlet-filter based authentication mechanism (programmatic security), this design may not work anymore (unless the filter itself had some POST-saving scheme). Just thought I'd point that out. Certainly this is an optional / quality of implementation feature. I'm perfectly aware that other form-based authentication solutions will not save POST data and may even fail to replay requests at all. That's fine and good. The application design is not dependent on this behavior. Rather, Tomcat documentation says this should work and it doesn't -- that's the issue. Of course this isn't just an application design issue. If you're in the midst of your application, fill out a complex form, go out to lunch, come back and submit the form chances are good your session will have timed out. In this case, you really want to have POST body capture working -- otherwise usability will suffer. Servlet Spec 3.0, 13.6.3.1 : ... If the form based login is invoked because of an HTTP request, the original request parameters must be preserved by the container for use if, on successful authentication, it redirects the call to the requested resource. ... Note the if. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
On 2/5/2012 12:22 PM, Konstantin Kolinko wrote: 2012/2/5 Jess Holle je...@ptc.com: Also it strikes me that maxSavePostSize should really be backed up by a use of a SoftReference in SavedRequest. This would allow one to allow relatively large POST bodies to be saved unless/until this threatened to consume the JVM's overall memory resources, at which point the POST bodies could be dropped. As it stands now one has to choose between vicious treatment of large POST bodies (i.e. dropping all the user's data) and opening oneself wide open to quick and easy (and possibly accidental) DOS attacks. Interesting idea. I think it is worth filing an enhancement request. Though I see the following caveat: Using SoftReference here will lead to non-deterministic behaviour. I wonder whether admins will be puzzled by this feature. Though this can be solved by logging an INFO message wrapped by org.apache.juli.logging.UserDataHelper. Yeah, there is the element of uncertainty as to how strongly a SoftReference really holds on to its data, etc. This would be nice opt in behavior if nothing else. -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [somewhat OT] Form Authentication POST data not preserved?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jess, On 2/5/12 1:23 PM, Jess Holle wrote: Certainly this is an optional / quality of implementation feature. I'm perfectly aware that other form-based authentication solutions will not save POST data and may even fail to replay requests at all. That's fine and good. The application design is not dependent on this behavior. Rather, Tomcat documentation says this should work and it doesn't -- that's the issue. FWIW, SecurityFilter also provides similar capabilities. I'd be shocked if this wasn't industry-wide capability for servlet containers. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8u7EkACgkQ9CaO5/Lv0PDZ0ACghcEXQ7pTElJawGg64eFQFkKS 0swAn3hcVSNeaEx9D9sXI5ZJN6ASwKhL =Azqj -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [somewhat OT] Form Authentication POST data not preserved?
On 2/5/2012 2:53 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jess, On 2/5/12 1:23 PM, Jess Holle wrote: Certainly this is an optional / quality of implementation feature. I'm perfectly aware that other form-based authentication solutions will not save POST data and may even fail to replay requests at all. That's fine and good. The application design is not dependent on this behavior. Rather, Tomcat documentation says this should work and it doesn't -- that's the issue. FWIW, SecurityFilter also provides similar capabilities. I'd be shocked if this wasn't industry-wide capability for servlet containers. I was considering form-based authentication on an even broader basis -- as one can do this in the web server as instead of in the servlet engine. That said, yes, most solutions do cover this base -- and Tomcat says it does, but doesn't if you use an AJP connector. Fortunately the fix is trivial to patch in. -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jess, On 2/3/12 5:59 PM, Jess Holle wrote: Or could this be getting loused up by having a servlet request filter that calls getParameterMap() first thing? I'd *assume* not -- as that would be pretty hokey... Probably not: Tomcat's valves (including the one that performs authentication) all fire before any of the webapp-specified filters run. In any case, the problem you observe is *after* authentication when the POST should be re-tried, right? Silly question: you *are* using Tomcat's authentication, right? I mean, if you're using something else like ACEGI (does that even still exist -- other than as Spring Security?) then you'll have to look somewhere else. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8teKEACgkQ9CaO5/Lv0PAmYwCeI0qfe5iNv/8X3z3eN4PyKtm1 6YYAoKteM140ZuIVbr9e01IP9aZf+rZq =aUyr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Konstantin, On 2/3/12 6:26 PM, Konstantin Kolinko wrote: 2012/2/4 Jess Holle je...@ptc.com: I posted a query recently wherein I thought that POST data was being lost *only* if the user had been authenticated, their session timed out, and then they POST'ed to a URL requiring authentication -- thus having their request interrupted for a form-based login. I know Tomcat is supposed to preserve the POST data in this case as well as in the case where one had not yet authenticated prior to the POST, but I'd thought that the latter case worked. As someone nicely pointed out, that makes no sense. Why? The saved data is kept in session. If session times out (that means: it is removed from the server) the data that was kept in it becomes lost as well as the session itself. It was I who said it made no sense, and here's why: my understanding of Jess's situation was that he was comparing the following two cases and saying that they behaved differently: Case 1: a. User logs in b. User navigates to POST form c. Session times out d. User POSTs form e. Login form is shown f. User authenticates successfully g. Form data is successfully re-POSTed (*) * Jess is now saying that step (g) actually fails Case 2: a. User has never logged-in, yet sits on a POST form page b. User POSTs form c. Login form is shown d. User authenticates successfully e. Form data faild to be re-POSTed Since Tomcat cannot actually differentiate between these two cases, observing them behaving differently seems suspicious. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8tee0ACgkQ9CaO5/Lv0PDf+ACaA6It3MZPPXtMxasCDQ48/E2s w7AAnjesutw2xiigAwSFOEST5f3uS4LA =M+n3 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
Yes, I'm using Tomcat authentication. Yes, the issue is after authentication on the POST retry. On 2/4/2012 12:27 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jess, On 2/3/12 5:59 PM, Jess Holle wrote: Or could this be getting loused up by having a servlet request filter that calls getParameterMap() first thing? I'd *assume* not -- as that would be pretty hokey... Probably not: Tomcat's valves (including the one that performs authentication) all fire before any of the webapp-specified filters run. In any case, the problem you observe is *after* authentication when the POST should be re-tried, right? Silly question: you *are* using Tomcat's authentication, right? I mean, if you're using something else like ACEGI (does that even still exist -- other than as Spring Security?) then you'll have to look somewhere else. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8teKEACgkQ9CaO5/Lv0PAmYwCeI0qfe5iNv/8X3z3eN4PyKtm1 6YYAoKteM140ZuIVbr9e01IP9aZf+rZq =aUyr -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
Form Authentication POST data not preserved?
I posted a query recently wherein I thought that POST data was being lost *only* if the user had been authenticated, their session timed out, and then they POST'ed to a URL requiring authentication -- thus having their request interrupted for a form-based login. I know Tomcat is supposed to preserve the POST data in this case as well as in the case where one had not yet authenticated prior to the POST, but I'd thought that the latter case worked. As someone nicely pointed out, that makes no sense. So here's the issue: Neither case works. My POST data is always lost here. I've tried various values of maxSavePostSize, including leaving it unspecified -- to no avail. [I had it set to -1 and maxPostSize also set to -1, which I also tried leaving unspecified.] I've tried various things -- all with no luck. This is with Tomcat 7.0.23. I'm pretty sure I was having similar issues with 7.0.25 as well. [No, I didn't really downgrade -- I'm just working in a context that's still using 7.0.23 at the moment.] I'm left wondering what could be causing the issue. -- Jess Holle P.S. The lack of wisdom of setting maxSavePostSize is clear enough to me now. I'll be setting this to a large but still not egregious value once I figure out the rest of this... - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
In case this makes any difference this is with the AJP BIO connector. On 2/3/2012 4:51 PM, Jess Holle wrote: I posted a query recently wherein I thought that POST data was being lost *only* if the user had been authenticated, their session timed out, and then they POST'ed to a URL requiring authentication -- thus having their request interrupted for a form-based login. I know Tomcat is supposed to preserve the POST data in this case as well as in the case where one had not yet authenticated prior to the POST, but I'd thought that the latter case worked. As someone nicely pointed out, that makes no sense. So here's the issue: Neither case works. My POST data is always lost here. I've tried various values of maxSavePostSize, including leaving it unspecified -- to no avail. [I had it set to -1 and maxPostSize also set to -1, which I also tried leaving unspecified.] I've tried various things -- all with no luck. This is with Tomcat 7.0.23. I'm pretty sure I was having similar issues with 7.0.25 as well. [No, I didn't really downgrade -- I'm just working in a context that's still using 7.0.23 at the moment.] I'm left wondering what could be causing the issue. -- Jess Holle P.S. The lack of wisdom of setting maxSavePostSize is clear enough to me now. I'll be setting this to a large but still not egregious value once I figure out the rest of this... - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
Or could this be getting loused up by having a servlet request filter that calls getParameterMap() first thing? I'd *assume* not -- as that would be pretty hokey... On 2/3/2012 4:53 PM, Jess Holle wrote: In case this makes any difference this is with the AJP BIO connector. On 2/3/2012 4:51 PM, Jess Holle wrote: I posted a query recently wherein I thought that POST data was being lost *only* if the user had been authenticated, their session timed out, and then they POST'ed to a URL requiring authentication -- thus having their request interrupted for a form-based login. I know Tomcat is supposed to preserve the POST data in this case as well as in the case where one had not yet authenticated prior to the POST, but I'd thought that the latter case worked. As someone nicely pointed out, that makes no sense. So here's the issue: Neither case works. My POST data is always lost here. I've tried various values of maxSavePostSize, including leaving it unspecified -- to no avail. [I had it set to -1 and maxPostSize also set to -1, which I also tried leaving unspecified.] I've tried various things -- all with no luck. This is with Tomcat 7.0.23. I'm pretty sure I was having similar issues with 7.0.25 as well. [No, I didn't really downgrade -- I'm just working in a context that's still using 7.0.23 at the moment.] I'm left wondering what could be causing the issue. -- Jess Holle P.S. The lack of wisdom of setting maxSavePostSize is clear enough to me now. I'll be setting this to a large but still not egregious value once I figure out the rest of this... - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
2012/2/4 Jess Holle je...@ptc.com: I posted a query recently wherein I thought that POST data was being lost *only* if the user had been authenticated, their session timed out, and then they POST'ed to a URL requiring authentication -- thus having their request interrupted for a form-based login. I know Tomcat is supposed to preserve the POST data in this case as well as in the case where one had not yet authenticated prior to the POST, but I'd thought that the latter case worked. As someone nicely pointed out, that makes no sense. Why? The saved data is kept in session. If session times out (that means: it is removed from the server) the data that was kept in it becomes lost as well as the session itself. Or maybe I do not quite understand you (try rephrase your statements, listing the events in chronological order). The session is created once the session-id cookie is sent to the user. That happens before authentication. (...) P.S. The lack of wisdom of setting maxSavePostSize is clear enough to me now. I'll be setting this to a large but still not egregious value once I figure out the rest of this... Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
On 2/3/2012 5:26 PM, Konstantin Kolinko wrote: 2012/2/4 Jess Holleje...@ptc.com: I posted a query recently wherein I thought that POST data was being lost *only* if the user had been authenticated, their session timed out, and then they POST'ed to a URL requiring authentication -- thus having their request interrupted for a form-based login. I know Tomcat is supposed to preserve the POST data in this case as well as in the case where one had not yet authenticated prior to the POST, but I'd thought that the latter case worked. As someone nicely pointed out, that makes no sense. Why? The saved data is kept in session. If session times out (that means: it is removed from the server) the data that was kept in it becomes lost as well as the session itself. Or maybe I do not quite understand you (try rephrase your statements, listing the events in chronological order). How's this? Case 1: 1. Browse to (anonymously accessible) data entry form without having logged in yet 2. Click to POST data to authenticated result page URL 3. Fill in login form 4. See result page Case 2: 1. Log in 2. Browse to data entry form (anonymous or otherwise) 3. Allow session to time out (or force this on the server) 4. Click to POST data to authenticated result page URL 5. Fill in login form 6. See result page I'd expect to see the results in both cases reflect the POST data. Initially I had thought that Case #1 worked but Case #2 didn't. That makes no sense -- as others pointed out. Now I see that neither case works. -- Jess Holle
Tomcat Form Authentication Timeout Behavior
I've noticed that if I POST to an authenticated URL in a web app configured for form-based authentication, Tomcat delivers the login form, and then replays the POST just fine *unless* the current state of the browser is one where I had already been authenticated but that session had timed out. In that case, Tomcat fails to deliver the POST data. I assume this is a known issue/limitation. If not, is there some configuration setting I'm missing or some such? This is with Tomcat 7.0.23. -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Form Authentication Timeout Behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jess, On 2/1/12 2:10 PM, Jess Holle wrote: I've noticed that if I POST to an authenticated URL in a web app configured for form-based authentication, Tomcat delivers the login form, and then replays the POST just fine *unless* the current state of the browser is one where I had already been authenticated but that session had timed out. In that case, Tomcat fails to deliver the POST data. I assume this is a known issue/limitation. If not, is there some configuration setting I'm missing or some such? This is with Tomcat 7.0.23. If you are logged-in and experience a timeout while you stare at a POST form, the next POST should ask for your credentials and then re-POST the form. Your description about seems to claim that Tomcat can somehow tell the difference between a POST to a timed-out session and a post to a session which never existed. Tomcat does not keep old sessions around for the purposes of messing up your flows. Are you sure you are describing your observations properly? Tomcat *does* have a maximum size for a saved post (see http://tomcat.apache.org/tomcat-7.0-doc/config/http.html, maxSavePostSize - the default is 4kb). I actually don't know what happens if the POST size exceeds this value since I've never needed more than the default. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8plDEACgkQ9CaO5/Lv0PC2OgCgr27LjLMrycQrWS4dEgH4qsiM kzQAn3rWP/BUT/wbKiQudxMYLpiNnQC4 =jybe -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication vs. Tomcat Restart
I should have noted that this is with Tomcat 7.0.23, but it seemed unlikely to be JVM (Java 6 Update 29) or OS (Windows 7) specific. Of course given that I found that the documentation clearly states this behavior, I suspect this is longstanding Tomcat behavior. My remaining question is /why/ Tomcat behaves this way. If one quickly restarts Tomcat for some reason and session data is preserved, you really don't want all the users to have to login again do you? -- Jess Holle On 12/6/2011 7:05 PM, André Warnier wrote: Jess Holle wrote: When doing a graceful shutdown of Tomcat, the sessions are persisted to disk and then re-read on startup (at least in all reasonably recent versions). Oddly, however, form-based authentication does not seem to survive a graceful restart. Rather one has to log in again. Is this known? Intentional? Configurable? There should be a template for messages on this list : Tomcat version : Java version : platform OS version : - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication vs. Tomcat Restart
Tomcat does that for every all Form Authentication even if you used `DatabaseRealm` it doesn't save logged user. On Wed, Dec 7, 2011 at 2:24 PM, Jess Holle je...@ptc.com wrote: I should have noted that this is with Tomcat 7.0.23, but it seemed unlikely to be JVM (Java 6 Update 29) or OS (Windows 7) specific. Of course given that I found that the documentation clearly states this behavior, I suspect this is longstanding Tomcat behavior. My remaining question is /why/ Tomcat behaves this way. If one quickly restarts Tomcat for some reason and session data is preserved, you really don't want all the users to have to login again do you? -- Jess Holle On 12/6/2011 7:05 PM, André Warnier wrote: Jess Holle wrote: When doing a graceful shutdown of Tomcat, the sessions are persisted to disk and then re-read on startup (at least in all reasonably recent versions). Oddly, however, form-based authentication does not seem to survive a graceful restart. Rather one has to log in again. Is this known? Intentional? Configurable? There should be a template for messages on this list : Tomcat version : Java version : platform OS version : --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication vs. Tomcat Restart
Yes, I now note this in the documentation. The question remains, however: /why /does it work this way? On 12/7/2011 6:34 AM, Mohammad M. AbuZer wrote: Tomcat does that for every all Form Authentication even if you used `DatabaseRealm` it doesn't save logged user. On Wed, Dec 7, 2011 at 2:24 PM, Jess Holleje...@ptc.com wrote: I should have noted that this is with Tomcat 7.0.23, but it seemed unlikely to be JVM (Java 6 Update 29) or OS (Windows 7) specific. Of course given that I found that the documentation clearly states this behavior, I suspect this is longstanding Tomcat behavior. My remaining question is /why/ Tomcat behaves this way. If one quickly restarts Tomcat for some reason and session data is preserved, you really don't want all the users to have to login again do you? -- Jess Holle On 12/6/2011 7:05 PM, André Warnier wrote: Jess Holle wrote: When doing a graceful shutdown of Tomcat, the sessions are persisted to disk and then re-read on startup (at least in all reasonably recent versions). Oddly, however, form-based authentication does not seem to survive a graceful restart. Rather one has to log in again. Is this known? Intentional? Configurable? There should be a template for messages on this list : Tomcat version : Java version : platform OS version : --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication vs. Tomcat Restart
2011/12/7 Jess Holle je...@ptc.com: I should have noted that this is with Tomcat 7.0.23, but it seemed unlikely to be JVM (Java 6 Update 29) or OS (Windows 7) specific. Of course given that I found that the documentation clearly states this behavior, I suspect this is longstanding Tomcat behavior. My remaining question is /why/ Tomcat behaves this way. If one quickly restarts Tomcat for some reason and session data is preserved, you really don't want all the users to have to login again do you? I think there are a simple reason: The data contain user's password. You wouldn't want the password to be written to disk. It is safer if it is kept in memory only. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication vs. Tomcat Restart
It should serialize User and Principles nothing more, no need for password. On Wed, Dec 7, 2011 at 4:12 PM, Konstantin Kolinko knst.koli...@gmail.comwrote: 2011/12/7 Jess Holle je...@ptc.com: I should have noted that this is with Tomcat 7.0.23, but it seemed unlikely to be JVM (Java 6 Update 29) or OS (Windows 7) specific. Of course given that I found that the documentation clearly states this behavior, I suspect this is longstanding Tomcat behavior. My remaining question is /why/ Tomcat behaves this way. If one quickly restarts Tomcat for some reason and session data is preserved, you really don't want all the users to have to login again do you? I think there are a simple reason: The data contain user's password. You wouldn't want the password to be written to disk. It is safer if it is kept in memory only. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication vs. Tomcat Restart
2011/12/7 Mohammad M. AbuZer m.abuze...@gmail.com: It should serialize User and Principles nothing more, no need for password. On Wed, Dec 7, 2011 at 4:12 PM, Konstantin Kolinko knst.koli...@gmail.comwrote: 2011/12/7 Jess Holle je...@ptc.com: I should have noted that this is with Tomcat 7.0.23, but it seemed unlikely to be JVM (Java 6 Update 29) or OS (Windows 7) specific. Of course given that I found that the documentation clearly states this behavior, I suspect this is longstanding Tomcat behavior. My remaining question is /why/ Tomcat behaves this way. If one quickly restarts Tomcat for some reason and session data is preserved, you really don't want all the users to have to login again do you? I think there are a simple reason: The data contain user's password. You wouldn't want the password to be written to disk. It is safer if it is kept in memory only. That depends on usage. Realm are used not only for Form authentication, but for other authentication protocols as well. Anyway if it is not implemented it likely means that nobody contributed an implementation of it. PS: Do not top-post. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication vs. Tomcat Restart
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jess, On 12/6/11 6:17 PM, Jess Holle wrote: Okay, I now notice this plainly stated in the documentation for JNDIRealm (which I'm using): The cached user is *not* saved and restored across sessions serialisations. That seems a bit odd... I wouldn't think that should be a problem: subsequent requests (after a restart) should re-create whatever data are necessary. We used to have this problem, and it turned out that we had a few objects in the session that were serializable yet still not un-serializable (because they didn't have no-arg constructors, for instance). Is it possible you are having a problem like that? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7ftpgACgkQ9CaO5/Lv0PAxJgCfW8G91XwwLTiUAXoYO16NCojL aNUAoLysh1BGs942flGrKpVv1i40AsPN =zzm/ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication vs. Tomcat Restart
You get an error when that's what's occurring, though. On 12/7/2011 12:55 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jess, On 12/6/11 6:17 PM, Jess Holle wrote: Okay, I now notice this plainly stated in the documentation for JNDIRealm (which I'm using): The cached user is *not* saved and restored across sessions serialisations. That seems a bit odd... I wouldn't think that should be a problem: subsequent requests (after a restart) should re-create whatever data are necessary. We used to have this problem, and it turned out that we had a few objects in the session that were serializable yet still not un-serializable (because they didn't have no-arg constructors, for instance). Is it possible you are having a problem like that? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7ftpgACgkQ9CaO5/Lv0PAxJgCfW8G91XwwLTiUAXoYO16NCojL aNUAoLysh1BGs942flGrKpVv1i40AsPN =zzm/ -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
Form Authentication vs. Tomcat Restart
When doing a graceful shutdown of Tomcat, the sessions are persisted to disk and then re-read on startup (at least in all reasonably recent versions). Oddly, however, form-based authentication does not seem to survive a graceful restart. Rather one has to log in again. Is this known? Intentional? Configurable? -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication vs. Tomcat Restart
Okay, I now notice this plainly stated in the documentation for JNDIRealm (which I'm using): The cached user is *not* saved and restored across sessions serialisations. That seems a bit odd... On 12/6/2011 5:12 PM, Jess Holle wrote: When doing a graceful shutdown of Tomcat, the sessions are persisted to disk and then re-read on startup (at least in all reasonably recent versions). Oddly, however, form-based authentication does not seem to survive a graceful restart. Rather one has to log in again. Is this known? Intentional? Configurable? -- Jess Holle
Re: Form Authentication vs. Tomcat Restart
Jess Holle wrote: When doing a graceful shutdown of Tomcat, the sessions are persisted to disk and then re-read on startup (at least in all reasonably recent versions). Oddly, however, form-based authentication does not seem to survive a graceful restart. Rather one has to log in again. Is this known? Intentional? Configurable? There should be a template for messages on this list : Tomcat version : Java version : platform OS version : - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Should Form Authentication Valve restore request body on a PUT?
On 1:59 PM, Nicholas Sushkin wrote: The bug was that if you do an unauthenticated POST, PUT, or DELETE, the Form Authentication valve was trying to do a POST, PUT, or DELETE to the login form. The correct behaviour IMHO is to always GET the login form and return it as a response to the unauthenticated request of any kind. Then, once the form is POSTed and authentication is successful, the original request whatever it may have been, should be replayed. Right? On Friday, October 07, 2011 16:07:20 Nicholas Sushkin wrote: Before being forwarded to login page, the request is saved and only then turned into GET, before dispatching the forward to the login page. After login form is submitted, the original request is restored from the saved state and is replayed. -- Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations Open Finance - Secure, Accurate, Industrial Strength Aggregation http://www.openfinance.com Sounds logical but modifying data on the server: 1) after being diverted to the login form 2) without any type of confirmation makes me a little uncomfortable. -Terence Bandoian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Should Form Authentication Valve restore request body on a PUT?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nicholas, On 10/6/2011 10:08 PM, Nicholas Sushkin wrote: I now reconfigured DefaultServlet in conf/web.xml with readonly=false. Now, an unauthenticated PUT (with or without a body) returns 204 No Content instead of the login form. Seems like a bug. Should I add this behavior to Bug #51940 or a new bug? I'll bet what is happening is that your PUT request is being forwarded without modification to the login page, and your login page is some static content. Is that right? If that's what's happening, the DefaultServlet is handling the request, seeing that it is a PUT, and then complaining that it's read-only. When you make the DefaultServlet read-write you tell the DefaultServlet to accept uploads, and you'll probably end up overwriting your login form with the request entity (oops). It looks like the authenticator code needs to transform the PUT request into a GET (or POST?) so that the DefaultServlet doesn't try to do an upload. I think you'd have similar problems if trying to use a JSP for your login-page, because JSPs can't accept PUT requests unless specifically configured to do so. Since you're just hacking, try setting the request method to GET when you detect a PUT request that requires authentication. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6PCOwACgkQ9CaO5/Lv0PB5lwCeNN0fxcnPVAZG7UaY6ywQsR/A xNQAn1TbTs0QqPT4FspU9yPFoNNL5PjO =mkME -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Should Form Authentication Valve restore request body on a PUT?
Yup. The body of the POST got written into my login.html. Took me a while to notice that. Good one! On Friday, October 07, 2011 10:13:00 Christopher Schultz wrote: If that's what's happening, the DefaultServlet is handling the request, seeing that it is a PUT, and then complaining that it's read-only. When you make the DefaultServlet read-write you tell the DefaultServlet to accept uploads, and you'll probably end up overwriting your login form with the request entity (oops). -- Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations Open Finance - Secure, Accurate, Industrial Strength Aggregation http://www.openfinance.com smime.p7s Description: S/MIME cryptographic signature
Re: Should Form Authentication Valve restore request body on a PUT?
Charles, Thanks for the suggestion. I set request method to GET on all unauthenticated requests that forward to the login page. That tested well for all RESTful methods, POST, PUT, GET, and DELETE. Submitted a patch. https://issues.apache.org/bugzilla/show_bug.cgi?id=51940#c2 On Friday, October 07, 2011 10:13:00 Christopher Schultz wrote: Since you're just hacking, try setting the request method to GET when you detect a PUT request that requires authentication. -- Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations Open Finance - Secure, Accurate, Industrial Strength Aggregation http://www.openfinance.com smime.p7s Description: S/MIME cryptographic signature
RE: Should Form Authentication Valve restore request body on a PUT?
From: Nicholas Sushkin [mailto:nsush...@openfinance.com] Subject: Re: Should Form Authentication Valve restore request body on a PUT? I set request method to GET on all unauthenticated requests that forward to the login page. I'm confused. If you turn a PUT into a GET, it would seem that the request will likely be badly mishandled once the login process is complete and the original request is sent on to the target servlet/JSP. Am I missing something? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Should Form Authentication Valve restore request body on a PUT?
Before being forwarded to login page, the request is saved and only then turned into GET, before dispatching the forward to the login page. After login form is submitted, the original request is restored from the saved state and is replayed. On Friday, October 07, 2011 12:51:48 Caldarale, Charles R wrote: I'm confused. If you turn a PUT into a GET, it would seem that the request will likely be badly mishandled once the login process is complete and the original request is sent on to the target servlet/JSP. Am I missing something? - Chuck -- Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations Open Finance - Secure, Accurate, Industrial Strength Aggregation http://www.openfinance.com smime.p7s Description: S/MIME cryptographic signature
Re: Should Form Authentication Valve restore request body on a PUT?
The bug was that if you do an unauthenticated POST, PUT, or DELETE, the Form Authentication valve was trying to do a POST, PUT, or DELETE to the login form. The correct behaviour IMHO is to always GET the login form and return it as a response to the unauthenticated request of any kind. Then, once the form is POSTed and authentication is successful, the original request whatever it may have been, should be replayed. Right? On Friday, October 07, 2011 16:07:20 Nicholas Sushkin wrote: Before being forwarded to login page, the request is saved and only then turned into GET, before dispatching the forward to the login page. After login form is submitted, the original request is restored from the saved state and is replayed. -- Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations Open Finance - Secure, Accurate, Industrial Strength Aggregation http://www.openfinance.com smime.p7s Description: S/MIME cryptographic signature
RE: Should Form Authentication Valve restore request body on a PUT?
From: Nicholas Sushkin [mailto:nsush...@openfinance.com] Subject: Re: Should Form Authentication Valve restore request body on a PUT? The correct behaviour IMHO is to always GET the login form and return it as a response to the unauthenticated request of any kind. Then, once the form is POSTed and authentication is successful, the original request whatever it may have been, should be replayed. Right? Yes, that sounds correct. It wasn't clear to me in what order things were being done. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Should Form Authentication Valve restore request body on a PUT?
I found out that in Tomcat 6.0 trunk, if user is not authentication and app is
configured for FORM authentication, POST and GET requests return 200 and the
login form, but PUT returns 403 and error page. What might explain the
difference in handling PUT?
I tried to run in debugger, but it wasn't immediately obvious.
forwardToLoginPage is called in all cases, but there is some difference in the
way dispatcher processes the forward.
Thanks.
On Thursday, September 29, 2011 17:04:27 Christopher Schultz wrote:
Nicholas,
On 9/29/2011 3:37 PM, Nicholas Sushkin wrote:
In Tomcat 6, Form Authentication valve restores the original
request after a POST with successful authentication and redirect is
followed by the client's GET. In case of the POST, the valve also
restores the original request's body. However, it doesn't do that
for a PUT.
That's not entirely surprising.
If I am not mistaken, it should restore the body on PUT as well. Do
I misunderstand something?
The servlet spec (v3.0, SRV 13.6.3.1) has this to say:
If the form based login is invoked because of an HTTP request, the
original request parameters must be preserved by the container for use
if, on successful authentication, it redirects the call to the
requested resource.
It doesn't say what kinds of HTTP verbs should or should not be
supported, but GET and PUT seem entirely obvious. It doesn't say that
the request body needs to be maintained, only the request
parameters. Since the servlet specification doesn't have any
provisions for fetching request parameters from PUT operations, I
suppose the spec therefore doesn't directly recommend that PUT bodies
be stored for later use like when POST is used.
The patch would be in FormAuthenticator.restoreRequest(Request,
Session) [1], to change from
if (POST.equalsIgnoreCase(saved.getMethod())) {
to
if (POST.equalsIgnoreCase(saved.getMethod()) ||
PUT.equalsIgnoreCase(saved.getMethod())) {
On the face of it, that seems reasonable. I haven't read-through the
code that then replays the saved-request so I'm not sure if there's
more to be done.
I do have one question: why are you using Form-based authentication
with PUT requests? It seems like HTTP Digest or something like that
would make more sense when clients can expect to send data without
being challenged a-priori for credentials.
Another workaround would just be to use POST.
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
Nicholas Sushkin
Senior Software Engineer, Manager of IT Operations
OpenFinance
62 Chelsea Piers, Suite 316
New York, NY 10011
+1 646 723 2790 (o)
nsush...@openfinance.com
CONFIDENTIALITY NOTICE: This e-mail message and any attachments are only for
the use of the intended recipient and may contain information that is
privileged, confidential or exempt from disclosure under applicable law. If
you are not the intended recipient, any disclosure, distribution or other use
of this e-mail message or attachments is prohibited. If you have received this
e-mail message in error, please delete and notify the sender immediately.
Thank you.
smime.p7s
Description: S/MIME cryptographic signature
Re: Should Form Authentication Valve restore request body on a PUT?
I now reconfigured DefaultServlet in conf/web.xml with readonly=false. Now, an unauthenticated PUT (with or without a body) returns 204 No Content instead of the login form. Seems like a bug. Should I add this behavior to Bug #51940 or a new bug? On Thursday, October 06, 2011 16:35:16 Nicholas Sushkin wrote: Ok, traced the 403 to DefaultServlet being readonly, which is somehow relevant during login form forward. -- Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations Open Finance - Secure, Accurate, Industrial Strength Aggregation http://www.openfinance.com smime.p7s Description: S/MIME cryptographic signature
Re: Should Form Authentication Valve restore request body on a PUT?
https://issues.apache.org/bugzilla/show_bug.cgi?id=51940 I left all the flags at their default settings. Thanks! On Saturday, October 01, 2011 07:20:21 Mark Thomas wrote: On 30/09/2011 17:09, Nicholas Sushkin wrote: Mark, Chris, thanks for the review. Should filing a bug be my next step, then? Please. Mark On Friday, September 30, 2011 13:10:55 Mark Thomas wrote: Basically my thinking is that you handle POST, shouldn't you also implement PUT the same way, to be consistent? I'd have no objection so the proposed change. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations Open Finance - Secure, Accurate, Industrial Strength Aggregation http://www.openfinance.com smime.p7s Description: S/MIME cryptographic signature
Re: Should Form Authentication Valve restore request body on a PUT?
On 30/09/2011 17:09, Nicholas Sushkin wrote: Mark, Chris, thanks for the review. Should filing a bug be my next step, then? Please. Mark On Friday, September 30, 2011 13:10:55 Mark Thomas wrote: Basically my thinking is that you handle POST, shouldn't you also implement PUT the same way, to be consistent? I'd have no objection so the proposed change. Mark -- Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations Open Finance - Secure, Accurate, Industrial Strength Aggregation http://www.openfinance.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Should Form Authentication Valve restore request body on a PUT?
I can go into more details, if you wish, but basically I am using Forgerock OpenAM, which is a single signon/access manager product which has its own valve that hooks into the application's login URLs defined in form authentication, returns a login form with prepopulated username and password fields, with html body having javascript onbody submit. I think it's their way to have Tomcat evaluate J2EE roles and soon. When using browser, this all happens transparent to the user and the form is being automatically submitted by the browser's javascript. When REST API is being used (that's where a PUT is required), Tomcat throws authentication form once its session expires, and this may happen on any method. GET and POST are handled correctly, but not PUT. PUT's body is always lost because the the Form Authentication doesn't restore it. Basically my thinking is that you handle POST, shouldn't you also implement PUT the same way, to be consistent? On Thursday, September 29, 2011 17:04:27 Christopher Schultz wrote: I do have one question: why are you using Form-based authentication with PUT requests? It seems like HTTP Digest or something like that would make more sense when clients can expect to send data without being challenged a-priori for credentials. Another workaround would just be to use POST. -- Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations Open Finance - Secure, Accurate, Industrial Strength Aggregation http://www.openfinance.com smime.p7s Description: S/MIME cryptographic signature
Re: Should Form Authentication Valve restore request body on a PUT?
On 30/09/2011 12:20, Nicholas Sushkin wrote: I can go into more details, if you wish, but basically I am using Forgerock OpenAM, which is a single signon/access manager product which has its own valve that hooks into the application's login URLs defined in form authentication, returns a login form with prepopulated username and password fields, with html body having javascript onbody submit. I think it's their way to have Tomcat evaluate J2EE roles and soon. When using browser, this all happens transparent to the user and the form is being automatically submitted by the browser's javascript. When REST API is being used (that's where a PUT is required), Tomcat throws authentication form once its session expires, and this may happen on any method. GET and POST are handled correctly, but not PUT. PUT's body is always lost because the the Form Authentication doesn't restore it. Basically my thinking is that you handle POST, shouldn't you also implement PUT the same way, to be consistent? I'd have no objection so the proposed change. Mark On Thursday, September 29, 2011 17:04:27 Christopher Schultz wrote: I do have one question: why are you using Form-based authentication with PUT requests? It seems like HTTP Digest or something like that would make more sense when clients can expect to send data without being challenged a-priori for credentials. Another workaround would just be to use POST. -- Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations Open Finance - Secure, Accurate, Industrial Strength Aggregation http://www.openfinance.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Should Form Authentication Valve restore request body on a PUT?
Mark, Chris, thanks for the review. Should filing a bug be my next step, then? On Friday, September 30, 2011 13:10:55 Mark Thomas wrote: Basically my thinking is that you handle POST, shouldn't you also implement PUT the same way, to be consistent? I'd have no objection so the proposed change. Mark -- Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations Open Finance - Secure, Accurate, Industrial Strength Aggregation http://www.openfinance.com smime.p7s Description: S/MIME cryptographic signature
Should Form Authentication Valve restore request body on a PUT?
In Tomcat 6, Form Authentication valve restores the original request after a
POST with successful authentication and redirect is followed by the client's
GET. In case of the POST, the valve also restores the original request's body.
However, it doesn't do that for a PUT. If I am not mistaken, it should restore
the body on PUT as well. Do I misunderstand something?
The patch would be in FormAuthenticator.restoreRequest(Request, Session) [1],
to change from
if (POST.equalsIgnoreCase(saved.getMethod())) {
to
if (POST.equalsIgnoreCase(saved.getMethod()) ||
PUT.equalsIgnoreCase(saved.getMethod())
) {
[1]
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/authenticator/FormAuthenticator.java?view=markup#l450
--
Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations
Open Finance - Secure, Accurate, Industrial Strength Aggregation
http://www.openfinance.com
smime.p7s
Description: S/MIME cryptographic signature
Re: Should Form Authentication Valve restore request body on a PUT?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nicholas,
On 9/29/2011 3:37 PM, Nicholas Sushkin wrote:
In Tomcat 6, Form Authentication valve restores the original
request after a POST with successful authentication and redirect is
followed by the client's GET. In case of the POST, the valve also
restores the original request's body. However, it doesn't do that
for a PUT.
That's not entirely surprising.
If I am not mistaken, it should restore the body on PUT as well. Do
I misunderstand something?
The servlet spec (v3.0, SRV 13.6.3.1) has this to say:
If the form based login is invoked because of an HTTP request, the
original request parameters must be preserved by the container for use
if, on successful authentication, it redirects the call to the
requested resource.
It doesn't say what kinds of HTTP verbs should or should not be
supported, but GET and PUT seem entirely obvious. It doesn't say that
the request body needs to be maintained, only the request
parameters. Since the servlet specification doesn't have any
provisions for fetching request parameters from PUT operations, I
suppose the spec therefore doesn't directly recommend that PUT bodies
be stored for later use like when POST is used.
The patch would be in FormAuthenticator.restoreRequest(Request,
Session) [1], to change from
if (POST.equalsIgnoreCase(saved.getMethod())) {
to
if (POST.equalsIgnoreCase(saved.getMethod()) ||
PUT.equalsIgnoreCase(saved.getMethod())) {
On the face of it, that seems reasonable. I haven't read-through the
code that then replays the saved-request so I'm not sure if there's
more to be done.
I do have one question: why are you using Form-based authentication
with PUT requests? It seems like HTTP Digest or something like that
would make more sense when clients can expect to send data without
being challenged a-priori for credentials.
Another workaround would just be to use POST.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6E3VsACgkQ9CaO5/Lv0PD67gCdGvoSAw3CJKRokEg0GNvDz7Tn
62oAnjovksaQNSkPiPDXg9jl9RSROVup
=JpnY
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication and status (response) code
2011/9/2 Mabry Tyson ty...@ai.sri.com: Summary: When requiring form authentication, Tomcat responds to an unauthenticated GET request with a HTTP status code of 200 (OK) and the login page. I believe that to be in violation of the HTTP standards. The problem: Software makes a GET request to a web server. It gets back a 200 status code. By RFC 2616, that code indicates the request has succeeded. The software then takes the resulting page as the successful response to the GET request. However, in some cases this response is NOT a successful response but is instead a login form. By using a 200 status code, Tomcat is misrepresenting that the login form is the response to the request. My believe is a 4xx code (client error) is appropriate, or possibly a 3xx code (Redirection) might be appropriate. Unfortunately, the RFC indicates that a 401 (Unauthorized) response MUST have a header that is only appropriate for basic or digest authentication. So a status code of 401 is not legal in this situation. neither is 403 or 404. Plus add to that that certain web browser (IE) has a habit to display his own error page instead on the one provided by the server. The response code 200 tells that server is returning some valid data (a HTML page) that has to be displayed to the user. There might be other headers along that (e.g. to forbid caching). What is your software trying to do? It is trying to crawl the web site? Maybe you can detect the presence of login form on the HTML page that is returned to you? P.S. For anyone maintaining the examples, shouldn't vendor examples demonstrate the best practices? I'd suggest you indicate the Content-Type and the charset. The best way to make examples better is to prepare and propose patches (through Bugzilla). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication and status (response) code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jess, On 9/1/2011 7:06 PM, Jess Holle wrote: So form-based authentication is an obnoxious mutt -- but a mutt that everyone seems to have fallen in love with. This isn't Tomcat's fault, however, and Tomcat is doing the normal thing by returning a 200 here. The servlet spec (section 13.6.3 Form Based Authentication) has the whole process laid out, except that they don't say what the HTTP response code should be when a request for a protected resource arrives and the login form should be sent to the client. Later, it says: If authentication fails, the error page is returned using either a forward or a redirect, and the status code of the response is set to 200. Ignoring the fact that you can't do a redirect using a 200 response, it's clear that there is no unauthenticated or forbidden response code to be used, here. Presumably, the decision to use response code 200 was drawn from this section as well as practical considerations (being able to prohibit the login form from being directly accessible to remote clients for instance) and past user input (I think Tomcat used to issue a redirect, but now does an internal forward and responds with 200). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5hTEwACgkQ9CaO5/Lv0PBpKACbB5A+XQ42NDT9gHSgR7jCDEAz 5i0An2JZMwf+jrrpwuQrk6AtDWbpOYpN =XYT8 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Form Authentication and status (response) code
Summary: When requiring form authentication, Tomcat responds to an unauthenticated GET request with a HTTP status code of 200 (OK) and the login page. I believe that to be in violation of the HTTP standards. The problem: Software makes a GET request to a web server. It gets back a 200 status code. By RFC 2616, that code indicates the request has succeeded. The software then takes the resulting page as the successful response to the GET request. However, in some cases this response is NOT a successful response but is instead a login form. By using a 200 status code, Tomcat is misrepresenting that the login form is the response to the request. My believe is a 4xx code (client error) is appropriate, or possibly a 3xx code (Redirection) might be appropriate. Unfortunately, the RFC indicates that a 401 (Unauthorized) response MUST have a header that is only appropriate for basic or digest authentication. So a status code of 401 is not legal in this situation. It seems unlikely that I'm the first to comment on this. It must have been discussed extensively before. Can anyone tell me (1) What is the reason behind saying the login form is a successful response? (2) Where is a pointer to the discussions? (3) What is an appropriate (non-ad hoc) way to determine that Tomcat is returning a login form rather than the requested resource? (I have done a quick search of the Internet, of Tomcat FAQ, and of outstanding Tomcat bugs, but didn't find this.) For instance, here are the headers when doing a GET of a login protected page from the examples shipped with Tomcat: GET /examples/jsp/security/protected/index.jsp HTTP/1.1 User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8r zlib/1.2.3 Host: xxx.example.com Accept: */* HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Pragma: No-cache Cache-Control: no-cache Expires: Wed, 31 Dec 1969 19:00:00 EST Set-Cookie: JSESSIONID=99FD7582647EEF539C449AEBBA5365EB; Path=/examples Content-Type: text/html Content-Length: 1413 Date: Thu, 01 Sep 2011 22:15:29 GMT while the content starts with html head titleLogin Page for Examples/title body bgcolor=white form method=POST action='j_security_check;jsessionid=99FD7582647EEF539C449AEBBA5365EB' P.S. For anyone maintaining the examples, shouldn't vendor examples demonstrate the best practices? I'd suggest you indicate the Content-Type and the charset. Also, it would be handy if the web.xml showed how to have the login page be served up by https (along with a note explaining that you don't do it here since you don't know that https willl be available). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication and status (response) code
That's the unfortunate way of form-based authentication. It's an application convention rather than a protocol-level standard -- it's not a standard but rather a loose convention and has to be handled by the application code rather than seamlessly with at protocol handling level. As such it's fine and good for consumption by interactive user sessions in a web browser -- as users can grok conventions just fine unless they're horrifically convoluted. Unfortunately, for any other form of client (e.g. a programmatic, non-interactive service in the extreme case or even an interactive client that is not browser based but rather is written against some HTTP client library or another) form-based authentication is a royal mess. It would be a lot better if form-based authentication standardized around returning a 401 -- ideally with some header information as to how to proceed to respond to the challenge. Unfortunately, responding with a 401 is not really legal here and indeed results in bad behavior from some HTTP client libraries (e.g. that built into Java, for instance). So form-based authentication is an obnoxious mutt -- but a mutt that everyone seems to have fallen in love with. This isn't Tomcat's fault, however, and Tomcat is doing the normal thing by returning a 200 here. As for tricks to see if your 200 isn't really a 200, you can: 1. Check the response Content-Type if the expected Content-Type isn't one that could possibly be used by a login form or 2. Add some other custom header to your response. If it's not there but you got a 200, then something hijacked the response -- quite probably a login form. -- Jess Holle On 9/1/2011 5:49 PM, Mabry Tyson wrote: Summary: When requiring form authentication, Tomcat responds to an unauthenticated GET request with a HTTP status code of 200 (OK) and the login page. I believe that to be in violation of the HTTP standards. The problem: Software makes a GET request to a web server. It gets back a 200 status code. By RFC 2616, that code indicates the request has succeeded. The software then takes the resulting page as the successful response to the GET request. However, in some cases this response is NOT a successful response but is instead a login form. By using a 200 status code, Tomcat is misrepresenting that the login form is the response to the request. My believe is a 4xx code (client error) is appropriate, or possibly a 3xx code (Redirection) might be appropriate. Unfortunately, the RFC indicates that a 401 (Unauthorized) response MUST have a header that is only appropriate for basic or digest authentication. So a status code of 401 is not legal in this situation. It seems unlikely that I'm the first to comment on this. It must have been discussed extensively before. Can anyone tell me (1) What is the reason behind saying the login form is a successful response? (2) Where is a pointer to the discussions? (3) What is an appropriate (non-ad hoc) way to determine that Tomcat is returning a login form rather than the requested resource? (I have done a quick search of the Internet, of Tomcat FAQ, and of outstanding Tomcat bugs, but didn't find this.) For instance, here are the headers when doing a GET of a login protected page from the examples shipped with Tomcat: GET /examples/jsp/security/protected/index.jsp HTTP/1.1 User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8r zlib/1.2.3 Host: xxx.example.com Accept: */* HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Pragma: No-cache Cache-Control: no-cache Expires: Wed, 31 Dec 1969 19:00:00 EST Set-Cookie: JSESSIONID=99FD7582647EEF539C449AEBBA5365EB; Path=/examples Content-Type: text/html Content-Length: 1413 Date: Thu, 01 Sep 2011 22:15:29 GMT while the content starts with html head titleLogin Page for Examples/title body bgcolor=white form method=POST action='j_security_check;jsessionid=99FD7582647EEF539C449AEBBA5365EB' P.S. For anyone maintaining the examples, shouldn't vendor examples demonstrate the best practices? I'd suggest you indicate the Content-Type and the charset. Also, it would be handy if the web.xml showed how to have the login page be served up by https (along with a note explaining that you don't do it here since you don't know that https willl be available). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Form Authentication Illegal Characters
Hello All: I am using Tomcat 6.0.26. My application has a context.xml file that defines an org.apache.catalina.authenticator.FormAuthenticator Valve and an org.apache.catalina.realm.DataSourceRealm Realm which I use for authentication. My login page functions in typical FormAuthentication manner by passing the j_username and j_password parameters to j_security_check Currently, authentication fails if the character # (pound sign) is contained within a username. Has anybody come across this limitation? I am working with another system that stores all @ symbols as # signs, so the likely hood of someone using an email address as their username is good. When I query my USERS table directly, I can locate any username that has a # sign in it, so it seems that this is a tomcat related issue. Just wanted to see if someone has experienced this and if there is a solution/workaround for this. Thanks, Beau
Re: Form Authentication Illegal Characters
2011/3/14 beau.hutche...@thomsonreuters.com: Hello All: I am using Tomcat 6.0.26. My application has a context.xml file that defines an org.apache.catalina.authenticator.FormAuthenticator Valve and an org.apache.catalina.realm.DataSourceRealm Realm which I use for authentication. My login page functions in typical FormAuthentication manner by passing the j_username and j_password parameters to j_security_check Currently, authentication fails if the character # (pound sign) is contained within a username. Has anybody come across this limitation? I I do not think that there is such a limitation. I would suggest you to try debugging it, http://wiki.apache.org/tomcat/FAQ/Developing#Debugging And an update to the latest 6.0.32 should not hurt. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication Illegal Characters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Beau, On 3/14/2011 10:57 AM, beau.hutche...@thomsonreuters.com wrote: Currently, authentication fails if the character # (pound sign) is contained within a username. Define fails. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1+UUgACgkQ9CaO5/Lv0PAA7gCfedxpdkMLJ6lYFntVtO8pq6Wa GTMAn3BUQX2qpk32vKGY6miomFw9KuDQ =jAGN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Form Authentication Illegal Characters - SOLVED
Thanks for the response yet, There is no limitation regarding special characters. I just have to make sure and encode my query string properly. By fails I meant that the app gets forwarded to the value set in my form-error-page tag. Thanks, -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Monday, March 14, 2011 1:33 PM To: Tomcat Users List Subject: Re: Form Authentication Illegal Characters -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Beau, On 3/14/2011 10:57 AM, beau.hutche...@thomsonreuters.com wrote: Currently, authentication fails if the character # (pound sign) is contained within a username. Define fails. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1+UUgACgkQ9CaO5/Lv0PAA7gCfedxpdkMLJ6lYFntVtO8pq6Wa GTMAn3BUQX2qpk32vKGY6miomFw9KuDQ =jAGN -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: SOLVED - Form Authentication Illegal Characters
There is no limitation regarding special characters. I just have to make sure and encode my query string properly. Thanks, -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Monday, March 14, 2011 12:22 PM To: Tomcat Users List Subject: Re: Form Authentication Illegal Characters 2011/3/14 beau.hutche...@thomsonreuters.com: Hello All: I am using Tomcat 6.0.26. My application has a context.xml file that defines an org.apache.catalina.authenticator.FormAuthenticator Valve and an org.apache.catalina.realm.DataSourceRealm Realm which I use for authentication. My login page functions in typical FormAuthentication manner by passing the j_username and j_password parameters to j_security_check Currently, authentication fails if the character # (pound sign) is contained within a username. Has anybody come across this limitation? I I do not think that there is such a limitation. I would suggest you to try debugging it, http://wiki.apache.org/tomcat/FAQ/Developing#Debugging And an update to the latest 6.0.32 should not hurt. Best regards, Konstantin Kolinko - 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: Pid OpenSSO request for Tomcat Form Authentication that requires no password for third party SSO
On 28 Jan 2011, at 18:53, beau.hutche...@thomsonreuters.com beau.hutche...@thomsonreuters.com wrote: @Pid: The SSo third party app knows the SSO entry point into my Tomcat app. I am supplied an encrypted token which contains the username and my tomcat app has the libraries to unencrypt that token and unveil the username If you're using Tomcat 6 the only safe* way to do this is to implement JAAS. It's a bit of a hassle but the result will be worth it. p *IMHO @Andre: Ideally it would seem most convenient to access j_security_check with a valid j_username and a j_password with a blank value, so then the tomcat container would generate the proper principal and roles information. I want to be able to use request.getRemoteUser() and request.isUserInRole(String role). It would seem that I can extend AuthenticatorBase and mimic everything that FormAuthenticator does except for the password query part. Or I can use a hack for the DataSourceRealm and use my UserName column for both the userCredCol and userNameCol values. Therefore no password to check for. Beau -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Friday, January 28, 2011 6:36 AM To: Tomcat Users List Subject: Re: Pid OpenSSO request for Tomcat Form Authentication that requires no password for third party SSO Pid wrote: On 1/27/11 3:57 PM, beau.hutche...@thomsonreuters.com wrote: Chris: Thanks for your reply. Currently I am using Tomcat 6.0.29 @Pid: Would you have any ideas on how to set something up like this? What details are you providing to Tomcat? If I read the thread correctly you've got a single parameter - how are you validating that to stop say, me, guessing at logins? That's easy, as long as Tomcat accepts only connections from a source known to go through the aforementioned SSO. I have a similar setup at one of my customers. This is only an example : All users use a session on a specific Windows Terminal Server. In that session, they open a browser, which allows them to connect to Tomcat (*). Tomcat accepts only connections from the IP's of the Terminal Server. On the Terminal Server runs that nifty SSO mechanism which I mentioned in another message here. Somehow, that SSO detects the login page which the Tomcat authentication is sending back to the browser, fills-in the userid (**), and re-posts the login form to the server. The user is now logged-in and gets the application page. The user does not see anything. I know that it sounds a bit strange when one explains it like that, but it works. (**) the user-id being sent is the user's Windows Domain user-id, which has already been authenticated/verified, so it can be trusted. There is thus no need to verify it again in Tomcat. (*) Ok, I'm cheating : in my case, it is not Tomcat directly, but it is an Apache httpd front-ending for Tomcat, and connecting to it via mod_jk. mod_jk will pass on the httpd-level user-id, and Tomcat (with the 'tomcatAuthentication=false attribute on the AJP Connector), will accept that user-id as its own. At the Tomcat level, you would still have to do the isUserInRole part though. Now the question is : assuming that there is no httpd front-end and no mod_jk, can a similar mechanism work with Tomcat directly ? In other words, can the standard Tomcat form-based authentication work, if the login form is sent back with a non-blank userid, but with a blank password ? And could this authentication code be easily tweaked to bypass any verification of the received user-id ? And, to the original poster : apologies for somewhat hijacking your thread, but I am just trying to help finding the best method for you. I have a feeling that for this case, having to create a brand-new Authenticator is a bit heavy as a solution. It seems that it should be possible to at least crate some null Realm which always accepts any user-id and always returns OK. Or use whatever mechanism mod_jk is using to the same basic effect. - 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: Pid OpenSSO request for Tomcat Form Authentication that requires no password for third party SSO
It is more curiosity now on my part, but I have a couple of questions : Where does this SSO third-party app actually live ? Is it on another webserver which acts as a proxy to your Tomcat ? Or inside of Tomcat itself ? And you mention that you are supplied a token; how ? Is it in the form of a HTTP header added to the request ? or does the third-party app actually fill-in the login form ? Or does it add a query-string parameter with this token ? Pid * wrote: On 28 Jan 2011, at 18:53, beau.hutche...@thomsonreuters.com beau.hutche...@thomsonreuters.com wrote: @Pid: The SSo third party app knows the SSO entry point into my Tomcat app. I am supplied an encrypted token which contains the username and my tomcat app has the libraries to unencrypt that token and unveil the username If you're using Tomcat 6 the only safe* way to do this is to implement JAAS. It's a bit of a hassle but the result will be worth it. p *IMHO @Andre: Ideally it would seem most convenient to access j_security_check with a valid j_username and a j_password with a blank value, so then the tomcat container would generate the proper principal and roles information. I want to be able to use request.getRemoteUser() and request.isUserInRole(String role). It would seem that I can extend AuthenticatorBase and mimic everything that FormAuthenticator does except for the password query part. Or I can use a hack for the DataSourceRealm and use my UserName column for both the userCredCol and userNameCol values. Therefore no password to check for. Beau -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Friday, January 28, 2011 6:36 AM To: Tomcat Users List Subject: Re: Pid OpenSSO request for Tomcat Form Authentication that requires no password for third party SSO Pid wrote: On 1/27/11 3:57 PM, beau.hutche...@thomsonreuters.com wrote: Chris: Thanks for your reply. Currently I am using Tomcat 6.0.29 @Pid: Would you have any ideas on how to set something up like this? What details are you providing to Tomcat? If I read the thread correctly you've got a single parameter - how are you validating that to stop say, me, guessing at logins? That's easy, as long as Tomcat accepts only connections from a source known to go through the aforementioned SSO. I have a similar setup at one of my customers. This is only an example : All users use a session on a specific Windows Terminal Server. In that session, they open a browser, which allows them to connect to Tomcat (*). Tomcat accepts only connections from the IP's of the Terminal Server. On the Terminal Server runs that nifty SSO mechanism which I mentioned in another message here. Somehow, that SSO detects the login page which the Tomcat authentication is sending back to the browser, fills-in the userid (**), and re-posts the login form to the server. The user is now logged-in and gets the application page. The user does not see anything. I know that it sounds a bit strange when one explains it like that, but it works. (**) the user-id being sent is the user's Windows Domain user-id, which has already been authenticated/verified, so it can be trusted. There is thus no need to verify it again in Tomcat. (*) Ok, I'm cheating : in my case, it is not Tomcat directly, but it is an Apache httpd front-ending for Tomcat, and connecting to it via mod_jk. mod_jk will pass on the httpd-level user-id, and Tomcat (with the 'tomcatAuthentication=false attribute on the AJP Connector), will accept that user-id as its own. At the Tomcat level, you would still have to do the isUserInRole part though. Now the question is : assuming that there is no httpd front-end and no mod_jk, can a similar mechanism work with Tomcat directly ? In other words, can the standard Tomcat form-based authentication work, if the login form is sent back with a non-blank userid, but with a blank password ? And could this authentication code be easily tweaked to bypass any verification of the received user-id ? And, to the original poster : apologies for somewhat hijacking your thread, but I am just trying to help finding the best method for you. I have a feeling that for this case, having to create a brand-new Authenticator is a bit heavy as a solution. It seems that it should be possible to at least crate some null Realm which always accepts any user-id and always returns OK. Or use whatever mechanism mod_jk is using to the same basic effect. - 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
Re: Pid OpenSSO request for Tomcat Form Authentication that requires no password for third party SSO
On 1/27/11 3:57 PM, beau.hutche...@thomsonreuters.com wrote: Chris: Thanks for your reply. Currently I am using Tomcat 6.0.29 @Pid: Would you have any ideas on how to set something up like this? What details are you providing to Tomcat? If I read the thread correctly you've got a single parameter - how are you validating that to stop say, me, guessing at logins? p Beau -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, January 26, 2011 6:30 PM To: Tomcat Users List Subject: Re: Tomcat Form Authentication that requires no password for third party SSO Beau, On 1/26/2011 1:10 PM, beau.hutche...@thomsonreuters.com wrote: I am trying to integrate my application with an SSO partner application. What Tomcat version? I ask because Tomcat 7 includes the Servlet 3.0 programmatic login API. After successfully logging into the partner app, I will be redirected and only provided a username to log into my tomcat Form Authentication app. I am using a DataSourceRealm to check for both Users and User Roles. DataSourceRealm requires both username and password. I think JAASRealm might be able to help you. Also, one of the list contributors (Pid) is working on a realm to help with OpenSSO or something like that: he may have some ideas about how to set things up. Are there any suggestions as to how I can still authenticate() through the tomcat container without providing a password? Out of the box, I don't believe Tomcat can do this. -chris - 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 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Pid OpenSSO request for Tomcat Form Authentication that requires no password for third party SSO
Pid wrote: On 1/27/11 3:57 PM, beau.hutche...@thomsonreuters.com wrote: Chris: Thanks for your reply. Currently I am using Tomcat 6.0.29 @Pid: Would you have any ideas on how to set something up like this? What details are you providing to Tomcat? If I read the thread correctly you've got a single parameter - how are you validating that to stop say, me, guessing at logins? That's easy, as long as Tomcat accepts only connections from a source known to go through the aforementioned SSO. I have a similar setup at one of my customers. This is only an example : All users use a session on a specific Windows Terminal Server. In that session, they open a browser, which allows them to connect to Tomcat (*). Tomcat accepts only connections from the IP's of the Terminal Server. On the Terminal Server runs that nifty SSO mechanism which I mentioned in another message here. Somehow, that SSO detects the login page which the Tomcat authentication is sending back to the browser, fills-in the userid (**), and re-posts the login form to the server. The user is now logged-in and gets the application page. The user does not see anything. I know that it sounds a bit strange when one explains it like that, but it works. (**) the user-id being sent is the user's Windows Domain user-id, which has already been authenticated/verified, so it can be trusted. There is thus no need to verify it again in Tomcat. (*) Ok, I'm cheating : in my case, it is not Tomcat directly, but it is an Apache httpd front-ending for Tomcat, and connecting to it via mod_jk. mod_jk will pass on the httpd-level user-id, and Tomcat (with the 'tomcatAuthentication=false attribute on the AJP Connector), will accept that user-id as its own. At the Tomcat level, you would still have to do the isUserInRole part though. Now the question is : assuming that there is no httpd front-end and no mod_jk, can a similar mechanism work with Tomcat directly ? In other words, can the standard Tomcat form-based authentication work, if the login form is sent back with a non-blank userid, but with a blank password ? And could this authentication code be easily tweaked to bypass any verification of the received user-id ? And, to the original poster : apologies for somewhat hijacking your thread, but I am just trying to help finding the best method for you. I have a feeling that for this case, having to create a brand-new Authenticator is a bit heavy as a solution. It seems that it should be possible to at least crate some null Realm which always accepts any user-id and always returns OK. Or use whatever mechanism mod_jk is using to the same basic effect. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Pid OpenSSO request for Tomcat Form Authentication that requires no password for third party SSO
@Pid: The SSo third party app knows the SSO entry point into my Tomcat app. I am supplied an encrypted token which contains the username and my tomcat app has the libraries to unencrypt that token and unveil the username @Andre: Ideally it would seem most convenient to access j_security_check with a valid j_username and a j_password with a blank value, so then the tomcat container would generate the proper principal and roles information. I want to be able to use request.getRemoteUser() and request.isUserInRole(String role). It would seem that I can extend AuthenticatorBase and mimic everything that FormAuthenticator does except for the password query part. Or I can use a hack for the DataSourceRealm and use my UserName column for both the userCredCol and userNameCol values. Therefore no password to check for. Beau -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Friday, January 28, 2011 6:36 AM To: Tomcat Users List Subject: Re: Pid OpenSSO request for Tomcat Form Authentication that requires no password for third party SSO Pid wrote: On 1/27/11 3:57 PM, beau.hutche...@thomsonreuters.com wrote: Chris: Thanks for your reply. Currently I am using Tomcat 6.0.29 @Pid: Would you have any ideas on how to set something up like this? What details are you providing to Tomcat? If I read the thread correctly you've got a single parameter - how are you validating that to stop say, me, guessing at logins? That's easy, as long as Tomcat accepts only connections from a source known to go through the aforementioned SSO. I have a similar setup at one of my customers. This is only an example : All users use a session on a specific Windows Terminal Server. In that session, they open a browser, which allows them to connect to Tomcat (*). Tomcat accepts only connections from the IP's of the Terminal Server. On the Terminal Server runs that nifty SSO mechanism which I mentioned in another message here. Somehow, that SSO detects the login page which the Tomcat authentication is sending back to the browser, fills-in the userid (**), and re-posts the login form to the server. The user is now logged-in and gets the application page. The user does not see anything. I know that it sounds a bit strange when one explains it like that, but it works. (**) the user-id being sent is the user's Windows Domain user-id, which has already been authenticated/verified, so it can be trusted. There is thus no need to verify it again in Tomcat. (*) Ok, I'm cheating : in my case, it is not Tomcat directly, but it is an Apache httpd front-ending for Tomcat, and connecting to it via mod_jk. mod_jk will pass on the httpd-level user-id, and Tomcat (with the 'tomcatAuthentication=false attribute on the AJP Connector), will accept that user-id as its own. At the Tomcat level, you would still have to do the isUserInRole part though. Now the question is : assuming that there is no httpd front-end and no mod_jk, can a similar mechanism work with Tomcat directly ? In other words, can the standard Tomcat form-based authentication work, if the login form is sent back with a non-blank userid, but with a blank password ? And could this authentication code be easily tweaked to bypass any verification of the received user-id ? And, to the original poster : apologies for somewhat hijacking your thread, but I am just trying to help finding the best method for you. I have a feeling that for this case, having to create a brand-new Authenticator is a bit heavy as a solution. It seems that it should be possible to at least crate some null Realm which always accepts any user-id and always returns OK. Or use whatever mechanism mod_jk is using to the same basic effect. - 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: Pid OpenSSO request for Tomcat Form Authentication that requires no password for third party SSO
Chris: Thanks for your reply. Currently I am using Tomcat 6.0.29 @Pid: Would you have any ideas on how to set something up like this? Beau -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, January 26, 2011 6:30 PM To: Tomcat Users List Subject: Re: Tomcat Form Authentication that requires no password for third party SSO -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Beau, On 1/26/2011 1:10 PM, beau.hutche...@thomsonreuters.com wrote: I am trying to integrate my application with an SSO partner application. What Tomcat version? I ask because Tomcat 7 includes the Servlet 3.0 programmatic login API. After successfully logging into the partner app, I will be redirected and only provided a username to log into my tomcat Form Authentication app. I am using a DataSourceRealm to check for both Users and User Roles. DataSourceRealm requires both username and password. I think JAASRealm might be able to help you. Also, one of the list contributors (Pid) is working on a realm to help with OpenSSO or something like that: he may have some ideas about how to set things up. Are there any suggestions as to how I can still authenticate() through the tomcat container without providing a password? Out of the box, I don't believe Tomcat can do this. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1ArocACgkQ9CaO5/Lv0PBVWwCgwvN2jma89OEB0QLPo+rAAnOX luAAoI/QXqxD1ZX3DhevcyxCyJDL+eCc =QXO9 -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: Tomcat Form Authentication that requires no password for third party SSO
You could implement your own authenticator, extending the class org.apache.catalina.authenticator.AuthenticatorBase https://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/authenticator/AuthenticatorBase.java?view=markup protected abstract boolean authenticate(Request request, Response response, LoginConfig config) throws IOException; This would require a bit customization of Tomcat, but I would implement my own class, and my own authentication scheme Filip On 01/26/2011 11:10 AM, beau.hutche...@thomsonreuters.com wrote: Hello: I am trying to integrate my application with an SSO partner application. After successfully logging into the partner app, I will be redirected and only provided a username to log into my tomcat Form Authentication app. I am using a DataSourceRealm to check for both Users and User Roles. Are there any suggestions as to how I can still authenticate() through the tomcat container without providing a password? Thanks for your attention, Beau - 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 Form Authentication that requires no password for third party SSO
Filip: Thanks, I'll get going on my own authenticator right quick. Does tcserver come with something like this out of the box? Beau -Original Message- From: Filip Hanik - Dev Lists [mailto:devli...@hanik.com] Sent: Thursday, January 27, 2011 12:41 PM To: Tomcat Users List Subject: Re: Tomcat Form Authentication that requires no password for third party SSO You could implement your own authenticator, extending the class org.apache.catalina.authenticator.AuthenticatorBase https://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catal ina/authenticator/AuthenticatorBase.java?view=markup protected abstract boolean authenticate(Request request, Response response, LoginConfig config) throws IOException; This would require a bit customization of Tomcat, but I would implement my own class, and my own authentication scheme Filip On 01/26/2011 11:10 AM, beau.hutche...@thomsonreuters.com wrote: Hello: I am trying to integrate my application with an SSO partner application. After successfully logging into the partner app, I will be redirected and only provided a username to log into my tomcat Form Authentication app. I am using a DataSourceRealm to check for both Users and User Roles. Are there any suggestions as to how I can still authenticate() through the tomcat container without providing a password? Thanks for your attention, Beau - 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 Form Authentication that requires no password for third party SSO
There is a file called Authenticators.properties, in there it maps what you specify in web.xml, to a specific authenticator. So you write your own authenticator, you add an entry into this file, change web.xml with your new auth-method tc server does not come with something like this best Filip On 01/27/2011 10:56 AM, beau.hutche...@thomsonreuters.com wrote: Filip: Thanks, I'll get going on my own authenticator right quick. Does tcserver come with something like this out of the box? Beau -Original Message- From: Filip Hanik - Dev Lists [mailto:devli...@hanik.com] Sent: Thursday, January 27, 2011 12:41 PM To: Tomcat Users List Subject: Re: Tomcat Form Authentication that requires no password for third party SSO You could implement your own authenticator, extending the class org.apache.catalina.authenticator.AuthenticatorBase https://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catal ina/authenticator/AuthenticatorBase.java?view=markup protected abstract boolean authenticate(Request request, Response response, LoginConfig config) throws IOException; This would require a bit customization of Tomcat, but I would implement my own class, and my own authentication scheme Filip On 01/26/2011 11:10 AM, beau.hutche...@thomsonreuters.com wrote: Hello: I am trying to integrate my application with an SSO partner application. After successfully logging into the partner app, I will be redirected and only provided a username to log into my tomcat Form Authentication app. I am using a DataSourceRealm to check for both Users and User Roles. Are there any suggestions as to how I can still authenticate() through the tomcat container without providing a password? Thanks for your attention, Beau - 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
Re: Tomcat Form Authentication that requires no password for third party SSO
Hi. I think that you should be a bit more specific about the exact scheme below. Can you describe exactly, step by step, what happens just before and After successfully logging into the partner app, I will be redirected and only provided a username to log into my tomcat Form Authentication ? I am asking because I just dealt with an SSO system which works as follows : - the user sends a request for a protected URL - the server sends back a login form - the SSO system somehow recognises this login form, fills it in with the user's domain user-id, and submits the login form to the server - the server performs the authentication as if it was the user himself who submitted the login form It's pretty neat in fact, but a bit mysterious as to how it works. But it works. No password is submitted, but cannot a password be blank ? beau.hutche...@thomsonreuters.com wrote: Hello: I am trying to integrate my application with an SSO partner application. After successfully logging into the partner app, I will be redirected and only provided a username to log into my tomcat Form Authentication app. I am using a DataSourceRealm to check for both Users and User Roles. Are there any suggestions as to how I can still authenticate() through the tomcat container without providing a password? Thanks for your attention, Beau - 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
Tomcat Form Authentication that requires no password for third party SSO
Hello: I am trying to integrate my application with an SSO partner application. After successfully logging into the partner app, I will be redirected and only provided a username to log into my tomcat Form Authentication app. I am using a DataSourceRealm to check for both Users and User Roles. Are there any suggestions as to how I can still authenticate() through the tomcat container without providing a password? Thanks for your attention, Beau - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Form Authentication that requires no password for third party SSO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Beau, On 1/26/2011 1:10 PM, beau.hutche...@thomsonreuters.com wrote: I am trying to integrate my application with an SSO partner application. What Tomcat version? I ask because Tomcat 7 includes the Servlet 3.0 programmatic login API. After successfully logging into the partner app, I will be redirected and only provided a username to log into my tomcat Form Authentication app. I am using a DataSourceRealm to check for both Users and User Roles. DataSourceRealm requires both username and password. I think JAASRealm might be able to help you. Also, one of the list contributors (Pid) is working on a realm to help with OpenSSO or something like that: he may have some ideas about how to set things up. Are there any suggestions as to how I can still authenticate() through the tomcat container without providing a password? Out of the box, I don't believe Tomcat can do this. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1ArocACgkQ9CaO5/Lv0PBVWwCgwvN2jma89OEB0QLPo+rAAnOX luAAoI/QXqxD1ZX3DhevcyxCyJDL+eCc =QXO9 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: failed FORM authentication redirects to /j_security_check
On 26/08/2010 02:14, Shaun Senecal wrote: Thanks for the response Chris. You're right. Jetty does a redirect, so on the client-side the browser sees /login.html?error=true. Since this isn't happening in Tomcat, I am unable to retrieve the query string client side. As you indicated my login page is static html and I am relying on client-side processing to interpret the query string. I ended up working around the issue by creating a loginerror.html which is identical to login.html except that I have added a hidden DIV to the loginerror.html. I can then search for the hidden DIV to determine if there was a login failure or not. Not pretty, but it works! If you're using client-side scripting, why not just set a class or id on the body for each type, instead of the hidden div? p Thanks Shaun On Wed, Aug 25, 2010 at 10:17 PM, Christopher Schultz ch...@christopherschultz.net wrote: Shaun, On 8/23/2010 4:56 AM, Shaun Senecal wrote: I'm using FORM authentication, and everything seems to be working (logins are accepted, etc), except when there was an error the URL changes in the users browser to point to j_security_check. This is expected. The contents of the redirect to j_security_check contains login.html, so the user is able to login as expected, but my error=true query string is not passed along. How are you checking? If you are forwarding to a .html page, you probably don't have any dynamic content in there, and therefore have no options for checking for things like request parameters. Is there something obvious I am doing wrong here? I got it working under Jetty as a sanity test, but I need to get it working in Tomcat too... It's possible that Jetty performs a redirect (to login.html?error=true) during a failed login and Tomcat performs a forward, which is entirely server-side. The result is that the client never sees the error=true and therefore only server-side components will be able to see it. -chris - 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 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: failed FORM authentication redirects to /j_security_check
Currently the only content in the HTML file is a script tag, since I am using GWT for the UI. I dont think there is any way I can set a class/id on a script tag, so I went with the empty DIV and put a known id on it. You're right though, I could have reused an existing element for this purpose as well. On Thu, Aug 26, 2010 at 5:17 PM, Pid p...@pidster.com wrote: On 26/08/2010 02:14, Shaun Senecal wrote: Thanks for the response Chris. You're right. Jetty does a redirect, so on the client-side the browser sees /login.html?error=true. Since this isn't happening in Tomcat, I am unable to retrieve the query string client side. As you indicated my login page is static html and I am relying on client-side processing to interpret the query string. I ended up working around the issue by creating a loginerror.html which is identical to login.html except that I have added a hidden DIV to the loginerror.html. I can then search for the hidden DIV to determine if there was a login failure or not. Not pretty, but it works! If you're using client-side scripting, why not just set a class or id on the body for each type, instead of the hidden div? p Thanks Shaun On Wed, Aug 25, 2010 at 10:17 PM, Christopher Schultz ch...@christopherschultz.net wrote: Shaun, On 8/23/2010 4:56 AM, Shaun Senecal wrote: I'm using FORM authentication, and everything seems to be working (logins are accepted, etc), except when there was an error the URL changes in the users browser to point to j_security_check. This is expected. The contents of the redirect to j_security_check contains login.html, so the user is able to login as expected, but my error=true query string is not passed along. How are you checking? If you are forwarding to a .html page, you probably don't have any dynamic content in there, and therefore have no options for checking for things like request parameters. Is there something obvious I am doing wrong here? I got it working under Jetty as a sanity test, but I need to get it working in Tomcat too... It's possible that Jetty performs a redirect (to login.html?error=true) during a failed login and Tomcat performs a forward, which is entirely server-side. The result is that the client never sees the error=true and therefore only server-side components will be able to see it. -chris - 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: failed FORM authentication redirects to /j_security_check
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shaun, On 8/23/2010 4:56 AM, Shaun Senecal wrote: I'm using FORM authentication, and everything seems to be working (logins are accepted, etc), except when there was an error the URL changes in the users browser to point to j_security_check. This is expected. The contents of the redirect to j_security_check contains login.html, so the user is able to login as expected, but my error=true query string is not passed along. How are you checking? If you are forwarding to a .html page, you probably don't have any dynamic content in there, and therefore have no options for checking for things like request parameters. Is there something obvious I am doing wrong here? I got it working under Jetty as a sanity test, but I need to get it working in Tomcat too... It's possible that Jetty performs a redirect (to login.html?error=true) during a failed login and Tomcat performs a forward, which is entirely server-side. The result is that the client never sees the error=true and therefore only server-side components will be able to see it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx1F/oACgkQ9CaO5/Lv0PBinQCfYr3S/2sEresGix7Qcd/waAow ltYAoIMMm/C9xFuMS5ixJ8jlsm1ensim =cFJK -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
