ISAPI Redicect - Request Entitiy too large
Hello @ll, I have installed a new Windows 2008 R2 x64 Server with IIS7 and Tomcat 6.0.32 x64 Edition. We use SSO Authentication from IIS to the Tomcat. Suddenly, we got on some clients, but not on every client (that´s stupid!) the following error: Request Entity Too large! The HTTP method does not allow the data transmitted, or the data volume exceeds the capacity limit. Jakarata/ISAPI/isapi_redirector/1.2.32 () The isapi.log contains the following messages in debug mode: [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] find_match::jk_uri_worker_map.c (863): Found a wildchar match '/jci/*=worker1' [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (1978): check if [/jci/] points to the web-inf directory [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (1994): [/jci/] is a servlet url - should redirect to worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (2034): fowarding escaped URI [/jci/] [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] wc_maintain::jk_worker.c (339): Maintaining worker worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3022): Reading extension header HTTP_TOMCATWORKER00018000: worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3023): Reading extension header HTTP_TOMCATWORKERIDX00018000: 3 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3024): Reading extension header HTTP_TOMCATURI00018000: /jci/ [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3025): Reading extension header HTTP_TOMCATQUERY00018000: (null) [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3085): Applying service extensions [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Connection : Keep-Alive [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Content-Length : 0 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept : */* [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept-Encoding : gzip, deflate [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept-Language : de-DE [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Host : b0621s008 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header User-Agent : Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727) [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3344): Service protocol=HTTP/1.1 method=GET host=fe80::3d83:4ce1:6ac:83dd%11 addr=fe80::3d83:4ce1:6ac:83dd%11 name=b0621s008 port=80 auth=Negotiate user=DOMAIN\USERNAME uri=/jci/ [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3356): Service request headers=8 attributes=0 chunked=no content-length=0 available=0 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] wc_get_worker_for_name::jk_worker.c (116): found a worker worker1 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] HttpExtensionProc::jk_isapi_plugin.c (2228): got a worker for name worker1 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] ajp_get_endpoint::jk_ajp_common.c (3161): acquired connection pool slot=0 after 0 retries [Fri Sep 30 15:06:08.460 2011] [3456:1540] [error] ajp_marshal_into_msgb::jk_ajp_common.c (469): failed appending the header value [Fri Sep 30 15:06:08.460 2011] [3456:1540] [info] ajp_service::jk_ajp_common.c (2431): Creating AJP message failed, without recovery [Fri Sep 30 15:06:08.460 2011] [3456:1540] [error] HttpExtensionProc::jk_isapi_plugin.c (2261): service() failed with http error 413 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] ajp_reset_endpoint::jk_ajp_common.c (807): (worker1) resetting endpoint with socket -1 (socket shutdown) [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] ajp_done::jk_ajp_common.c (3078): recycling connection pool slot=0 for worker worker1 smime.p7s Description: S/MIME cryptographic signature
Re: ISAPI Redicect - Request Entitiy too large
Alexander Diedler wrote: Hello @ll, I have installed a new Windows 2008 R2 x64 Server with IIS7 and Tomcat 6.0.32 x64 Edition. We use SSO Authentication from IIS to the Tomcat. Which SSO mechanism ? Suddenly, we got on some clients, but not on every client (that´s stupid!) the following error: Request Entity Too large! which does look strange, considering that there is a Content-length: 0 header below. It looks a bit as if a HTTP *header* in the request was too large. Repeat question : can you be a bot more specific about the authentication mechanism used ? Also, if you can determine a difference, what is the difference between the clients where it happens, and the ones where it does not ? The HTTP method does not allow the data transmitted, or the data volume exceeds the capacity limit. Jakarata/ISAPI/isapi_redirector/1.2.32 () The isapi.log contains the following messages in debug mode: [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] find_match::jk_uri_worker_map.c (863): Found a wildchar match '/jci/*=worker1' [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (1978): check if [/jci/] points to the web-inf directory [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (1994): [/jci/] is a servlet url - should redirect to worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (2034): fowarding escaped URI [/jci/] [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] wc_maintain::jk_worker.c (339): Maintaining worker worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3022): Reading extension header HTTP_TOMCATWORKER00018000: worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3023): Reading extension header HTTP_TOMCATWORKERIDX00018000: 3 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3024): Reading extension header HTTP_TOMCATURI00018000: /jci/ [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3025): Reading extension header HTTP_TOMCATQUERY00018000: (null) [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3085): Applying service extensions [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Connection : Keep-Alive [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Content-Length : 0 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept : */* [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept-Encoding : gzip, deflate [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept-Language : de-DE [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Host : b0621s008 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header User-Agent : Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727) [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3344): Service protocol=HTTP/1.1 method=GET host=fe80::3d83:4ce1:6ac:83dd%11 addr=fe80::3d83:4ce1:6ac:83dd%11 name=b0621s008 port=80 auth=Negotiate user=DOMAIN\USERNAME uri=/jci/ [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3356): Service request headers=8 attributes=0 chunked=no content-length=0 available=0 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] wc_get_worker_for_name::jk_worker.c (116): found a worker worker1 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] HttpExtensionProc::jk_isapi_plugin.c (2228): got a worker for name worker1 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] ajp_get_endpoint::jk_ajp_common.c (3161): acquired connection pool slot=0 after 0 retries [Fri Sep 30 15:06:08.460 2011] [3456:1540] [error] ajp_marshal_into_msgb::jk_ajp_common.c (469): failed appending the header value [Fri Sep 30 15:06:08.460 2011] [3456:1540] [info] ajp_service::jk_ajp_common.c (2431): Creating AJP message failed, without recovery [Fri Sep 30 15:06:08.460 2011] [3456:1540] [error] HttpExtensionProc::jk_isapi_plugin.c (2261): service() failed with http error 413 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] ajp_reset_endpoint::jk_ajp_common.c (807): (worker1) resetting endpoint with socket -1 (socket shutdown) [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug]
Re: problem with session replication in tomcat 5.5.23
Really any idea? Il giorno 04/ott/2011 19:13, Gabriele Faelli gabriele.fae...@gmail.com ha scritto: Hi all, I'm running tomcat 5.5.23 on two RHEL 5.6. I'm having big trouble making the session replication working across these two nodes. I configured a cluster and it looks like working: each node discovers the other one, I can see in the logs every received and transmitted ping. Well, when I create a session in the logs there are no mention of sessions being replicated and/or errors encounter while trying. The applications running on tomcat have the distributable/ entry in their web.xml and this is the cluster config part of the server.xml: Cluster className=org.apache.catalina.cluster.tcp.SimpleTcpCluster defaultMode=true managerClassName=org.apache.catalina.cluster.session.DeltaManager manager.expireSessionsOnShutdown=false manager.useDirtyFlag=false manager.notifyListenersOnReplication=true manager.notifySessionListenersOnReplication=true manager.sendAllSessions=true Membership className=org.apache.catalina.cluster.mcast.McastService mcastAddr=228.0.0.4 mcastPort=45564 mcastFrequency=500 mcastDropTime=3000/ Receiver className=org.apache.catalina.cluster.tcp.ReplicationListener tcpListenAddress=192.168.199.101 tcpListenPort=4001 tcpSelectorTimeout=100 tcpThreadCount=6/ Sender className=org.apache.catalina.cluster.tcp.ReplicationTransmitter replicationMode=synchronous ackTimeout=15000 waitForAck=true autoConnect=true/ Valve className=org.apache.catalina.cluster.tcp.ReplicationValve filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/ Deployer className=org.apache.catalina.cluster.deploy.FarmWarDeployer tempDir=/tmp/war-temp/ deployDir=/tmp/war-deploy/ watchDir=/tmp/war-listen/ watchEnabled=false/ ClusterListener className=org.apache.catalina.cluster.session.ClusterSessionListener/ /Cluster Any Idea? Where I'm wrong? I did something stupid for sure :) I tried every configuration, suggest... well everything I found on the official an unofficial documentation... I'm quite frustated :P Thanks in advance G.
AW: ISAPI Redicect - Request Entitiy too large
Hello, We use the IIS integrated (Windows) domain authentication, which is passed to the Tomcat and then we check the given String with our user database in the app and if username and password match, the user was automatically logged in (SSO). Greetings Alexander -Ursprüngliche Nachricht- Von: André Warnier [mailto:a...@ice-sa.com] Gesendet: Mittwoch, 5. Oktober 2011 10:15 An: Tomcat Users List Betreff: Re: ISAPI Redicect - Request Entitiy too large Alexander Diedler wrote: Hello @ll, I have installed a new Windows 2008 R2 x64 Server with IIS7 and Tomcat 6.0.32 x64 Edition. We use SSO Authentication from IIS to the Tomcat. Which SSO mechanism ? Suddenly, we got on some clients, but not on every client (that´s stupid!) the following error: Request Entity Too large! which does look strange, considering that there is a Content-length: 0 header below. It looks a bit as if a HTTP *header* in the request was too large. Repeat question : can you be a bot more specific about the authentication mechanism used ? Also, if you can determine a difference, what is the difference between the clients where it happens, and the ones where it does not ? The HTTP method does not allow the data transmitted, or the data volume exceeds the capacity limit. Jakarata/ISAPI/isapi_redirector/1.2.32 () The isapi.log contains the following messages in debug mode: [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] find_match::jk_uri_worker_map.c (863): Found a wildchar match '/jci/*=worker1' [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (1978): check if [/jci/] points to the web-inf directory [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (1994): [/jci/] is a servlet url - should redirect to worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (2034): fowarding escaped URI [/jci/] [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] wc_maintain::jk_worker.c (339): Maintaining worker worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3022): Reading extension header HTTP_TOMCATWORKER00018000: worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3023): Reading extension header HTTP_TOMCATWORKERIDX00018000: 3 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3024): Reading extension header HTTP_TOMCATURI00018000: /jci/ [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3025): Reading extension header HTTP_TOMCATQUERY00018000: (null) [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3085): Applying service extensions [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Connection : Keep-Alive [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Content-Length : 0 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept : */* [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept-Encoding : gzip, deflate [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept-Language : de-DE [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Host : b0621s008 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header User-Agent : Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727) [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3344): Service protocol=HTTP/1.1 method=GET host=fe80::3d83:4ce1:6ac:83dd%11 addr=fe80::3d83:4ce1:6ac:83dd%11 name=b0621s008 port=80 auth=Negotiate user=DOMAIN\USERNAME uri=/jci/ [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3356): Service request headers=8 attributes=0 chunked=no content-length=0 available=0 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] wc_get_worker_for_name::jk_worker.c (116): found a worker worker1 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] HttpExtensionProc::jk_isapi_plugin.c (2228): got a worker for name worker1 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] ajp_get_endpoint::jk_ajp_common.c (3161): acquired connection pool slot=0 after 0 retries [Fri Sep 30 15:06:08.460 2011] [3456:1540] [error]
Re: AW: ISAPI Redicect - Request Entitiy too large
Alexander Diedler wrote: Hello, We use the IIS integrated (Windows) domain authentication, which is passed to the Tomcat and then we check the given String with our user database in the app and if username and password match, the user was automatically logged in (SSO). Ok, basically thanks. I just wanted to know if the NTLM authentication dialog could explain some extra-large headers. But in this case, apparently not, since the authentication dialog happens between the browser and IIS, and should not even be seen in Tomcat. (Apart from the final Authorization: header). One item in your above explanation does not fit : username and password cannot be. There is no way that the IIS authentication would produce a user password that you can pass on to Tomcat. Userid yes, password no. (But it does not matter for the current issue). Anyway, what about a difference between the workstations for which it happens, and the ones for which it does not ? any visible OS/browser difference ? Greetings Alexander -Ursprüngliche Nachricht- Von: André Warnier [mailto:a...@ice-sa.com] Gesendet: Mittwoch, 5. Oktober 2011 10:15 An: Tomcat Users List Betreff: Re: ISAPI Redicect - Request Entitiy too large Alexander Diedler wrote: Hello @ll, I have installed a new Windows 2008 R2 x64 Server with IIS7 and Tomcat 6.0.32 x64 Edition. We use SSO Authentication from IIS to the Tomcat. Which SSO mechanism ? Suddenly, we got on some clients, but not on every client (that´s stupid!) the following error: Request Entity Too large! which does look strange, considering that there is a Content-length: 0 header below. It looks a bit as if a HTTP *header* in the request was too large. Repeat question : can you be a bot more specific about the authentication mechanism used ? Also, if you can determine a difference, what is the difference between the clients where it happens, and the ones where it does not ? The HTTP method does not allow the data transmitted, or the data volume exceeds the capacity limit. Jakarata/ISAPI/isapi_redirector/1.2.32 () The isapi.log contains the following messages in debug mode: [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] find_match::jk_uri_worker_map.c (863): Found a wildchar match '/jci/*=worker1' [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (1978): check if [/jci/] points to the web-inf directory [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (1994): [/jci/] is a servlet url - should redirect to worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (2034): fowarding escaped URI [/jci/] [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] wc_maintain::jk_worker.c (339): Maintaining worker worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3022): Reading extension header HTTP_TOMCATWORKER00018000: worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3023): Reading extension header HTTP_TOMCATWORKERIDX00018000: 3 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3024): Reading extension header HTTP_TOMCATURI00018000: /jci/ [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3025): Reading extension header HTTP_TOMCATQUERY00018000: (null) [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3085): Applying service extensions [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Connection : Keep-Alive [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Content-Length : 0 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept : */* [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept-Encoding : gzip, deflate [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept-Language : de-DE [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Host : b0621s008 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header User-Agent : Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727) [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3344): Service protocol=HTTP/1.1 method=GET host=fe80::3d83:4ce1:6ac:83dd%11 addr=fe80::3d83:4ce1:6ac:83dd%11 name=b0621s008
Re: AW: ISAPI Redicect - Request Entitiy too large
Addendum : can you increase the log level of isapi_redirect on the IIS server, and try again ? it may show us a bit more about what is happening. André Warnier wrote: Alexander Diedler wrote: Hello, We use the IIS integrated (Windows) domain authentication, which is passed to the Tomcat and then we check the given String with our user database in the app and if username and password match, the user was automatically logged in (SSO). Ok, basically thanks. I just wanted to know if the NTLM authentication dialog could explain some extra-large headers. But in this case, apparently not, since the authentication dialog happens between the browser and IIS, and should not even be seen in Tomcat. (Apart from the final Authorization: header). One item in your above explanation does not fit : username and password cannot be. There is no way that the IIS authentication would produce a user password that you can pass on to Tomcat. Userid yes, password no. (But it does not matter for the current issue). Anyway, what about a difference between the workstations for which it happens, and the ones for which it does not ? any visible OS/browser difference ? Greetings Alexander -Ursprüngliche Nachricht- Von: André Warnier [mailto:a...@ice-sa.com] Gesendet: Mittwoch, 5. Oktober 2011 10:15 An: Tomcat Users List Betreff: Re: ISAPI Redicect - Request Entitiy too large Alexander Diedler wrote: Hello @ll, I have installed a new Windows 2008 R2 x64 Server with IIS7 and Tomcat 6.0.32 x64 Edition. We use SSO Authentication from IIS to the Tomcat. Which SSO mechanism ? Suddenly, we got on some clients, but not on every client (that´s stupid!) the following error: Request Entity Too large! which does look strange, considering that there is a Content-length: 0 header below. It looks a bit as if a HTTP *header* in the request was too large. Repeat question : can you be a bot more specific about the authentication mechanism used ? Also, if you can determine a difference, what is the difference between the clients where it happens, and the ones where it does not ? The HTTP method does not allow the data transmitted, or the data volume exceeds the capacity limit. Jakarata/ISAPI/isapi_redirector/1.2.32 () The isapi.log contains the following messages in debug mode: [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] find_match::jk_uri_worker_map.c (863): Found a wildchar match '/jci/*=worker1' [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (1978): check if [/jci/] points to the web-inf directory [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (1994): [/jci/] is a servlet url - should redirect to worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (2034): fowarding escaped URI [/jci/] [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] wc_maintain::jk_worker.c (339): Maintaining worker worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3022): Reading extension header HTTP_TOMCATWORKER00018000: worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3023): Reading extension header HTTP_TOMCATWORKERIDX00018000: 3 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3024): Reading extension header HTTP_TOMCATURI00018000: /jci/ [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3025): Reading extension header HTTP_TOMCATQUERY00018000: (null) [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3085): Applying service extensions [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Connection : Keep-Alive [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Content-Length : 0 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept : */* [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept-Encoding : gzip, deflate [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept-Language : de-DE [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Host : b0621s008 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header User-Agent : Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727) [Fri Sep 30 15:06:08.460 2011] [3456:1540]
AW: AW: ISAPI Redicect - Request Entitiy too large
Hello, Please find below the full loglevel from isapi with level debug for the single request to access a url/jci/ Yes, you are right. In the header will only be the username and domain passed to the application. In the application we make a request to query the NTLM with the given username and the current logged in user credentials. So no password will be transferred from browser to IIS resp. Tomcat. [Fri Sep 30 15:06:06.320 2011] [3456:1540] [debug] jk_set_time_fmt::jk_util.c (459): Pre-processed log time stamp format is '[%a %b %d %H:%M:%S.000 %Y] ' [Fri Sep 30 15:06:06.320 2011] [3456:1540] [info] init_jk::jk_isapi_plugin.c (2602): Starting Jakarta/ISAPI/isapi_redirector/1.2.32 () [Fri Sep 30 15:06:06.320 2011] [3456:1540] [debug] init_jk::jk_isapi_plugin.c (2620): Detected IIS version 7.5 [Fri Sep 30 15:06:06.320 2011] [3456:1540] [debug] init_jk::jk_isapi_plugin.c (2622): Using ini file D:\tecracer\software\tomcat\isapi\isapi_redirect.properties. [Fri Sep 30 15:06:06.320 2011] [3456:1540] [debug] init_jk::jk_isapi_plugin.c (2628): Using log file d:\tecracer\software\tomcat\logs\isapi_redirect.log. [Fri Sep 30 15:06:06.320 2011] [3456:1540] [debug] init_jk::jk_isapi_plugin.c (2629): Using log level 1. [Fri Sep 30 15:06:06.320 2011] [3456:1540] [debug] init_jk::jk_isapi_plugin.c (2630): Using log rotation time 0 seconds. [Fri Sep 30 15:06:06.320 2011] [3456:1540] [debug] init_jk::jk_isapi_plugin.c (2631): Using log file size 0 bytes. [Fri Sep 30 15:06:06.320 2011] [3456:1540] [debug] init_jk::jk_isapi_plugin.c (2633): Using extension uri /tomcat/isapi_redirect.dll. [Fri Sep 30 15:06:06.320 2011] [3456:1540] [debug] init_jk::jk_isapi_plugin.c (2634): Using worker file d:\tecracer\software\tomcat\conf\workers.properties. [Fri Sep 30 15:06:06.320 2011] [3456:1540] [debug] init_jk::jk_isapi_plugin.c (2635): Using worker mount file d:\tecracer\software\tomcat\conf\uriworkermap.properties. [Fri Sep 30 15:06:06.320 2011] [3456:1540] [debug] init_jk::jk_isapi_plugin.c (2637): Using rewrite rule file . [Fri Sep 30 15:06:06.320 2011] [3456:1540] [debug] init_jk::jk_isapi_plugin.c (2639): Using uri select 3. [Fri Sep 30 15:06:06.335 2011] [3456:1540] [debug] init_jk::jk_isapi_plugin.c (2640): Using no chunked encoding. [Fri Sep 30 15:06:06.335 2011] [3456:1540] [debug] init_jk::jk_isapi_plugin.c (2642): Using notification event SF_NOTIFY_AUTH_COMPLETE (0x0400) [Fri Sep 30 15:06:06.335 2011] [3456:1540] [debug] init_jk::jk_isapi_plugin.c (2652): Using uri header TOMCATURI00018000:. [Fri Sep 30 15:06:06.335 2011] [3456:1540] [debug] init_jk::jk_isapi_plugin.c (2653): Using query header TOMCATQUERY00018000:. [Fri Sep 30 15:06:06.335 2011] [3456:1540] [debug] init_jk::jk_isapi_plugin.c (2654): Using worker header TOMCATWORKER00018000:. [Fri Sep 30 15:06:06.335 2011] [3456:1540] [debug] init_jk::jk_isapi_plugin.c (2655): Using worker index TOMCATWORKERIDX00018000:. [Fri Sep 30 15:06:06.335 2011] [3456:1540] [debug] init_jk::jk_isapi_plugin.c (2656): Using translate header TOMCATTRANSLATE00018000:. [Fri Sep 30 15:06:06.335 2011] [3456:1540] [debug] init_jk::jk_isapi_plugin.c (2657): Using a default of 250 connections per pool. [Fri Sep 30 15:06:06.335 2011] [3456:1540] [debug] jk_map_read_property::jk_map.c (491): Adding property '/admin/*' with value 'worker1' to map. [Fri Sep 30 15:06:06.335 2011] [3456:1540] [debug] jk_map_read_property::jk_map.c (491): Adding property '/manager/*' with value 'worker1' to map. [Fri Sep 30 15:06:06.335 2011] [3456:1540] [debug] jk_map_read_property::jk_map.c (491): Adding property '/examples/*' with value 'worker1' to map. [Fri Sep 30 15:06:06.335 2011] [3456:1540] [debug] jk_map_read_property::jk_map.c (491): Adding property '/jci/*' with value 'worker1' to map. [Fri Sep 30 15:06:06.335 2011] [3456:1540] [debug] uri_worker_map_load::jk_uri_worker_map.c (1102): Loading urimaps from d:\tecracer\software\tomcat\conf\uriworkermap.properties with reload check interval 60 seconds [Fri Sep 30 15:06:06.335 2011] [3456:1540] [debug] uri_worker_map_add::jk_uri_worker_map.c (720): wildchar rule '/admin/*=worker1' source 'uriworkermap' was added [Fri Sep 30 15:06:06.335 2011] [3456:1540] [debug] uri_worker_map_add::jk_uri_worker_map.c (720): wildchar rule '/manager/*=worker1' source 'uriworkermap' was added [Fri Sep 30 15:06:06.335 2011] [3456:1540] [debug] uri_worker_map_add::jk_uri_worker_map.c (720): wildchar rule '/examples/*=worker1' source 'uriworkermap' was added [Fri Sep 30 15:06:06.351 2011] [3456:1540] [debug] uri_worker_map_add::jk_uri_worker_map.c (720): wildchar rule '/jci/*=worker1' source 'uriworkermap' was added [Fri Sep 30 15:06:06.351 2011] [3456:1540] [debug] uri_worker_map_dump::jk_uri_worker_map.c (171): uri map dump after file load: index=0 file='d:\tecracer\software\tomcat\conf\uriworkermap.properties' reject_unsafe=0 reload=60 modified=1317371602 checked=1317387966 [Fri Sep 30 15:06:06.351 2011]
Re: AW: ISAPI Redicect - Request Entitiy too large
Alexander, If you are using authorisation header, then you are using SPNGEO. This header encodes the users group membership in the authorisation header. By default tomcat has an 8k maximum header, whilst users belonging to many groups can have an authorisation token that can swell to larger than this size. This explains why you see some people can login and others can't. Just change the maxHttpHeaderSize to something larger than the default 8k and you should be set. We used 32k Chris
Regarding Catalina/Tomcat MBeans attributes/operations description
Hi, Can anyone tell me where can I get the Catalina MBeans field description. I mean what exactly particular attribute of particular MBean is providing. e.g. In ThreadPool There are two attributes in Mbean http-8080 1. currentThreadCount 2. currentThreadsBusy I'm not able to understand what each of these is doing. Can I get any documentation related to this? I checked the Tomcat documentation but there is not description of MBeans. Thanks. Akshay
Cocoon - Tomcat - APEX for FOP PDF printing
I am trying to setup Tomcat with Cocoon for the purpose of enabling PDF printing with Oracle APEX using FOP. I'm using Linux 64bit, Tomcat 7.0.22, Cocoon 2.1.11, and JDK (build 1.6.0_24-b07). Whenever, I attempt to hit the cocoon site (localhost:8080/cocoon/), I receive the following error: org.apache.cocoon. ResourceNotFoundException: No pipeline matched request: index.html I can see this error in the Tomcat log: SEVERE: The web application [/cocoon] appears to have started a thread named [HSQLDB Timer @6b033450] but has failed to stop it. This is very likely to create a memory leak. Other than these errors, the Tomcat and Cocoon appear to be installed properly and functioning properly. However, I cannot get past these errors. Please provide any insights you may have about using Cocoon with Tomcat. Or, what else I can check to see why Cocoon isn't working with Tomcat. Many Thanks, in advance, for your help Reid
Re: Regarding Catalina/Tomcat MBeans attributes/operations description
2011/10/5 akshay hiremath akshay...@yahoo.com: Hi, Can anyone tell me where can I get the Catalina MBeans field description. I mean what exactly particular attribute of particular MBean is providing. e.g. In ThreadPool There are two attributes in Mbean http-8080 1. currentThreadCount 2. currentThreadsBusy I'm not able to understand what each of these is doing. Can I get any documentation related to this? I checked the Tomcat documentation but there is not description of MBeans. If it is not in the docs, then read the source code. MBeans are defined by mbeans-descriptors.xml files, and are implemented by properties in Java objects represented by those beans. You are not saying what Tomcat version you are using. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cocoon - Tomcat - APEX for FOP PDF printing
2011/10/5 Reid McKinley reidmckin...@gmail.com: I am trying to setup Tomcat with Cocoon for the purpose of enabling PDF printing with Oracle APEX using FOP. I'm using Linux 64bit, Tomcat 7.0.22, Cocoon 2.1.11, and JDK (build 1.6.0_24-b07). Whenever, I attempt to hit the cocoon site (localhost:8080/cocoon/), I receive the following error: org.apache.cocoon. ResourceNotFoundException: No pipeline matched request: index.html You would better ask it on a cocoon-related mailing list, http://cocoon.apache.org/mail-lists.html http://cocoon.apache.org/1275_1_1.html I can see this error in the Tomcat log: SEVERE: The web application [/cocoon] appears to have started a thread named [HSQLDB Timer @6b033450] but has failed to stop it. This is very likely to create a memory leak. A leak in HSQLDB. It would waste your memory, but it would not prevent your app from functioning. I think that mitigation options were already discussed several times -- search the archives of this mailing list. Other than these errors, the Tomcat and Cocoon appear to be installed properly and functioning properly. However, I cannot get past these errors. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Denying IPs using the Valve command in context.xml
Part of the problem with this valve is that regex matching is such a (IMHO) bizarre choice for IP address matching. IP addresses have a structure which is very unlike text, and the customary and expected matches take a bit of finagling to do in regexes. I should try writing netmask and CIDR address matchers. Likewise the hostname valve. Domain names also are structured, and people who have just discovered the valve may be expecting quite a different type of matching than what they get. I had to read the documentation very slowly and carefully before I could get the customary match styles out of my head. Again, I should try writing a DNS-style globber. It might be fun. (But don't hold your breath waiting for it.) -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. pgpBlPBdN6hmN.pgp Description: PGP signature
Re: Denying IPs using the Valve command in context.xml
On Wed, Oct 5, 2011 at 15:57, Mark H. Wood mw...@iupui.edu wrote: Part of the problem with this valve is that regex matching is such a (IMHO) bizarre choice for IP address matching. IP addresses have a structure which is very unlike text, and the customary and expected matches take a bit of finagling to do in regexes. I should try writing netmask and CIDR address matchers. I'm doing just that at the moment :p https://issues.apache.org/bugzilla/show_bug.cgi?id=51953 Likewise the hostname valve. Domain names also are structured, and people who have just discovered the valve may be expecting quite a different type of matching than what they get. I had to read the documentation very slowly and carefully before I could get the customary match styles out of my head. Again, I should try writing a DNS-style globber. It might be fun. (But don't hold your breath waiting for it.) Ideally, all of Apache's allow from and deny from (along with Order while we are at it) could/should be implemented. I'm starting with the most simple case of all. It'll be fun to implement, say, 10., .mydomain.com and such... -- Francis Galiegue ONE2TEAM Ingénieur système Mob : +33 (0) 683 877 875 Tel : +33 (0) 178 945 552 f...@one2team.com 40 avenue Raymond Poincaré 75116 Paris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk 1.2.30 error problem after upgrade
Anthony J. Biacco abiacco at formatdynamics.com writes: I may have found it from 5 minutes earlier, I didn't go back that far in the log. I'll mail it privately, I don't feel comfortable posting the content in whole publicly, if that's alright. Thanks again. -Tony --- Manager, IT Operations Format Dynamics, Inc. 303-573-1800x27 abiacco at formatdynamics.com http://www.formatdynamics.com -Original Message- From: Mladen Turk [mailto:mturk at apache.org] Sent: Wednesday, March 17, 2010 12:57 PM To: users at tomcat.apache.org Subject: Re: mod_jk 1.2.30 error problem after upgrade On 03/17/2010 07:15 PM, Anthony J. Biacco wrote: On 03/16/2010 10:07 PM, Anthony J. Biacco wrote: The errors are: [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (1152): sending to ajp13 pos=4 len=4 max=8192 [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (1152): 12 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - .4.. Do you have browser stop sending data, no need to recover message before those two? I do not. I don't see anything other than the snippet I posted. And they're all the same as the above one. I do notice that successful ones look like this: There must be something calling ajp_connection_tcp_send_message. It sends the zero length message, so it's hard to figure out from the snippet you gave. You'll have to post the larger one (for the same pid) that causes that. Regards -- ^TM - To unsubscribe, e-mail: users-unsubscribe at tomcat.apache.org For additional commands, e-mail: users-help at tomcat.apache.org Hi Anthony, Did you find any soluction to this problem. I also have the same problem and tried all known possible solution but no luck. Appreciate if you can share your solution. [Mon Sep 19 16:19:45 2011] [26120:1328027968] [debug] jk_map_to_storage::mod_jk.c (3603): no match for /healthcheck/clover.html found [Mon Sep 19 16:19:46 2011] [26122:1325082944] [debug] ajp_send_request::jk_ajp_common.c (1643): (tomcat01) browser stop sending data, no need to recover [Mon Sep 19 16:19:46 2011] [26122:1325082944] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (1070): sending to ajp13 pos=4 len=6 max=8192 [Mon Sep 19 16:19:46 2011] [26122:1325082944] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (1070): 12 34 00 02 00 00 00 00 00 00 00 00 00 00 00 00 - .4.. [Mon Sep 19 16:19:46 2011] [26122:1325082944] [info] ajp_service::jk_ajp_common.c (2447): (tomcat01) sending request to tomcat failed (unrecoverable), because of client read error (attempt=1) [Mon Sep 19 16:19:46 2011] [26122:1325082944] [debug] ajp_reset_endpoint::jk_ajp_common.c (743): (tomcat01) resetting endpoint with sd = 20 (socket shutdown) [Mon Sep 19 16:19:46 2011] [26122:1325082944] [debug] jk_shutdown_socket::jk_connect.c (681): About to shutdown socket 20 [Mon Sep 19 16:19:46 2011] [26122:1325082944] [debug] jk_shutdown_socket::jk_connect.c (689): Failed sending SHUT_WR for socket 20 [Mon Sep 19 16:19:46 2011] [26122:1325082944] [debug] ajp_done::jk_ajp_common.c (2905): recycling connection pool slot=0 for worker tomcat01 [Mon Sep 19 16:19:46 2011] [26122:1325082944] [info] service::jk_lb_worker.c (1384): service failed, worker tomcat01 is in local error state [Mon Sep 19 16:19:46 2011] [26122:1325082944] [info] service::jk_lb_worker.c (1403): unrecoverable error 400, request failed. Client failed in the middle of request, we can't recover to another instance. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Denying IPs using the Valve command in context.xml
On Tue, Oct 04, 2011 at 09:11:28PM +0200, Francis GALIEGUE wrote: On Tue, Oct 4, 2011 at 21:08, Christopher Schultz ch...@christopherschultz.net wrote: [...] - From the docs: If this attribute [allow] is specified, the remote address MUST match for this request to be accepted. If this attribute [deny] is specified, the remote address MUST NOT match for this request to be accepted. I don't think Matacher.lookingAt is appropriate for this kind of checking. Well, it depends on the definition of match, I guess. For me, a regex matches an input if it matches anywhere in the input! Which is pretty much the definition of regex matching, and which is why Java's .matches() methods are misnomers... Hmmm, old SNOBOL coders may recall the handy concept of anchored (.matches(), .lookingAt()) vs. unanchored (.find()) matching. The actual difference between matches() and lookingAt() is that of matching the entire string vs. matching a prefix. Having said that, I think that an anchored partial match (lookingAt()) really is the least-bad fit to the address problem, since we're usually more concerned about the first, second, and perhaps third quads of an IP address and the trailing part is considered insignificant. As I posted previously, though, it's still pretty bad: how would you match a /27? Domain matches, OTOH, might take matches() as least-bad of the regex types, since the prefix tends to be the don't-care part. Again, though, since domain structure is significant, regex matching tends to require a lot of complexity that could be considered boilerplate: you almost always need to write all the fiddly escaped dots and stuff. (If you think SNOBOL is ancient: I'm trying to recall whether COMIT II embodied all of these concepts. :-) -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. pgpk3QsMKeVYM.pgp Description: PGP signature
Problem with Tomcat 6.0.33 Session replication
I'm running 2 servers with Tomcat 6.0.33 and session replication. Tomcat session replication only works with Tomcat starting the first time the server (Windows Server 2008 R2 64-bit) boots. When I stop and then start the Tomcat service via Windows Services, session replication will no longer work until the next reboot of that server (the Tomcat service is automatically started on startup). Has anybody experienced this before or have any pointers on where to start looking for issues? In the catalina logs, the only indicator I get is: INFO: Manager [/cas]: skipping state transfer. No members active in cluster group. Thank you, Tobias - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Using multiple login pages
This follows on from yesterday's discussion about whether in my application, I can have more than one page with an embedded login form or not. I've been looking over the servlet spec (V2.2) and it seems that I can't actually do this which is a shame. So I'm now looking at a more conventional log in from a login page. But can anyone explain to me why I dont see my login page when I run the application? Login.jsp contains the following: form action = c:url value = 'j_security_check' / method = post table align = center border = 0 cellspacing = 0 tr th align = rightfont class = labelUsername/font/th td align = leftinput class = textInput name = j_username type = text/td /tr tr th align = rightfont class = labelPassword/font/th td align = leftinput class = textInput name = j_password type = password/td /tr tr td/td td input class = button type = submit value = Log in input class = button type = reset value = Clear /td /tr /table /form Which corresponds to the following in web.xml: welcome-file-list welcome-file/jsp/about/concept.jsp/welcome-file /welcome-file-list security-constraint display-nameSecurity Constraint/display-name web-resource-collection web-resource-namemyApp/web-resource-name description/ url-pattern/aboutConcept/url-pattern /web-resource-collection auth-constraint description/ role-nameADMIN/role-name /auth-constraint user-data-constraint description/ transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint login-config auth-methodFORM/auth-method realm-nameForm-Based Authentication Area/realm-name form-login-config form-login-page/jsp/security/protected/login.jsp/form-login-page form-error-page/jsp/security/protected/error.jsp/form-error-page /form-login-config /login-config security-role description/ role-nameADMIN/role-name /security-role But when I run the application, all I get is the html of the page specified in the welcome file list? But if I then invoke a link from the welcome file, I get the login page. Surely it should be the other way around? -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: 04 Oct 2011 19 56 To: Tomcat Users List Subject: Re: Using multiple login pages app...@dsl.pipex.com wrote: Not sure about which version of security I will use but I would like to accommodate MD5 verification into things. There's no sensitive or confidential info in the system either so protected page access may not be required. I don't know what you have in mind, but there are some basic principles to avoid wasting your time : 1) In Tomcat (and other servlet engines), there are 2 different ways of doing authentication : - declarative, as per web.xml. In that case Tomcat, /before it evens calls the webapp or any filter in it/, intercepts a non-authenticated call and returns *the* login form to the browser. It then (later) intercepts the submit of that form by the browser, checks the credentials, and if they pass muster, it allows the call to proceed to the webapp which the user wanted in the first place. - application- or filter-based authentication : in this case, Tomcat is not aware that there is an authentication taking place. It forwards the call to the webapp, and a filter /in the webapp/ intercepts the call and does whatever is needed to check the authentication, return a login form etc.. This second authentication scheme is probably more flexible for doing the kind of thing you seem to want to do (but also more complex to do). 2) There already exist a number of authentication systems on the market. Unless this is considered as an exercise, re-use an existing one instead of rolling you own. Web authentication looks deceptively simple, but is in fact quite complex and delicate, and open to many mistakes which completely defeat the purpose. (This being said, if it is an exercise, it is an interesting area). 3) anything that your server sends to a browser should be considered open and lost. Once you send something out there, the recipient can do with it what he wants : save it, analyse it, copy it, decompile it, falsify it, re-send it to your server and whatnot. There is no practical way to avoid that. (You don't even know that it is really a browser out there). 4) the only good way to secure things if you do form authentication, is to work over HTTPS. The customer is going to type a
logging.properties and no classdef error when trying to switch to log4j 6.0.18
I am trying to configure log4j logging, but when I remove the conf/logging.properties file I get the following error in catalina.out and nothing more. Could not find the main class: . Program will exit. java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina at java.net.URLClassLoader$1.run(Unknown Source) Googling around I found that the logging.properties files missing causes the problem (multiple posts) but if I dont remove I still see the commons loggings file output even though I have replace the juli jar files in both CATALINA_HOME and CATALINA_BASE with the versions downloaded from bin/extras. Any ideas on what I should check next. I'm guessing it is stil trying to use commons logging instead of log4j, but not sure why,. -- View this message in context: http://old.nabble.com/logging.properties-and-no-classdef-error-when-trying-to-switch-to-log4j-6.0.18-tp32595470p32595470.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: logging.properties and no classdef error when trying to switch to log4j 6.0.18
2011/10/5 jjgtx jeff_g...@yahoo.com: I am trying to configure log4j logging, but when I remove the conf/logging.properties file I get the following error in catalina.out and nothing more. Could not find the main class: . Program will exit. java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina at java.net.URLClassLoader$1.run(Unknown Source) 1. 6.0.18 is old. Why don't you upgrade to a more recent version. Also, have you read the docs? 2. Just removing the logging.properties file should not have caused this error. It is likely that you broke something else as well. There were many fixes to startup scripts since 6.0.18 as well. 3. You can reconfigure the file to log everything to Console, but the file itself is needed. You can reconfigure Tomcat logging to use log4j, but you cannot turn off java.util.logging API of Java entirely. Bootstrap classes use it. Some web applications can use it as well. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Login or index page or vice-versa
This follows on from yesterday's discussion about whether in my application, I can have more than one page with an embedded login form or not. I've been looking over the servlet spec (V2.2) and it seems that I can't actually do this which is a shame. So I'm now looking at a more conventional log in from a login page. But can anyone explain to me why I dont see my login page when I run the application? Login.jsp contains the following: form action = c:url value = 'j_security_check' / method = post table align = center border = 0 cellspacing = 0 tr th align = rightfont class = labelUsername/font/th td align = leftinput class = textInput name = j_username type = text/td /tr tr th align = rightfont class = labelPassword/font/th td align = leftinput class = textInput name = j_password type = password/td /tr tr td/td td input class = button type = submit value = Log in input class = button type = reset value = Clear /td /tr /table /form Which corresponds to the following in web.xml: welcome-file-list welcome-file/jsp/about/concept.jsp/welcome-file /welcome-file-list security-constraint display-nameSecurity Constraint/display-name web-resource-collection web-resource-namemyApp/web-resource-name description/ url-pattern/aboutConcept/url-pattern /web-resource-collection auth-constraint description/ role-nameADMIN/role-name /auth-constraint user-data-constraint description/ transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint login-config auth-methodFORM/auth-method realm-nameForm-Based Authentication Area/realm-name form-login-config form-login-page/jsp/security/protected/login.jsp/form-login-page form-error-page/jsp/security/protected/error.jsp/form-error-page /form-login-config /login-config security-role description/ role-nameADMIN/role-name /security-role But when I run the application, all I get is the html of the page specified in the welcome file list? But if I then invoke a link from the welcome file, I get the login page. Surely it should be the other way around? -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: 04 Oct 2011 19 56 To: Tomcat Users List Subject: Re: Using multiple login pages app...@dsl.pipex.com wrote: Not sure about which version of security I will use but I would like to accommodate MD5 verification into things. There's no sensitive or confidential info in the system either so protected page access may not be required. I don't know what you have in mind, but there are some basic principles to avoid wasting your time : 1) In Tomcat (and other servlet engines), there are 2 different ways of doing authentication : - declarative, as per web.xml. In that case Tomcat, /before it evens calls the webapp or any filter in it/, intercepts a non-authenticated call and returns *the* login form to the browser. It then (later) intercepts the submit of that form by the browser, checks the credentials, and if they pass muster, it allows the call to proceed to the webapp which the user wanted in the first place. - application- or filter-based authentication : in this case, Tomcat is not aware that there is an authentication taking place. It forwards the call to the webapp, and a filter /in the webapp/ intercepts the call and does whatever is needed to check the authentication, return a login form etc.. This second authentication scheme is probably more flexible for doing the kind of thing you seem to want to do (but also more complex to do). 2) There already exist a number of authentication systems on the market. Unless this is considered as an exercise, re-use an existing one instead of rolling you own. Web authentication looks deceptively simple, but is in fact quite complex and delicate, and open to many mistakes which completely defeat the purpose. (This being said, if it is an exercise, it is an interesting area). 3) anything that your server sends to a browser should be considered open and lost. Once you send something out there, the recipient can do with it what he wants : save it, analyse it, copy it, decompile it, falsify it, re-send it to your server and whatnot. There is no practical way to avoid that. (You don't even know that it is really a browser out there). 4) the only good way to secure things if you do form authentication, is to work over HTTPS. The customer is going to type a
Re: WebApps sharing uploaded files
chris wrote: Be careful: if you undeploy the webapp, you will have all those files deleted by Tomcat. Ok. Thank you! André wrote: Thanks. Seen. Lea, do you follow ? Yes, thanks! Ok. I do not properly understand the doc.: http://tomcat.apache.org/tomcat-7.0-doc/config/context.html 1) aliases is an attribute. Is it an attribute of the Context element? 2) I have a context.xml file in META-INF in both w1 and w2. I have tried: 2.A) context.xml ?xml version='1.0' encoding='utf-8'? Context aliases=/attachments=C:\somewhere_1\somewhere_2\somewhere_3 [...] /Context 2.B) I've created a foo.txt file in the directory C:\somewhere_1\somewhere_2\somewhere_3\ 2.C) test_download.html html head titleTest download/title /head body /attachments/foo.txt Foo.txt /body /html When I click the link, I get a 404 error: HTTP Status 404 - /attachments/foo.txt type Status report message /attachments/foo.txt description The requested resource (/attachments/foo.txt) is not available. What am I doing wrong? Thank you and best regards, -- Léa -- View this message in context: http://old.nabble.com/WebApps-sharing-uploaded-files-tp32570911p32595832.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using multiple login pages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin, On 10/5/2011 11:41 AM, Martin O'Shea wrote: This follows on from yesterday's discussion about whether in my application, I can have more than one page with an embedded login form or not. I've been looking over the servlet spec (V2.2) and it seems that I can't actually do this which is a shame. Do what, have different login pages for different types of resources you're trying to reach? Sure you can: try reading my responses. So I'm now looking at a more conventional log in from a login page. But can anyone explain to me why I don’t see my login page when I run the application? Login.jsp contains the following: This isn't relevant if you're not seeing it. Which corresponds to the following in web.xml: welcome-file-list welcome-file/jsp/about/concept.jsp/welcome-file /welcome-file-list security-constraint web-resource-collection url-pattern/aboutConcept/url-pattern /web-resource-collection auth-constraint description/ role-nameADMIN/role-name /auth-constraint /security-constraint login-config form-login-config form-login-page/jsp/security/protected/login.jsp/form-login-page form-error-page/jsp/security/protected/error.jsp/form-error-page /form-login-config /login-config But when I run the application, all I get is the html of the page specified in the welcome file list? Is that a question or a statement? But if I then invoke a link from the welcome file, I get the login page. Surely it should be the other way around? Your welcome file is not protected in any way, so you are not challenged for credentials. If you want to login to see every page on your site, you should have url-pattern/*/url-pattern in your web-resource-collection. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6MlkYACgkQ9CaO5/Lv0PB3nQCfRf0g/erXaD2kOPyaBCMJW/h0 Ce0An0EbOElkSImGQYK8y+JkZdtcrIqL =wbh5 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 7 Embedded: Manager *additional info*
Hi guys *kick* :) I have additional info on this topic. When deploying a webapp to an embedded tomcat server via ANT and listen all webapps via ANT afterwards, I noticed that the path information is completely missing for the freshly deployed webapp. In this case /test. I think I missed to setup a path directive?! [LIST] OK - Listed applications for virtual host localhost [LIST] /manager:running:0:C:\Users\xx\AppData\Local\Temp\tc7embedded\webapps [LIST] /test:running:0:test Java Code: http://pastie.org/268 Cheers Darky Am 27.09.2011 16:46, schrieb Dark Before Dawn: Hi guys, I am sorry to resurrect this topic, but I got stuck for weeks now. I would like to provide an embedded Tomcat 7 instance in my JavaSE 1.6 application (diploma thesis). This instance should run the Manager-Application for easy War-Deployment via ANT. With help of this mailing-list I managed to create a privilged context which hosts the HTMLManagerServlet and the ManagerServlet. Both show up correctly when browsing: http://localhost:8080/manager/html/ http://localhost:8080/manager/text/ I guess the Deployer is running too = stdHost.addLifecycleListener(new HostConfig()); Problem 1: ANT Script ManagerServlet(Text): It is possible to deploy/undeploy/start/stop a Webapplication via ANT. When deploying a WAR-file via Ant the file will be uploaded to webapps folder and expanded afterwards. The ANT-script terminates successful without warning. When browsing the HTMLManagerServlet the freshly deployed webapp is shown correctly in the Application list. = ContextPath is correct and even the DisplayName is shown correctly. It is possible to Start/Stop/Repload/Undeploy this freshly deployed webapp(browser/ant). But it is not possible to browse this webapp, I just got 404 pages. Problem 2: HTMLManagerServlet won't upload WAR-file when selecting a WAR-file not located on the server. Message: FAIL - File upload failed, no file Folders: C:\Users\darky\AppData\Local\Temp\tc7embedded C:\Users\darky\AppData\Local\Temp\tc7embedded\work C:\Users\darky\AppData\Local\Temp\tc7embedded\webapps Code: http://pastie.org/268 Any help is appreciated! Thanks in advance! Cheers Darky - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Using multiple login pages
Maybe I've misunderstood something but I'm having a lot of trouble getting the login page to display with the following: welcome-file-list welcome-file/jsp/index/newjsp.jsp/welcome-file /welcome-file-list !-- Error pages. -- error-page error-code403/error-code location/jsp/error/error403.jsp/location /error-page error-page error-code404/error-code location/jsp/error/error404.jsp/location /error-page error-page error-code408/error-code location/jsp/error/error408.jsp/location /error-page error-page exception-typejava.lang.Throwable/exception-type location/jsp/error/error500.jsp/location /error-page !-- Accessibility. -- security-constraint display-nameSecurity Constraint/display-name web-resource-collection web-resource-namemyApp/web-resource-name description/ url-pattern/*/url-pattern /web-resource-collection auth-constraint description/ role-nameADMIN/role-name /auth-constraint user-data-constraint description/ transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint login-config auth-methodFORM/auth-method realm-nameForm-Based Authentication Area/realm-name form-login-config form-login-page/jsp/security/protected/login.jsp/form-login-page form-error-page/jsp/security/protected/error.jsp/form-error-page /form-login-config /login-config security-role description/ role-nameADMIN/role-name /security-role All that newjsp.jsp in the welcome list contains is 'Hello World'. But running it in several browsers, all I get is a warning about redirection. Other applications of mine using a single log in page are fine. I can't see where this one is wrong. -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: 05 Oct 2011 18 39 To: Tomcat Users List Subject: Re: Using multiple login pages -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin, On 10/5/2011 11:41 AM, Martin O'Shea wrote: This follows on from yesterday's discussion about whether in my application, I can have more than one page with an embedded login form or not. I've been looking over the servlet spec (V2.2) and it seems that I can't actually do this which is a shame. Do what, have different login pages for different types of resources you're trying to reach? Sure you can: try reading my responses. So I'm now looking at a more conventional log in from a login page. But can anyone explain to me why I don’t see my login page when I run the application? Login.jsp contains the following: This isn't relevant if you're not seeing it. Which corresponds to the following in web.xml: welcome-file-list welcome-file/jsp/about/concept.jsp/welcome-file /welcome-file-list security-constraint web-resource-collection url-pattern/aboutConcept/url-pattern /web-resource-collection auth-constraint description/ role-nameADMIN/role-name /auth-constraint /security-constraint login-config form-login-config form-login-page/jsp/security/protected/login.jsp/form-login-page form-error-page/jsp/security/protected/error.jsp/form-error-page /form-login-config /login-config But when I run the application, all I get is the html of the page specified in the welcome file list? Is that a question or a statement? But if I then invoke a link from the welcome file, I get the login page. Surely it should be the other way around? Your welcome file is not protected in any way, so you are not challenged for credentials. If you want to login to see every page on your site, you should have url-pattern/*/url-pattern in your web-resource-collection. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6MlkYACgkQ9CaO5/Lv0PB3nQCfRf0g/erXaD2kOPyaBCMJW/h0 Ce0An0EbOElkSImGQYK8y+JkZdtcrIqL =wbh5 -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: Using multiple login pages
I have it now. There was a redirection going on in a method called from a scriptlet in the login page. It now seems to be OK. Thanks Chris. But one thing bugs me still: you said that you can have 'different login pages for different types of resources you're trying to reach.' Can you give any pointers about this? .-Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: 05 Oct 2011 18 39 To: Tomcat Users List Subject: Re: Using multiple login pages -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin, On 10/5/2011 11:41 AM, Martin O'Shea wrote: This follows on from yesterday's discussion about whether in my application, I can have more than one page with an embedded login form or not. I've been looking over the servlet spec (V2.2) and it seems that I can't actually do this which is a shame. Do what, have different login pages for different types of resources you're trying to reach? Sure you can: try reading my responses. So I'm now looking at a more conventional log in from a login page. But can anyone explain to me why I don’t see my login page when I run the application? Login.jsp contains the following: This isn't relevant if you're not seeing it. Which corresponds to the following in web.xml: welcome-file-list welcome-file/jsp/about/concept.jsp/welcome-file /welcome-file-list security-constraint web-resource-collection url-pattern/aboutConcept/url-pattern /web-resource-collection auth-constraint description/ role-nameADMIN/role-name /auth-constraint /security-constraint login-config form-login-config form-login-page/jsp/security/protected/login.jsp/form-login-page form-error-page/jsp/security/protected/error.jsp/form-error-page /form-login-config /login-config But when I run the application, all I get is the html of the page specified in the welcome file list? Is that a question or a statement? But if I then invoke a link from the welcome file, I get the login page. Surely it should be the other way around? Your welcome file is not protected in any way, so you are not challenged for credentials. If you want to login to see every page on your site, you should have url-pattern/*/url-pattern in your web-resource-collection. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6MlkYACgkQ9CaO5/Lv0PB3nQCfRf0g/erXaD2kOPyaBCMJW/h0 Ce0An0EbOElkSImGQYK8y+JkZdtcrIqL =wbh5 -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: problem with session replication in tomcat 5.5.23
- Original Message -
From: Gabriele Faelli gabriele.fae...@gmail.com
To: users@tomcat.apache.org
Cc:
Sent: Wednesday, October 5, 2011 1:17 AM
Subject: Re: problem with session replication in tomcat 5.5.23
Really any idea?
Il giorno 04/ott/2011 19:13, Gabriele Faelli
gabriele.fae...@gmail.com
ha scritto:
Hi all,
I'm running tomcat 5.5.23 on two RHEL 5.6.
I'm having big trouble making the session replication working across
these
two nodes.
I configured a cluster and it looks like working: each node discovers the
other one, I can see in the logs every received and transmitted ping.
Well, when I create a session in the logs there are no mention of sessions
being replicated and/or errors encounter while trying.
The applications running on tomcat have the distributable/ entry in
their
web.xml and this is the cluster config part of the server.xml:
Cluster
className=org.apache.catalina.cluster.tcp.SimpleTcpCluster
defaultMode=true
managerClassName=org.apache.catalina.cluster.session.DeltaManager
manager.expireSessionsOnShutdown=false
manager.useDirtyFlag=false
manager.notifyListenersOnReplication=true
manager.notifySessionListenersOnReplication=true
manager.sendAllSessions=true
Membership
className=org.apache.catalina.cluster.mcast.McastService
mcastAddr=228.0.0.4
mcastPort=45564
mcastFrequency=500
mcastDropTime=3000/
Receiver
className=org.apache.catalina.cluster.tcp.ReplicationListener
tcpListenAddress=192.168.199.101
tcpListenPort=4001
tcpSelectorTimeout=100
tcpThreadCount=6/
Sender
className=org.apache.catalina.cluster.tcp.ReplicationTransmitter
replicationMode=synchronous
ackTimeout=15000
waitForAck=true
autoConnect=true/
Valve
className=org.apache.catalina.cluster.tcp.ReplicationValve
filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/
Deployer
className=org.apache.catalina.cluster.deploy.FarmWarDeployer
tempDir=/tmp/war-temp/
deployDir=/tmp/war-deploy/
watchDir=/tmp/war-listen/
watchEnabled=false/
ClusterListener
className=org.apache.catalina.cluster.session.ClusterSessionListener/
/Cluster
Any Idea? Where I'm wrong? I did something stupid for sure :)
I tried every configuration, suggest... well everything I found on the
official an unofficial documentation... I'm quite frustated :P
Thanks in advance
G.
I'm by no means a clustering expert, and I've only run a 5.5.x (5.5.33) cluster
on my local machine (Fedora 15). I was going to work on improving the
documentation (and my understanding), but since EOL for the 5.5.x series is
less than one year out that's fallen lower on my things to do list.
A few things to check:
1. Make sure all your session objects implement java.io.Serializable
2. You have distributable/ as the first line after webapp in your web.xml
file
3. Apparently (from the Tomcat documentation) when you override any of the
defaults you
have to specify everything.
This has tripped me up in the past. I noticed for example that your
configuration appears to be missing a ClusterListener. Try adding the following
line to your cluster configuration after your other ClusterListener.
ClusterListener
className=org.apache.catalina.cluster.session.JvmRouteSessionIDBinderListener
/
4. Make sure that each Tomcat has a unique jvmRoute attribute on the Engine
element
5. Make sure your firewall is not blocking new connections on your tcpListenPort
6. Make sure that you're set up for multicasting on the proper interface (which
it
sounds like you do)
So ifconfig interface-name should show in part: UP BROADCAST RUNNING MULTICAST
So ip route list should show something like: multicast 224.0.0.0/4 dev eth0
scope link
7. Run something like Wireshark or tcpdump and watch for traffic on the
tcpListenPort
Items 3 and 4 are for load balancing with AJP (think mod_ajp and Apache HTTPD),
so I don't know if it's necessary.
I'm not sure how the FarmDeployer works. I have mine set up so it functions,
but there doesn't seem to be any documentation. The javadoc doesn't seem to be
internally consistent (I know, patches welcome). I've set my FarmDeployer up as
follows:
Admin (or source) node:
Deployer className=org.apache.catalina.cluster.deploy.FarmWarDeployer
tempDir=${catalina.base}/temp-dir/
deployDir=${catalina.base}/webapps/
watchDir=${catalina.base}/watch-dir/
watchEnabled=true/
All other (client) nodes:
Deployer className=org.apache.catalina.cluster.deploy.FarmWarDeployer
tempDir=${catalina.base}/temp-dir/
deployDir=${catalina.base}/webapps/
watchDir=${catalina.base}/watch-dir/
watchEnabled=false/
This seems to work (auto-deploy, etc.), except that when I restart the cluster
all of the applications in watchDir are deleted from deployDir and then
redeployed.
Finally, you can get some more logging information by modifying
Re: WebApps sharing uploaded files
Hello. Ok. I found what I was doing wrong and corrected my mistake: added /w1 at the beginning of the href attribute value. See below: 2.C) test_download.html html head titleTest download/title /head body /w1/attachments/foo.txt Foo.txt /body /html Now it works! Best regards, -- Léa -- View this message in context: http://old.nabble.com/WebApps-sharing-uploaded-files-tp32570911p32596193.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: WebApps sharing uploaded files
Hello. Ok. I found what I was doing wrong and corrected my mistake: added /w1 at the beginning of the href attribute value. See below: 2.C) test_download.html html head titleTest download/title /head body /w1/attachments/foo.txt Foo.txt /body /html Now it works! Best regards, -- Léa -- View this message in context: http://old.nabble.com/WebApps-sharing-uploaded-files-tp32570911p32596195.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: WebApps sharing uploaded files
Hello. Ok. I found what I was doing wrong and corrected my mistake: added /w1 at the beginning of the href attribute value. See below: 2.C) test_download.html html head titleTest download/title /head body /w1/attachments/foo.txt Foo.txt /body /html Now it works! Best regards, -- Léa -- View this message in context: http://old.nabble.com/WebApps-sharing-uploaded-files-tp32570911p32596196.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using multiple login pages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin, On 10/5/2011 1:59 PM, Martin O'Shea wrote: I have it now. There was a redirection going on in a method called from a scriptlet in the login page. It now seems to be OK. Glad you got it going. But one thing bugs me still: you said that you can have 'different login pages for different types of resources you're trying to reach.' Can you give any pointers about this? A page is defined as whatever the server responds when you request a resource. The form-login-page you configure in your web.xml can be dynamic: you can do whatever you want in that page. It doesn't have to be a static form that always looks the same. You can include/forward/etc from that page. It doesn't even have to be a JSP. You can configure the login-form-page to be a servlet that makes decisions and forwards to some other .jsp file. Use your imagination. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6MxyEACgkQ9CaO5/Lv0PByHACfZL9ykx3wPGApX1yyzjxYwkQR Rf4AoJG5DnnBtbIFYzZsKSLzPJOjJq2j =A5GW -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Using multiple login pages
Thanks for this Chris. It is food for thought.
I was under the impression that form-login-page was static, because that's
how I seen it used in apps I've worked on.
But I am curious to try a filter as well, something like this mapped to the
login:
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws java.io.IOException, ServletException {
HttpServletRequest req = (HttpServletRequest)request;
HttpServletResponse res = (HttpServletResponse)response;
// pre login action
// get username
String username = req.getParameter(j_username);
// if user is in revoked list send error
if ( revokeList.contains(username) ) {
res.sendError(javax.servlet.http.HttpServletResponse.SC_UNAUTHORIZED);
return;
}
// call next filter in the chain : let j_security_check authenticate
// user
chain.doFilter(request, response);
// post login action
}
I wouldn't mind seeing a servlet specified as form-login-page if you know of
an example.
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: 05 Oct 2011 22 08
To: Tomcat Users List
Subject: Re: Using multiple login pages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin,
On 10/5/2011 1:59 PM, Martin O'Shea wrote:
I have it now. There was a redirection going on in a method called
from a scriptlet in the login page. It now seems to be OK.
Glad you got it going.
But one thing bugs me still: you said that you can have 'different
login pages for different types of resources you're trying to
reach.' Can you give any pointers about this?
A page is defined as whatever the server responds when you request a
resource. The form-login-page you configure in your web.xml can be
dynamic: you can do whatever you want in that page. It doesn't have to
be a static form that always looks the same. You can
include/forward/etc from that page. It doesn't even have to be a JSP.
You can configure the login-form-page to be a servlet that makes
decisions and forwards to some other .jsp file.
Use your imagination.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6MxyEACgkQ9CaO5/Lv0PByHACfZL9ykx3wPGApX1yyzjxYwkQR
Rf4AoJG5DnnBtbIFYzZsKSLzPJOjJq2j
=A5GW
-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: Denying IPs using the Valve command in context.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 10/5/2011 10:28 AM, Mark H. Wood wrote: Having said that, I think that an anchored partial match (lookingAt()) really is the least-bad fit to the address problem, since we're usually more concerned about the first, second, and perhaps third quads of an IP address and the trailing part is considered insignificant. Again, I'm guessing that this just isn't going to change, no matter how good the arguments are, unless there is some new syntax that differentiates the old behavior from the new (such as adding prefix and postfix / like /\.0\./ if you want to match anything that has a 0 as either of the middle two octets of an IPv4 address). As I posted previously, though, it's still pretty bad: how would you match a /27? This valve can't do that, anyway. If you want /27, you have to list them all out. Note that there is a patch currently under development to handle CIDR masks such as this one: https://issues.apache.org/bugzilla/show_bug.cgi?id=51953 Domain matches, OTOH, might take matches() as least-bad of the regex types, since the prefix tends to be the don't-care part. I see these as mirror-images of one-another: the implementation fails in both cases by requiring you to add .* to either the beginning or the end of your regular expression. No matter what else happens, it's worth pointing-out in the documentation what's really going on, here. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6M1PEACgkQ9CaO5/Lv0PB0HQCfYpd59y18bJilfBPasp2MRyDl Np0An1NWgVCHEfOWnhz4+PLMiBtTkhne =adNX -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Denying IPs using the Valve command in context.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 10/5/2011 9:57 AM, Mark H. Wood wrote: Part of the problem with this valve is that regex matching is such a (IMHO) bizarre choice for IP address matching. IP addresses have a structure which is very unlike text, and the customary and expected matches take a bit of finagling to do in regexes. This was done somewhat recently (can't find the enhancement request at the moment) so that partial IP address matches could be done. It's done at the RequestFilterValve level which allows any of the subclasses to use regular expressions to match pretty much any allow/deny request property. Take a look a the code to see the level of reuse it provides. While it may not exactly be the smartest choice for IP addresses specifically, you don't have to use it for IP addresses :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6M1i0ACgkQ9CaO5/Lv0PAnuwCfZNhDWns5QDu5Lee+txGP0uU+ iP0An3wBwYz3+DEp7YrfDt1lJM0WfISb =HZFI -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using multiple login pages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin, On 10/5/2011 6:06 PM, Martin O'Shea wrote: Thanks for this Chris. It is food for thought. I was under the impression that form-login-page was static, because that's how I seen it used in apps I've worked on. But I am curious to try a filter as well, something like this mapped to the login: That's not going to work: the authentication stuff happens before your Filter can get it's hands on the request. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6M1nQACgkQ9CaO5/Lv0PAbvQCgsXcZD/J1FWCKl/LzuQOCEXr0 0qgAoJgNHrsZoD03AvFcDw0J6Euqaz3s =py59 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Using multiple login pages
That's a shame. It looked promising. I wouldn't mind seeing a servlet specified as form-login-page if you know of an example. -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: 05 Oct 2011 23 13 To: Tomcat Users List Subject: Re: Using multiple login pages -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin, On 10/5/2011 6:06 PM, Martin O'Shea wrote: Thanks for this Chris. It is food for thought. I was under the impression that form-login-page was static, because that's how I seen it used in apps I've worked on. But I am curious to try a filter as well, something like this mapped to the login: That's not going to work: the authentication stuff happens before your Filter can get it's hands on the request. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6M1nQACgkQ9CaO5/Lv0PAbvQCgsXcZD/J1FWCKl/LzuQOCEXr0 0qgAoJgNHrsZoD03AvFcDw0J6Euqaz3s =py59 -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: Using multiple login pages
From: Martin O'Shea [mailto:app...@dsl.pipex.com] Subject: RE: Using multiple login pages I wouldn't mind seeing a servlet specified as form-login-page if you know of an example. Simply set the url-pattern of some servlet-mapping to that of the login page. - 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.
RE: Using multiple login pages
From: Martin O'Shea [mailto:app...@dsl.pipex.com] Subject: RE: Using multiple login pages Do you mean the login page as specified in web.xml's login-config as below: If you're already using a .jsp for the login, you have all the dynamic content capability you need. If instead you want the login to be handled by a servlet, just make the form-login-page setting target a previously defined url-pattern for some appropriate servlet of the webapp. - 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.
RE: Using multiple login pages
From: Caldarale, Charles R Subject: RE: Using multiple login pages If you're already using a .jsp for the login, you have all the dynamic content capability you need. If instead you want the login to be handled by a servlet, just make the form-login-page setting target a previously defined url-pattern for some appropriate servlet of the webapp. In the interest of full disclosure, I have to say that I haven't actually tried doing that... - 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.
RE: Using multiple login pages
If I understand you correctly, I think I should have this: login-config auth-methodFORM/auth-method realm-nameForm-Based Authentication Area/realm-name form-login-config form-login-page/login/form-login-page form-error-page/jsp/security/protected/error.jsp/form-error-page /form-login-config /login-config But when called I receive a page not found exception. /login maps to a servlet I've been using to test my own logging in outside of j_security_check Should the servlet mapped to /login receive j_username and j_password? -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: 05 Oct 2011 23 41 To: Tomcat Users List Subject: RE: Using multiple login pages From: Caldarale, Charles R Subject: RE: Using multiple login pages If you're already using a .jsp for the login, you have all the dynamic content capability you need. If instead you want the login to be handled by a servlet, just make the form-login-page setting target a previously defined url-pattern for some appropriate servlet of the webapp. In the interest of full disclosure, I have to say that I haven't actually tried doing that... - 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: Using multiple login pages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin, On 10/5/2011 6:50 PM, Martin O'Shea wrote: If I understand you correctly, I think I should have this: login-config auth-methodFORM/auth-method realm-nameForm-Based Authentication Area/realm-name form-login-config form-login-page/login/form-login-page form-error-page/jsp/security/protected/error.jsp/form-error-page /form-login-config /login-config But when called I receive a page not found exception. /login maps to a servlet I've been using to test my own logging in outside of j_security_check It's important to understand that the form-login-page is the resource returned when the user tries to access a protected resource but is not yet authenticated. The form-login-page does *not* perform any authentication itself. It merely requests credentials from the user (i.e. it contains a form with j_username and j_password fields). Should the servlet mapped to /login receive j_username and j_password? No. It should produce a page which contains a login form. Tomcat will handle the actual processing of j_username/j_password for you, and then send the user onto the originally-requested page. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6M+fwACgkQ9CaO5/Lv0PCf7QCgiEzUtizqst/nDb0F9qrLeeb8 sbAAn0R85xOID9LtrPCSwIk54uZgssT3 =ssS3 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
