Re: Nginx as a proxy...
On 20.05.2015 08:27, Mark Thomas wrote: On 19/05/2015 22:25, Bjørn T Johansen wrote: I have a small problem using nginx as a reverse proxy in front of Tomcat 8.. The problem is that sometimes the context url is set to the local ip address of the tomcat server instead of the hostname used to access the nginx server. And I know this can be solved by using proxyname and proxypost but as far as I can see, this can only be configured for the connector port, which make the setting global? Add I run 5 other web applications in the same Tomcat instance so changing this globally is not an option... Anyway to solve this? option 1. Configure nginx to set the host header as you wish option 2. Remote IP Host/Valve (still requires nginx config) Mark Thx, was missing the HOST header... And now the url is almost correct... The remaining problem, is that the url looses the scheme used, so it gets redirected to http address instead of https; is that configured in the Tomcat config somewhere or? BTJ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Nginx as a proxy...
On 19/05/2015 22:25, Bjørn T Johansen wrote: I have a small problem using nginx as a reverse proxy in front of Tomcat 8.. The problem is that sometimes the context url is set to the local ip address of the tomcat server instead of the hostname used to access the nginx server. And I know this can be solved by using proxyname and proxypost but as far as I can see, this can only be configured for the connector port, which make the setting global? Add I run 5 other web applications in the same Tomcat instance so changing this globally is not an option... Anyway to solve this? option 1. Configure nginx to set the host header as you wish option 2. Remote IP Host/Valve (still requires nginx config) Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: what are directories created
On 20/05/2015 04:40, Dave H wrote: I have lucee (coldfusion) and tomcat7 setup on a windows server 2008r2. I have a wildcard DNS pointing to the server so any subdomain will forward to main site. for example bob.mydomain.com will forward to mydomain.com via the wildcard DNS entry. My question is when I go to the site in this example dave.mydomain.com or steve.mydomain.com tomcat takes about 10 seconds to load the page and it also creates a folder in c:\lucess\tomcat\conf\catalina\dave.mydomain.com that has root.xml Why does it need to create these directories? And why does it take so long to load? Those are good questions but ones you need to ask the coldfusion folks as Tomcat won't do this by default (or even with config). It looks like every time a new host name is seen a new default host with a default web application is created. That raises a number of DoS questions (time taken for these requests to process, disk space usage, etc). Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Nginx as a proxy...
On 20.05.2015 09:46, Mark Thomas wrote: On 20/05/2015 07:56, Bjørn T Johansen wrote: On 20.05.2015 08:27, Mark Thomas wrote: On 19/05/2015 22:25, Bjørn T Johansen wrote: I have a small problem using nginx as a reverse proxy in front of Tomcat 8.. The problem is that sometimes the context url is set to the local ip address of the tomcat server instead of the hostname used to access the nginx server. And I know this can be solved by using proxyname and proxypost but as far as I can see, this can only be configured for the connector port, which make the setting global? Add I run 5 other web applications in the same Tomcat instance so changing this globally is not an option... Anyway to solve this? option 1. Configure nginx to set the host header as you wish option 2. Remote IP Host/Valve (still requires nginx config) Mark Thx, was missing the HOST header... And now the url is almost correct... The remaining problem, is that the url looses the scheme used, so it gets redirected to http address instead of https; is that configured in the Tomcat config somewhere or? Set the scheme on the connector. If nginx is receiving both http and https traffic then the simplest way is to have two connectors in Tomcat, one with scheme=http and one with scheme=https (and secure=true). Note that scheme, secure and sslEnabled may all be set independently to handle the various permutations of reverse proxy config. Mark Yes, just thought of having a second connector for ssl, thx for confirming it... :) BTJ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re:Re: how to block the duplicated requests?
More detail information as below: presudo-code step: 1. a register page named http://mywebsite.com/register1.jsp; is set up, and this page contains a CAPTCHA image 2. the robot(crackers) could successfully register the thousands different users for this web site during only several minutes. 3. if it is a human beings, these thousands different users should have different IPs. But we find these thousands different users are from same IPs. By the way, we get the IP from HttpServletRequest header. 4. later, we setup a new register page. We change its url from http://mywebsite.com/register1.jsp; to http://mywebsite.com/register2.jsp; For the first several days, we find everthing is good. But after several days, we find the robot(crackers) find this new URL and could successfully register the thousands different users for this web site during only several minutes. It's just reproduced steps for our issue. Our requirements are that: 1. we have a URL for register page. we don't want the thousands different users with same IP could successfully registered during a very short time window. 2. We can have a policy to set an interval time window. Based on this interval time window, the same IP should NOT register users again and again. 3. This policy should manage a group of URLs. We can always add the different URLs for this policy. Because based on our maintaining activities, we may set up many different register page again and again. Is it a DDOS attack? Is there a good way to resolve it at httpd level? At 2015-05-19 21:16:29, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 To whom it may concern, On 5/19/15 8:09 AM, javalishixml wrote: Just understood you. Really appreciate for your feedback. How do we judge it's a robot? item1: we find the request IP is always the same one. item2: our page may contains several keep-alive connections. But the attack connection only focus on connection. Based upon the first request, how can you tell that the robot is going to make later keep-alive requests? Based on these 2 items, we think the client is a robot. Can you write some pseudo-code that shows the algorithm in its simplest form? I think maybe putting these 2 items together to consider it as a robot is a bit complex. Let's do it from the simple point. If we always find there is a same IP request our website the same url for many times, can I block this request at httpd level? This sounds like a job for mod_qos, mod_evasive, or mod_security. - -chris At 2015-05-19 20:01:00, David kerber dcker...@verizon.net wrote: On 5/19/2015 7:53 AM, javalishixml wrote: I doubt you're going to be able to do this in httpd, unless you have a very simple, straight forward way of identifying the robots. Yes. I just want to have a way to block the duplicated requests at httpd level. After all, my website has to face the the big concurrency issue. I understand that's what you want. What we're telling you is that you probably won't be able to do that. Let me ask the question again, that Chris asked before: how do you tell that a given request is from a robot? The answer to that question will determine if you can block it with httpd. At 2015-05-19 19:35:26, David kerber dcker...@verizon.net wrote: On 5/19/2015 1:03 AM, javalishixml wrote: Thanks a lot for your information. This solution is based on tomcat level. If I always handle this issue at java level, I'm afraid it has performance issue. Because this web site afford a very big concurrency access. Taking a consideration on its basic architect tomcat+apache, I think the best way to move this solution from tomcat to apache. So do you have some good solution at apache's configuration? I understand this is a mail list for tomcat.. but just want to get any information I doubt you're going to be able to do this in httpd, unless you have a very simple, straight forward way of identifying the robots. Thanks, At 2015-05-19 04:00:28, Christopher Schultz ch...@christopherschultz.net wrote: To whom it may concern, On 5/18/15 11:44 AM, javalishixml wrote: I have a website. It is built by apache + tomcat. Now we make a lottery activity at this website. But we find that some robots always raise the duplicated requests to hit this lottery activity. It causes that robots almost get all the awards. So we just want to block these kind of duplicated requests at every interval unit. For example, we set the interval unit is 3 seconds. The if the robot want to hit the lottery activity in 3 seconds, the website could block this action. So how to do it? I suppose if we do it at tomcat level, is it a very low performance? Can I do it at apache level? how to do it? If I could not do it apache level, can I do it by setting sth at tomcat? If you have a way to identify a duplicate request (e.g. using a
Re: Nginx as a proxy...
On 20/05/2015 07:56, Bjørn T Johansen wrote: On 20.05.2015 08:27, Mark Thomas wrote: On 19/05/2015 22:25, Bjørn T Johansen wrote: I have a small problem using nginx as a reverse proxy in front of Tomcat 8.. The problem is that sometimes the context url is set to the local ip address of the tomcat server instead of the hostname used to access the nginx server. And I know this can be solved by using proxyname and proxypost but as far as I can see, this can only be configured for the connector port, which make the setting global? Add I run 5 other web applications in the same Tomcat instance so changing this globally is not an option... Anyway to solve this? option 1. Configure nginx to set the host header as you wish option 2. Remote IP Host/Valve (still requires nginx config) Mark Thx, was missing the HOST header... And now the url is almost correct... The remaining problem, is that the url looses the scheme used, so it gets redirected to http address instead of https; is that configured in the Tomcat config somewhere or? Set the scheme on the connector. If nginx is receiving both http and https traffic then the simplest way is to have two connectors in Tomcat, one with scheme=http and one with scheme=https (and secure=true). Note that scheme, secure and sslEnabled may all be set independently to handle the various permutations of reverse proxy config. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Re: how to block the duplicated requests?
Hi What you explaining now and what you explained before are completely different story. Simple and main cause for your issue is inefficiency and poor design. why don't you simply count number of users registering on particular ip and stop at threshold for certain amount of time. A simple request filter servlet would do the job. And maybe you might want to change the CAPTCHA, to a not_so_obvious_to_figure_out kind With regards Prabhu -Original Message- From: javalishixml [mailto:javalishi...@163.com] Sent: Wednesday, 20 May, 2015 4:22 PM To: Tomcat Users List Subject: Re:Re: how to block the duplicated requests? More detail information as below: presudo-code step: 1. a register page named http://mywebsite.com/register1.jsp; is set up, and this page contains a CAPTCHA image 2. the robot(crackers) could successfully register the thousands different users for this web site during only several minutes. 3. if it is a human beings, these thousands different users should have different IPs. But we find these thousands different users are from same IPs. By the way, we get the IP from HttpServletRequest header. 4. later, we setup a new register page. We change its url from http://mywebsite.com/register1.jsp; to http://mywebsite.com/register2.jsp; For the first several days, we find everthing is good. But after several days, we find the robot(crackers) find this new URL and could successfully register the thousands different users for this web site during only several minutes. It's just reproduced steps for our issue. Our requirements are that: 1. we have a URL for register page. we don't want the thousands different users with same IP could successfully registered during a very short time window. 2. We can have a policy to set an interval time window. Based on this interval time window, the same IP should NOT register users again and again. 3. This policy should manage a group of URLs. We can always add the different URLs for this policy. Because based on our maintaining activities, we may set up many different register page again and again. Is it a DDOS attack? Is there a good way to resolve it at httpd level? At 2015-05-19 21:16:29, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 To whom it may concern, On 5/19/15 8:09 AM, javalishixml wrote: Just understood you. Really appreciate for your feedback. How do we judge it's a robot? item1: we find the request IP is always the same one. item2: our page may contains several keep-alive connections. But the attack connection only focus on connection. Based upon the first request, how can you tell that the robot is going to make later keep-alive requests? Based on these 2 items, we think the client is a robot. Can you write some pseudo-code that shows the algorithm in its simplest form? I think maybe putting these 2 items together to consider it as a robot is a bit complex. Let's do it from the simple point. If we always find there is a same IP request our website the same url for many times, can I block this request at httpd level? This sounds like a job for mod_qos, mod_evasive, or mod_security. - -chris At 2015-05-19 20:01:00, David kerber dcker...@verizon.net wrote: On 5/19/2015 7:53 AM, javalishixml wrote: I doubt you're going to be able to do this in httpd, unless you have a very simple, straight forward way of identifying the robots. Yes. I just want to have a way to block the duplicated requests at httpd level. After all, my website has to face the the big concurrency issue. I understand that's what you want. What we're telling you is that you probably won't be able to do that. Let me ask the question again, that Chris asked before: how do you tell that a given request is from a robot? The answer to that question will determine if you can block it with httpd. At 2015-05-19 19:35:26, David kerber dcker...@verizon.net wrote: On 5/19/2015 1:03 AM, javalishixml wrote: Thanks a lot for your information. This solution is based on tomcat level. If I always handle this issue at java level, I'm afraid it has performance issue. Because this web site afford a very big concurrency access. Taking a consideration on its basic architect tomcat+apache, I think the best way to move this solution from tomcat to apache. So do you have some good solution at apache's configuration? I understand this is a mail list for tomcat.. but just want to get any information I doubt you're going to be able to do this in httpd, unless you have a very simple, straight forward way of identifying the robots. Thanks, At 2015-05-19 04:00:28, Christopher Schultz ch...@christopherschultz.net wrote: To whom it may concern, On 5/18/15 11:44 AM, javalishixml wrote: I have a website. It is built by apache + tomcat. Now we make a lottery activity at this website. But we find that some robots always
RE: Problem with APR library - Tomcat 7
Chris, I have tried the commands you wrote me for creating a keystore. When I access my application on ssl port, I get The connection was reset error. I have used this command: openssl pkcs12 -export -in server.pem -inkey server.key -certfile serverchain.pem -out server.p12 In serverchain.pem I have concatenation of my own CA certificate that signed this server.pem certificate for my server, and other 2 CA certificates that were given to me. (basically, one faculty CA, my subject project CA, and my own CA is actually my group CA certificate, by which I have signed my server.pem) After that I have used this command: keytool -importkeystore -srckeystore server.p12 -destkeystore serverkeystore.jks -srcstoretype pkcs12 Specified the new key store in the connector with its password, reboot, and The connection was reset error appears again. If in the first command I add the -chain in the end as you wrote me on your reply, I get this error: Error unable to get local issuer certificate getting chain. Why is this happening? Date: Tue, 19 May 2015 15:01:06 -0400 From: ch...@christopherschultz.net To: users@tomcat.apache.org Subject: Re: Problem with APR library - Tomcat 7 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dejan, On 5/19/15 2:17 PM, Dejan Stamenov wrote: Can you please explain me these two lines you have wrote: $ openssl pkcs12 -export -in ${HOSTNAME}.crt \ -inkey ${HOSTNAME}.key \ -certfile CA-intermediate.crt -out ${HOSTNAME}.p12 -chain Packages your server's certificate, key, and the CA's intermediate certificate into a single PKCS#12 keystore. OpenSSL can't write Java keystores, and Java's keytool cant read PEM files. So, we use a PKCS#12 keystore as an intermediary, which both tools can read. $ $JAVA_HOME/bin/keytool -importkeystore \ -srckeystore ${HOSTNAME}.p12 \ -destkeystore ${HOSTNAME}.jks \ -srcstoretype pkcs12 Converts a PKCS#12 keystore into a Java keystore. Basically, what I have is 3 .pem files. One is the certificate for my server, and the other two are the intermediate CA certificate and root CA. You shouldn't need the CA's root certificate since most browsers ship with those root certs as anchors. If you need to add the CA's root to your keystore, you can always add it like this: $ keytool -import -alias [Authority.CA] \ -trustcacerts \ -file [authority's CA cert] \ -keystore ${HOSTNAME}.jks So, I should run the pkcs12 for each of these 3 certificates? No, it does everything at once. Make sure you keep your PEM files in a safe place as a back-up. And if you can explain me in a word or two what is being created with them, it would be much appreciated as I am first time working with this. See above. If you want security done right, get someone who knows about X.509 certificates, etc. or do some reading to get yourself more familiar with these concepts. There really is no cookbook to just do SSL because it's complicated and, if you don't do it properly, increasingly risky lately. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVW4hyAAoJEBzwKT+lPKRYdVsP/2KG0pobgtXBEDS6WBK6OMV1 Sss/Xy2Ed3KCrtHceXL59FWoQBWysFRX/mVOPXnv4zAY7aurXOjI5oyHCRNZsOa/ 4PmqKy/HU4MaxCPBJczD0DfYi5HmuFdRTT9NHdXzM3/gPei29vyx7OE0Lr1/DYHT 5spnvkh9WwA30sfGBb07/zEA79OM17eVge/Ki/Bfd0WRBODd2iIfM9GfKxR9vpM4 vLE2P3zhGdCQT1aWxDIveZ+IL2QOdt7VwS2KWjc04snxjMh374EXvOtw7PWsD6Yg nlJxhrprRPhTiPDDuhOW4guV/o2jdLxYMBw/DX0gluCZ9qQLrUKC83cfdnE2+tuC PMaDBRT0UGzQx5Ok5iv1vNEBgAiwrWfK2MGrFAiiAJWGEjnANYc2GOQEdv7549gD 9nw6lgYbOOBztU326Hf6qeC/XDOBb/hDfc3E1xXkoXroWlUSteP3nmgkCDaoZY7B O005BAkQzZuhd7EFk3cWLBowSVt53O6xju5pOf6mdI8hPsIgWYB0ZxejS0cp0VvK +9pv5mkwUnmqQp5znkoBevBWRolzdOsHECXGotri2q3CoX1j+oCFmH+Nj+cpbRAF ob3/UuAMUfGXkb3TzILN2jnqX+JPmAXq5h7bEZTIu9PIy0x6BeGn1zkWiBSbfZcZ lg3He5P+ADNKCVHiMVBj =zaTm -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re:Re: how to block the duplicated requests?
Understood. Really appreciate for your nice time. Thanks, At 2015-05-20 21:00:33, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 5/20/15 4:22 AM, javalishixml wrote: More detail information as below: presudo-code step: This isn't pseudo-code. This is a re-statement of your problem. 1. a register page named http://mywebsite.com/register1.jsp; is set up, and this page contains a CAPTCHA image You didn't mention that CAPTCHA was already being used. Someone mentioned using it as a solution to your problem. What CAPTCHA are you using? Perhaps using a more effective one would help more than anything else. 2. the robot(crackers) could successfully register the thousands different users for this web site during only several minutes. 3. if it is a human beings, these thousands different users should have different IPs. But we find these thousands different users are from same IPs. No chance these are AOL users? Google for AOL ip address proxy. By the way, we get the IP from HttpServletRequest header. Where else would you get the remote IP address? 4. later, we setup a new register page. We change its url from http://mywebsite.com/register1.jsp; to http://mywebsite.com/register2.jsp; Are you trying to be evasive? Why have you moved your registration page? For the first several days, we find everything is good. But after several days, we find the robot(crackers) find this new URL and could successfully register the thousands different users for this web site during only several minutes. It's just reproduced steps for our issue. So, back to my original question: How are you going to identify a duplicate request? Show some pseudo-code. Our requirements are that: 1. we have a URL for register page. we don't want the thousands different users with same IP could successfully registered during a very short time window. What about users behind proxies? Are you okay shutting them out? See the AOL anecdote above. 2. We can have a policy to set an interval time window. Based on this interval time window, the same IP should NOT register users again and again. 3. This policy should manage a group of URLs. We can always add the different URLs for this policy. Because based on our maintaining activities, we may set up many different register page again and again. Is it a DDOS attack? Are they preventing anyone else from using your site? Or are they just raising their numbers quickly enough that statistically, they always overwhelm your legitimate users and win the lottery? Is there a good way to resolve it at httpd level? Seriously, look-up mod_qos, mod_evasive, and mod_security and stop asking for solutions. We've already given you a whole bunch of ideas that consultants would have already bankrupted you for. Go do some work. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVXIVxAAoJEBzwKT+lPKRY3AMQAIWrelhsrB9WnB8c+Wq7S2ia +L1dU+ZTI+VEeFBWy1ARUTtXM/viL7mE7QfofVVEjmMYAxrITrk9Nqn0DzmGBJAG JNcPkSHVAvhH9thOJDCfLvD69hV5sGCJdNC6RlYn235IEiai1IhH6ZQudrCXAPjl mMjZPX30W65MbA7fBMWG4NUJFi2BBz07zV8/teIwHQ/3w9fTs63o18alRwP5cGUk i1yu0lBf63xO5r7xnS5jN9fvklZe6FrCS+6RK2AAj2viF7mGi3kmaco1fdSQmTLY rdadMd0M9P6BgowMtBUAVNX4DnqJc2GIo8xlCySC/myvp8y3T9vwOvyRERoSW+8h a7oEPV6SKlFYKLHNg0XVgmkT3PHTjqojh2eOlKh8vO3W5YTw2R3xqXa4WUN0dHur cbD2RjSm7mA0Ewl+E2YsCbJAdfuPt3w77mIuv3FaV6ZPWdXLtSq0QARfGju0S11x bdEBaOzsQsm29qOC5MKMqG0tgHlY1Ya3BnGGxI+GTMat91d8kp92ufWeS5bmda3I BqOosM+GkgY9P1DATPXpR5A8Xi5Pp/lgkD4MYVNka2VH7FgKWckXlUhWoilDqFDX k4R9z/ZaRrDwqt6lwSAlRN4znwTw0OyP9FSLGr+VIKfKRUyweJss6pVUUGpxd3yQ ytK9Cbw2UpbOyFaiA1AE =CHtu -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Fwd:
Hello, I believe I am running tomcat 8.0 (although when I call the getServerInfo() method of the implicit ServletContext Object It tells me that I am running on 7.54) I configured my realm element in my context.xml file as follows (based on the howto guide: https://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html): Realm className=org.apache.catalina.realm.DataSourceRealm debug=99 dataSourceName=jdbc/board localDataSource=true userTable=test_user userNameCol=Email userCredCol=HashedPassword userRoleTable=test_user_role roleNameCol=Role CredentialHandler className=MessageDigestCredentialHandler algorithm=SHA-1 iterations=1000 saltLength=48/ /Realm However, despite the password being stored in the format described in your how to manual (ie:{salt}${iterations}${password}), authentication fails. I assume that this is because something in my Realm configuration is wrong. I was not able to find an answer on online help forums. I also couldn't find a way to call the initialized DataSourceRealm Object's digest method when inputting the HashedPassword (ie: I had to calculate salt and hash on my own using the SHA-1 algorithm). Perhaps this also has something to do with why authentication is failing? Thank you
Re: how to block the duplicated requests?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 5/20/15 4:22 AM, javalishixml wrote: More detail information as below: presudo-code step: This isn't pseudo-code. This is a re-statement of your problem. 1. a register page named http://mywebsite.com/register1.jsp; is set up, and this page contains a CAPTCHA image You didn't mention that CAPTCHA was already being used. Someone mentioned using it as a solution to your problem. What CAPTCHA are you using? Perhaps using a more effective one would help more than anything else. 2. the robot(crackers) could successfully register the thousands different users for this web site during only several minutes. 3. if it is a human beings, these thousands different users should have different IPs. But we find these thousands different users are from same IPs. No chance these are AOL users? Google for AOL ip address proxy. By the way, we get the IP from HttpServletRequest header. Where else would you get the remote IP address? 4. later, we setup a new register page. We change its url from http://mywebsite.com/register1.jsp; to http://mywebsite.com/register2.jsp; Are you trying to be evasive? Why have you moved your registration page? For the first several days, we find everything is good. But after several days, we find the robot(crackers) find this new URL and could successfully register the thousands different users for this web site during only several minutes. It's just reproduced steps for our issue. So, back to my original question: How are you going to identify a duplicate request? Show some pseudo-code. Our requirements are that: 1. we have a URL for register page. we don't want the thousands different users with same IP could successfully registered during a very short time window. What about users behind proxies? Are you okay shutting them out? See the AOL anecdote above. 2. We can have a policy to set an interval time window. Based on this interval time window, the same IP should NOT register users again and again. 3. This policy should manage a group of URLs. We can always add the different URLs for this policy. Because based on our maintaining activities, we may set up many different register page again and again. Is it a DDOS attack? Are they preventing anyone else from using your site? Or are they just raising their numbers quickly enough that statistically, they always overwhelm your legitimate users and win the lottery? Is there a good way to resolve it at httpd level? Seriously, look-up mod_qos, mod_evasive, and mod_security and stop asking for solutions. We've already given you a whole bunch of ideas that consultants would have already bankrupted you for. Go do some work. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVXIVxAAoJEBzwKT+lPKRY3AMQAIWrelhsrB9WnB8c+Wq7S2ia +L1dU+ZTI+VEeFBWy1ARUTtXM/viL7mE7QfofVVEjmMYAxrITrk9Nqn0DzmGBJAG JNcPkSHVAvhH9thOJDCfLvD69hV5sGCJdNC6RlYn235IEiai1IhH6ZQudrCXAPjl mMjZPX30W65MbA7fBMWG4NUJFi2BBz07zV8/teIwHQ/3w9fTs63o18alRwP5cGUk i1yu0lBf63xO5r7xnS5jN9fvklZe6FrCS+6RK2AAj2viF7mGi3kmaco1fdSQmTLY rdadMd0M9P6BgowMtBUAVNX4DnqJc2GIo8xlCySC/myvp8y3T9vwOvyRERoSW+8h a7oEPV6SKlFYKLHNg0XVgmkT3PHTjqojh2eOlKh8vO3W5YTw2R3xqXa4WUN0dHur cbD2RjSm7mA0Ewl+E2YsCbJAdfuPt3w77mIuv3FaV6ZPWdXLtSq0QARfGju0S11x bdEBaOzsQsm29qOC5MKMqG0tgHlY1Ya3BnGGxI+GTMat91d8kp92ufWeS5bmda3I BqOosM+GkgY9P1DATPXpR5A8Xi5Pp/lgkD4MYVNka2VH7FgKWckXlUhWoilDqFDX k4R9z/ZaRrDwqt6lwSAlRN4znwTw0OyP9FSLGr+VIKfKRUyweJss6pVUUGpxd3yQ ytK9Cbw2UpbOyFaiA1AE =CHtu -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Problrm with resources added using DirResourceSet
Server version: Apache Tomcat/8.0.14 Server built: Sep 24 2014 09:01:51 Server number: 8.0.14.0 OS Name:Linux OS Version: 3.8.0-29-generic Architecture: amd64 JVM Version:1.7.0_55-b14 JVM Vendor: Oracle Corporation I have implemented a custom WebappClassLoaderBase and StandardRoot, and it looks like it is working; but the resources added are not available to the web app. What follows is a bit long and I apologize for that, but didn't want to leave out potentially important information. Any ideas on what's wrong? This is the code snippet: wsRoot = IDWMPluginRegistry.getInstance().getWebRoot(); log.info(IDWMClassLoader init: + wsRoot.getContext().getName()); SetIDWMPlugin plugins = IDWMPluginRegistry.getInstance().getPlugins(); for(IDWMPlugin plugin: plugins) { log.info(Loading plugin: + plugin.getLoaderClassName()); try { if(wsRoot == null) { log.info(wsRoot not set.); wsRoot = new StandardRoot(); } if(wsRoot.getContext() == null) { throw new Exception(NO CONTEXT!!!); } File pFile = plugin.getRoot(); log.info(Adding plugin root + pFile.getAbsolutePath() + to the WebResourceRoot as a DirResourceSet.); DirResourceSet drs = new DirResourceSet(wsRoot, /, pFile.getAbsolutePath(), /); log.info(DirResourceSet base URL = + drs.getBaseUrl().toString()); wsRoot.addPostResources(drs); } catch(Exception e) { log.log(Level.SEVERE, Error setting up class path, e); } } And here is the catalina.out log pertaining to this section of code. 17-May-2015 23:27:52.399 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory /usr/local/apache-tomcat-8.0.14/webapps/ROOT 17-May-2015 23:27:53.243 INFO [localhost-startStop-1] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time. 17-May-2015 23:27:53.385 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory /usr/local/apache-tomcat-8.0.14/webapps/ROOT has finished in 986 ms 17-May-2015 23:27:53.388 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory /usr/local/apache-tomcat-8.0.14/webapps/idwm 17-May-2015 23:27:53.424 INFO [localhost-startStop-1] com.comsquared.idw.catalina.ext.IDWMFileDirContext.init Default Constructor. 17-May-2015 23:27:53.425 INFO [localhost-startStop-1] com.comsquared.idw.catalina.ext.IDWMFileDirContext.importPlugins System property idwm.plugins not set; using default plugin path /usr/us/idwm/plugins 17-May-2015 23:27:53.431 INFO [localhost-startStop-1] com.comsquared.idw.catalina.ext.IDWMFileDirContext.importFromDirectory Found plugin at /usr/us/idwm/plugins/idw-plugins-role_change_attribute_audit 17-May-2015 23:27:54.146 INFO [localhost-startStop-1] com.comsquared.idw.catalina.ext.IDWMClassLoader.init parent constructor.class java.net.URLClassLoader 17-May-2015 23:27:54.147 INFO [localhost-startStop-1] com.comsquared.idw.catalina.ext.IDWMClassLoader.init IDWMClassLoader init: /idwm 17-May-2015 23:27:54.148 INFO [localhost-startStop-1] com.comsquared.idw.catalina.ext.IDWMClassLoader.init Loading plugin: idwplugin.RoleChangeAttributeAudit.RoleChangeAttributeAuditPluginLoader 17-May-2015 23:27:54.148 INFO [localhost-startStop-1] com.comsquared.idw.catalina.ext.IDWMClassLoader.init Adding plugin root /usr/us/idwm/plugins/idw-plugins-role_change_attribute_audit to the WebResourceRoot as a DirResourceSet. 17-May-2015 23:27:54.148 INFO [localhost-startStop-1] com.comsquared.idw.catalina.ext.IDWMClassLoader.init DirResourceSet base URL = file:/usr/us/idwm/plugins/idw-plugins-role_change_attribute_audit/ 17-May-2015 23:28:05.198 INFO [localhost-startStop-1] com.comsquared.idwm.DataSourceFactory.getObjectInstance Get JNDI datasource ImageDirectorWorkflowDS from app config log4j:WARN No such property [maxBackupIndex] in org.apache.log4j.DailyRollingFileAppender. 17-May-2015 23:28:15.367 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory /usr/local/apache-tomcat-8.0.14/webapps/idwm has finished in 21,978 ms 17-May-2015 23:28:15.371 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory /usr/local/apache-tomcat-8.0.14/webapps/docs 17-May-2015 23:28:15.425 INFO [localhost-startStop-1] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this
APR Buffer NullPointer Error
Dear All I am deploying application (Tomcat 8.0.22, JDK 1.7.79, Solaris, SPARC, APR 1.5.2) and observing multiple erros while its communicates with client software (error presented below). It looks like that error happens while application writes output buffer. Any suggestion what is going wrong? Might it be resources limitation on OS level (was configured based on Oracle recommendations already). java.lang.NullPointerException at org.apache.coyote.http11.InternalAprOutputBuffer.addToBB(InternalAprOutputBuffer.java:186) ~[tomcat-coyote.jar:8.0.21] at org.apache.coyote.http11.InternalAprOutputBuffer.access$000(InternalAprOutputBuffer.java:40) ~[tomcat-coyote.jar:8.0.21] at org.apache.coyote.http11.InternalAprOutputBuffer$SocketOutputBuffer.doWrite(InternalAprOutputBuffer.java:349) ~[tomcat-coyote.jar: at org.apache.coyote.http11.filters.ChunkedOutputFilter.doWrite(ChunkedOutputFilter.java:116) ~[tomcat-coyote.jar:8.0.21] at org.apache.coyote.http11.AbstractOutputBuffer.doWrite(AbstractOutputBuffer.java:256) ~[tomcat-coyote.jar:8.0.21] at org.apache.coyote.Response.doWrite(Response.java:503) ~[tomcat-coyote.jar:8.0.21] at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:388) ~[catalina.jar:8.0.21] at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:426) ~[tomcat-util.jar:8.0.21] at org.apache.catalina.connector.OutputBuffer.realWriteChars(OutputBuffer.java:471) ~[catalina.jar:8.0.21] at org.apache.tomcat.util.buf.CharChunk.flushBuffer(CharChunk.java:393) ~[tomcat-util.jar:8.0.21] at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:339) ~[catalina.jar:8.0.21] at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:317) ~[catalina.jar:8.0.21] at org.apache.catalina.connector.CoyoteWriter.flush(CoyoteWriter.java:94) ~[catalina.jar:8.0.21] at se.highex.core.gw.GWSession.sendMsgs(GWSession.java:1568) ~[GWSession.class:?] at se.highex.core.gw.GWSession.takeNotifyQueue(GWSession.java:1668) ~[GWSession.class:?] BR, Maxim
Re: what are directories created
Hi Mark, Yes, this is exactly our concern. I was hopping there would be a setting or option we can configure to disable the creation of these folder / files. I will check with Lucee folks. -DaveH On 5/19/2015 11:28 PM, Mark Thomas wrote: On 20/05/2015 04:40, Dave H wrote: I have lucee (coldfusion) and tomcat7 setup on a windows server 2008r2. I have a wildcard DNS pointing to the server so any subdomain will forward to main site. for example bob.mydomain.com will forward to mydomain.com via the wildcard DNS entry. My question is when I go to the site in this example dave.mydomain.com or steve.mydomain.com tomcat takes about 10 seconds to load the page and it also creates a folder in c:\lucess\tomcat\conf\catalina\dave.mydomain.com that has root.xml Why does it need to create these directories? And why does it take so long to load? Those are good questions but ones you need to ask the coldfusion folks as Tomcat won't do this by default (or even with config). It looks like every time a new host name is seen a new default host with a default web application is created. That raises a number of DoS questions (time taken for these requests to process, disk space usage, etc). Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org __ Information from ESET NOD32 Antivirus, version of virus signature database 11654 (20150520) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: APR Buffer NullPointer Error
On 20/05/2015 18:02, Maxim Neshcheret wrote: Dear All I am deploying application (Tomcat 8.0.22, JDK 1.7.79, Solaris, SPARC, APR 1.5.2) and observing multiple erros while its communicates with client software (error presented below). It looks like that error happens while application writes output buffer. Any suggestion what is going wrong? Might it be resources limitation on OS level (was configured based on Oracle recommendations already). Application trying to write to a response object that has already been closed? Mark java.lang.NullPointerException at org.apache.coyote.http11.InternalAprOutputBuffer.addToBB(InternalAprOutputBuffer.java:186) ~[tomcat-coyote.jar:8.0.21] at org.apache.coyote.http11.InternalAprOutputBuffer.access$000(InternalAprOutputBuffer.java:40) ~[tomcat-coyote.jar:8.0.21] at org.apache.coyote.http11.InternalAprOutputBuffer$SocketOutputBuffer.doWrite(InternalAprOutputBuffer.java:349) ~[tomcat-coyote.jar: at org.apache.coyote.http11.filters.ChunkedOutputFilter.doWrite(ChunkedOutputFilter.java:116) ~[tomcat-coyote.jar:8.0.21] at org.apache.coyote.http11.AbstractOutputBuffer.doWrite(AbstractOutputBuffer.java:256) ~[tomcat-coyote.jar:8.0.21] at org.apache.coyote.Response.doWrite(Response.java:503) ~[tomcat-coyote.jar:8.0.21] at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:388) ~[catalina.jar:8.0.21] at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:426) ~[tomcat-util.jar:8.0.21] at org.apache.catalina.connector.OutputBuffer.realWriteChars(OutputBuffer.java:471) ~[catalina.jar:8.0.21] at org.apache.tomcat.util.buf.CharChunk.flushBuffer(CharChunk.java:393) ~[tomcat-util.jar:8.0.21] at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:339) ~[catalina.jar:8.0.21] at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:317) ~[catalina.jar:8.0.21] at org.apache.catalina.connector.CoyoteWriter.flush(CoyoteWriter.java:94) ~[catalina.jar:8.0.21] at se.highex.core.gw.GWSession.sendMsgs(GWSession.java:1568) ~[GWSession.class:?] at se.highex.core.gw.GWSession.takeNotifyQueue(GWSession.java:1668) ~[GWSession.class:?] BR, Maxim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problrm with resources added using DirResourceSet
On 20/05/2015 18:30, Ed Rouse wrote: Server version: Apache Tomcat/8.0.14 Server built: Sep 24 2014 09:01:51 Server number: 8.0.14.0 OS Name:Linux OS Version: 3.8.0-29-generic Architecture: amd64 JVM Version:1.7.0_55-b14 JVM Vendor: Oracle Corporation I have implemented a custom WebappClassLoaderBase and StandardRoot, and it looks like it is working; but the resources added are not available to the web app. What follows is a bit long and I apologize for that, but didn't want to leave out potentially important information. Any ideas on what's wrong? Thanks for all the info. I can't see anything obviously wrong in what you posted. I'd fire up a debugger and step through the StandardRoot.getResource() call and check: - You see the StandardRoot instance you expect to see - The DirResourceSet is present - Follow the code to see why the resource isn't looked up in your DirResourceSet HTH, Mark This is the code snippet: wsRoot = IDWMPluginRegistry.getInstance().getWebRoot(); log.info(IDWMClassLoader init: + wsRoot.getContext().getName()); SetIDWMPlugin plugins = IDWMPluginRegistry.getInstance().getPlugins(); for(IDWMPlugin plugin: plugins) { log.info(Loading plugin: + plugin.getLoaderClassName()); try { if(wsRoot == null) { log.info(wsRoot not set.); wsRoot = new StandardRoot(); } if(wsRoot.getContext() == null) { throw new Exception(NO CONTEXT!!!); } File pFile = plugin.getRoot(); log.info(Adding plugin root + pFile.getAbsolutePath() + to the WebResourceRoot as a DirResourceSet.); DirResourceSet drs = new DirResourceSet(wsRoot, /, pFile.getAbsolutePath(), /); log.info(DirResourceSet base URL = + drs.getBaseUrl().toString()); wsRoot.addPostResources(drs); } catch(Exception e) { log.log(Level.SEVERE, Error setting up class path, e); } } And here is the catalina.out log pertaining to this section of code. 17-May-2015 23:27:52.399 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory /usr/local/apache-tomcat-8.0.14/webapps/ROOT 17-May-2015 23:27:53.243 INFO [localhost-startStop-1] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time. 17-May-2015 23:27:53.385 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory /usr/local/apache-tomcat-8.0.14/webapps/ROOT has finished in 986 ms 17-May-2015 23:27:53.388 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory /usr/local/apache-tomcat-8.0.14/webapps/idwm 17-May-2015 23:27:53.424 INFO [localhost-startStop-1] com.comsquared.idw.catalina.ext.IDWMFileDirContext.init Default Constructor. 17-May-2015 23:27:53.425 INFO [localhost-startStop-1] com.comsquared.idw.catalina.ext.IDWMFileDirContext.importPlugins System property idwm.plugins not set; using default plugin path /usr/us/idwm/plugins 17-May-2015 23:27:53.431 INFO [localhost-startStop-1] com.comsquared.idw.catalina.ext.IDWMFileDirContext.importFromDirectory Found plugin at /usr/us/idwm/plugins/idw-plugins-role_change_attribute_audit 17-May-2015 23:27:54.146 INFO [localhost-startStop-1] com.comsquared.idw.catalina.ext.IDWMClassLoader.init parent constructor.class java.net.URLClassLoader 17-May-2015 23:27:54.147 INFO [localhost-startStop-1] com.comsquared.idw.catalina.ext.IDWMClassLoader.init IDWMClassLoader init: /idwm 17-May-2015 23:27:54.148 INFO [localhost-startStop-1] com.comsquared.idw.catalina.ext.IDWMClassLoader.init Loading plugin: idwplugin.RoleChangeAttributeAudit.RoleChangeAttributeAuditPluginLoader 17-May-2015 23:27:54.148 INFO [localhost-startStop-1] com.comsquared.idw.catalina.ext.IDWMClassLoader.init Adding plugin root /usr/us/idwm/plugins/idw-plugins-role_change_attribute_audit to the WebResourceRoot as a DirResourceSet. 17-May-2015 23:27:54.148 INFO [localhost-startStop-1] com.comsquared.idw.catalina.ext.IDWMClassLoader.init DirResourceSet base URL = file:/usr/us/idwm/plugins/idw-plugins-role_change_attribute_audit/ 17-May-2015 23:28:05.198 INFO [localhost-startStop-1] com.comsquared.idwm.DataSourceFactory.getObjectInstance Get JNDI datasource ImageDirectorWorkflowDS from app config log4j:WARN No such property [maxBackupIndex] in org.apache.log4j.DailyRollingFileAppender. 17-May-2015 23:28:15.367 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory
Re: Problrm with resources added using DirResourceSet
2015-05-20 20:30 GMT+03:00 Ed Rouse ero...@milner.com: Server version: Apache Tomcat/8.0.14 A bit old... Server built: Sep 24 2014 09:01:51 Server number: 8.0.14.0 OS Name:Linux OS Version: 3.8.0-29-generic Architecture: amd64 JVM Version:1.7.0_55-b14 JVM Vendor: Oracle Corporation I have implemented a custom WebappClassLoaderBase and StandardRoot, and it looks like it is working; but the resources added are not available to the web app. What follows is a bit long and I apologize for that, but didn't want to leave out potentially important information. Any ideas on what's wrong? At what point of Lifecycle is your code called? Has StandardRoot.initInternal() already happened? Has StandardRoot.startInternal() already happened? This is the code snippet: wsRoot = IDWMPluginRegistry.getInstance().getWebRoot(); log.info(IDWMClassLoader init: + wsRoot.getContext().getName()); SetIDWMPlugin plugins = IDWMPluginRegistry.getInstance().getPlugins(); for(IDWMPlugin plugin: plugins) { log.info(Loading plugin: + plugin.getLoaderClassName()); try { if(wsRoot == null) { log.info(wsRoot not set.); wsRoot = new StandardRoot(); The above code does not work. It will fail at if(wsRoot.getContext() == null) check on the next line... } if(wsRoot.getContext() == null) { throw new Exception(NO CONTEXT!!!); } File pFile = plugin.getRoot(); log.info(Adding plugin root + pFile.getAbsolutePath() + to the WebResourceRoot as a DirResourceSet.); DirResourceSet drs = new DirResourceSet(wsRoot, /, pFile.getAbsolutePath(), /); log.info(DirResourceSet base URL = + drs.getBaseUrl().toString()); wsRoot.addPostResources(drs); } catch(Exception e) { log.log(Level.SEVERE, Error setting up class path, e); } } And here is the catalina.out log pertaining to this section of code. (...) https://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: OpenSSL, Cipher-Suites, and Tomcat standalone vs. native vs. Tomcat behind apache-httpd
OS: Linux i386 2.6.18-404.el5 Java: Oracle Corporation Java HotSpot(TM) Server VM 1.8.0_45 Tomcat: Apache Tomcat/8.0.21 On Wed, May 20, 2015 at 7:12 PM, Glen Peterson g...@organicdesign.org wrote: I've been using Tomcat as a stand-alone web server for years. Last year, I started testing my site here: https://www.ssllabs.com/ssltest I notice that there are only 3 fully secure cipher-suites left (there were 6 left 2 months ago). Also, I only get an A, not an A+ due to TLS_FALLBACK_SCSV not supported. According to this: https://bz.apache.org/bugzilla/show_bug.cgi?id=57464 my issue is that I need openssl version 1.0.1j. I just downloaded and built my openssl 1.02 from the latest sources and installed it. As tomcat, (or root) I can now see the new version: openssl version OpenSSL 1.0.2a 19 Mar 2015 I stopped and started Tomcat, ran the ssllabs test, and got EXACTLY the same result I had with the old version of openssl. I think it must use some Java cryptography libraries instead. So the cipher-suites Tomcat supports are tied to the version of Java I have installed, not the version of OpenSSL (even though a lot of the configuration syntax is identical). I think that most people run apache-httpd and let it handle encryption, serving static files, and a whole bunch of other stuff, then they run Tomcat behind it, or within it, as a kind of plug-in, or extra. I've always avoided that because there are whole books about how to configure apache-httpd securely. It's one more thing to update, maintain, etc. Is it worth it? I'm aware of a tomcat native that uses it's own openssl version, but I've never tried it, nor do I know anyone who uses it. Of course, that's a new thing to learn, but presumably, it's tied to the regular Tomcat, so they don't have to be upgraded separately. Thoughts? -- Glen K. Peterson (828) 393-0081 -- Glen K. Peterson (828) 393-0081 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
OpenSSL, Cipher-Suites, and Tomcat standalone vs. native vs. Tomcat behind apache-httpd
I've been using Tomcat as a stand-alone web server for years. Last year, I started testing my site here: https://www.ssllabs.com/ssltest I notice that there are only 3 fully secure cipher-suites left (there were 6 left 2 months ago). Also, I only get an A, not an A+ due to TLS_FALLBACK_SCSV not supported. According to this: https://bz.apache.org/bugzilla/show_bug.cgi?id=57464 my issue is that I need openssl version 1.0.1j. I just downloaded and built my openssl 1.02 from the latest sources and installed it. As tomcat, (or root) I can now see the new version: openssl version OpenSSL 1.0.2a 19 Mar 2015 I stopped and started Tomcat, ran the ssllabs test, and got EXACTLY the same result I had with the old version of openssl. I think it must use some Java cryptography libraries instead. So the cipher-suites Tomcat supports are tied to the version of Java I have installed, not the version of OpenSSL (even though a lot of the configuration syntax is identical). I think that most people run apache-httpd and let it handle encryption, serving static files, and a whole bunch of other stuff, then they run Tomcat behind it, or within it, as a kind of plug-in, or extra. I've always avoided that because there are whole books about how to configure apache-httpd securely. It's one more thing to update, maintain, etc. Is it worth it? I'm aware of a tomcat native that uses it's own openssl version, but I've never tried it, nor do I know anyone who uses it. Of course, that's a new thing to learn, but presumably, it's tied to the regular Tomcat, so they don't have to be upgraded separately. Thoughts? -- Glen K. Peterson (828) 393-0081 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AJP config questions
Thanks for the guidance guys. I understand it better. See in-line comments: -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Friday, May 15, 2015 7:03 AM To: Tomcat Users List Subject: Re: AJP config questions -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey, On 5/14/15 6:38 PM, Jeffrey Janner wrote: (Hopefully, this isn't a duplicate post, but I sent the original a half-hour ago and I haven't seen it come back yet.) Guys, it's been a long time since I did any work with AJP, but it looks like something I'll be implementing soon. I have a couple of basic questions, mostly related to ProxyPassReverse, but also one related to SSL. I know to turn on mod_proxy and mod_proxy_ajp and a simple ProxyPass where the source and dest paths match, i.e. both are /foo. The question is if they differ. The httpd docs give this example: Rewriting Proxied Path ProxyPass /apps/foo ajp://backend.example.com:8009/foo ProxyPassReverse /apps/foo http://www.example.com/foo but don't mention if you need to turn on the RewriteEngine. Also, the second line doesn't look correct. Shouldn't it be http://www.example.com/app/foo? Or maybe ajp://backend.example.com:8009/foo? Trying to re-name the context path during proxying is a road that ends in tears. ProxyPassReverse only re-writes headers like SetCookie and Location. If you have links within your pages, you'll need to use something like mod_html to re-write all of them as the page is streamed back to the client. Best practice is to re-name the application to apps#foo.war if that's really the URL path you want to use. (The above configuration does not use mod_rewrite, hence the absence of RewriteEngine On.) BTW: we don't seem to be able to get the example to work. ProxyPass /myapp ajp://localhost:8009/myapp works, but ProxyPass /app ajp://localhost:8009/myapp does not work, and we've tried various iterations of ProxyPassReverse with it. When you say doesn't work, what do you really mean Means we can't reach the app on the Tomcat side. What's the best way to handle ROOT.war, assuming there are other webapps to deploy as well? This is tough. I would recommend that you put all web applications in distinct paths, and not use ROOT at all. It makes proxying a little more sane IMHO. You can definitely still do it (just do all your ProxyPasses for the non-ROOT webapps *first* in httpd.conf, and then have one that does something like ProxyPass / [endpoint] last to handle the ROOT webapp. This will be very helpful, since the primary app is currently deployed as ROOT. (We are using Tomcat direct connections, but moving to an HTTPD front-end for a few deployments.) What if I don't want ROOT.war, but want to send / to a specific webapp? Put index.html into ROOT/index.html and do a redirect (or something roughly equivalent, like using RedirectMatch ^/$ /webapp/). SSL Question: Since our web.xml is configured to redirect all requests to SSL in the security-constraints area, how does that effect the options that need to be supplied in the connector? Right now, we just have the basic config as it comes in the initial conf.xml. When using mod_proxy_ajp, the SSL information should be passed-over from httpd to Tomcat just like when you are using mod_jk, so I don't think you'll get a redirect storm. mod_jk sends-over some extra stuff by default that mod_proxy_ajp I think does not, but I can't remember off the top of my head what those things are. OK, I was just wondering what parameters need to be set in the Connector for AJP and if any needed to be specified for the whole redirect to SSL thingy. I'm guessing it still needs a redirect parameter in the above case? Re-reading the documentation. Sorry for being a newbie on this, but the last time I messed with Apache proxy was 4.0 and then I used JK. You can still certainly use mod_jk, but you'll find the same issues with path-rewriting. I've been using mod_jk forever and I have no plans to abandon it. mod_jk is alive and well if you'd prefer to use something with which you have previous experience. But you do have to build it separately, since it doesn't come bundled with httpd (which is definitely a bummer). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVVeBnAAoJEBzwKT+lPKRYsAwP/086jW4zeX/5BZxJyMsEbjLp fEJCj8tJguyKoXRkgVIqeVW9aHK86elY3JYaAx/00GmrZACZbk2J963XB58E3YyV C3bd3K1BkHGYsWCoYwqEcNUIygnaJEuWrydXalcJrvrsk5vprkkFKQE/yu2Wu7gg vdNcbLe+LwySbYAJdzrBWYiyTFqarA/ShFkyMcpsEz+TWpbcDZptfpLLs2M30lPz /53OaJvfVs4yle/nXaqvG7R61RXc1/JkEOVApXMhn+lCnP2XBwNhVtpqsAjwIRMv ArdZClXH5wEpB+8rwWZVwMVQhJZJqGZXjBX8k9r1zNoXzomN6TWnB6zcnjOBpMVC RaErv9KQmSDsRWwmz5wyhdHWNPOVo48g0oCZhg22cF4tCXd879x25P4HIEyR5hT/ oJppa8kT7nSSaRQbq3s0n1LrBUMa7FqF+544zID6HnATSlNVADP5DOMUFrrEU+yH
Re: Fwd:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Yuval, On 5/20/15 9:34 AM, Yuval Schwartz wrote: I believe I am running tomcat 8.0 (although when I call the getServerInfo() method of the implicit ServletContext Object It tells me that I am running on 7.54) Then you are not running Tomcat 8.0.x. I configured my realm element in my context.xml file as follows (based on the howto guide: https://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html): If you are running Tomcat 7, the Tomcat 8 users guide may give you bad guidance. If you are intending to run Tomcat 8, you might want to get that fixed, first. Realm className=org.apache.catalina.realm.DataSourceRealm debug=99 The debug attribute hasn't been supported for something like 10 years. dataSourceName=jdbc/board localDataSource=true userTable=test_user userNameCol=Email userCredCol=HashedPassword userRoleTable=test_user_role roleNameCol=Role CredentialHandler className=MessageDigestCredentialHandler algorithm=SHA-1 iterations=1000 saltLength=48/ Oh, good: someone is using the CredentialHandler to improve their security. You might want to: 1. Switch to a larger hash, like SHA-256 2. Find out how much time it takes to do 1000 SHA-1 (or SHA-256) hashes on your server. You want the hashing to take more than a trivial amount of time. Our services currently use more than 10k iterations of SHA-256. This makes brute-forcing our password database very time consuming for an attacker, if they were to capture the database itself. /Realm However, despite the password being stored in the format described in your how to manual (ie:{salt}${iterations}${password}), authentication fails. I assume that this is because something in my Realm configuration is wrong. Tomcat can generate a hash for you from the command-line: $ ./bin/digest.sh -a SHA-256 -i 1000 -s 48 'test' test:04d9deb5f6f1f206c7139a28806e7ebde8f444018e0191168f8d00291d6e8719cd2 5cc82eca073f9a925c005aadf238b$1000$22cb9257949205ffbff01088b46137cf768dc 67a0faca26f48269ca9250d4d9b Let's take-apart that credential to see what's in there: hash: 04d9deb5 f6f1f206 c7139a28 806e7ebd e8f44401 8e019116 8f8d0029 1d6e8719 cd25cc82 eca073f9 a925c005 aadf238b That's 48 bytes (96 characters) of data. iteration count: 1000 (easy) fingerprint: 22cb9257 949205ff bff01088 b46137cf 768dc67a 0faca26f 48269ca9 250d4d9b That's 32 bytes (64 characters) of data. SHA-1 produces 32-byte output, so this looks good on the face of it. I was not able to find an answer on online help forums. I also couldn't find a way to call the initialized DataSourceRealm Object's digest method when inputting the HashedPassword (ie: I had to calculate salt and hash on my own using the SHA-1 algorithm). Perhaps this also has something to do with why authentication is failing? You probably weren't following the algorithm the same way. For example, the 1000 iterations is done like this: cred = password do 1000 times: cred = hash ( salt + cred ) You probably forgot to salt the credential for each of the iterations. Take a look at the RealmBase class to see how the stored credential should be generated initially. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVXJ/UAAoJEBzwKT+lPKRYHZUQAKWVQoUhMr1QhBLBPmypX6By vQob26NzVU5h9C14CdiTuTJS1uc664yvgZHGkW3xfIKGlRmH0Kez/fuwO7ral1LX 4NWtkX1x2sRVTXZ5ZrEIcM9ofXrELqHCQmS3Jq7Y2VaXvAEvSNvsuY5kSh6+T8/w xEGyd509BU/QssidcQHGSjupxzlwbDngaWps2M4MW5JHfYBGzylNVw4tBpLwBEWm halR3EdHnIc/ReDCzelS9wH96onOAgMsnioh0ib/sC//5KVM6Mo1wh5IdTmQTcTp YF2Wj8QVMj8xaOrGMBqnEoimtY069QEJvaVeltmb0qle/ixKs7qbnrFUcR8Gpju3 ytf1JEUSi29Pw+ct5GL7HPN66P1Y0OfevFLlcB4UUALfceaKrI41/yQBpr8fp7U6 tMQ6fp6k11z92e2+MVgYosi2czpsRwJJO91GY85Ai2YlB8fLbQ9j3dv4Qzh1rl5m pF9B6G1zYLkXSEXk4ugEmHptTvDibPD9BSChnttZPUsLJN2oZfGBjZ2yEeKNpk4P 4xim6CiSfVFT6YNnKYmClzDOk4V+Lpo5uTLSHsd/GdueiSOoQXJmgRpoV7/uacWq J1QSUsyneNPVdrLosfTiidpgYCtTOKZSZ8OEdCiZV09m0JNnRcEoje3nNGYXlUg3 1EyyDLzlNZyDqRTYl+gJ =N8j2 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org