Tomcat embedded with Apache Solr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, I've posted a question to the Solr mailing list[1] about why Jetty is being used instead of Tomcat, and it seems that it's just "always the way it's been" for the most part. These seems to be some interest in moving from their existing model (Jetty launches, then hosts Solr as a web application) to an embedded model where a Solr-agent launches and then launches the app server (e.g. tc) hosting itself. Is anyone familiar enough with Solr to whip-up a quick-and-dirty POC for Tomcat-embedded-hosting-Solr? I'd like to make the case that Tomcat isn't some big, bad heavy monster that should be avoided for some other product. There appears to be soe unfounded hatred[4] going around. The Solr team seems especially conscious of runtime memory footprint, and they don't have any use for JSP, Websocket, or anything fancy. They just want to pump bytes back and forth to their basic servlet-based service. Can anyone chime-in on that thread referenced below with some thoughts on how Solr might be able to use Tomcat-embedded as a platform for soe future version? Also see [2] and [3]. Thanks, - -chris [1] https://lists.apache.org/thread.html/69c3a6ef96d99aa79d5ab15b23e1eb75d8f 32b0709fa14cc7cdded91@%3Cdev.lucene.apache.org%3E [2] https://issues.apache.org/jira/browse/SOLR-6733 [3] https://issues.apache.org/jira/browse/SOLR-6734 ?? [4] https://lists.apache.org/thread.html/c5786fd956d6d9029ddacc5af18147d098d 5a8675ebda78db14c10f1@%3Cdev.lucene.apache.org%3E -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvCnsMACgkQHPApP6U8 pFiqwA/+PbcFqOUhXacAzRwzBGtK0WELMHrr1QCkPYWw1D6yxgNq2kKya6jWh9XK +EFb1ZkaYDFunseLsXdLw6pN7fkxPjLRUVFLUr+57csGKR8nH+Y36uaKXErKG1TD w1PHOIjZkNfN1i5x3aouqZVGwxbqB41HZeXYDmaknNX5yhZGoZQlgLkH8DXZRj4H qLMIY2WV3q0tUz/9mVi4Lvtvejr01KUiALYxurwxJI9rToLdOEv3qIOk2+sNy5b7 P8G2eUgMtA7vdXQ+sajXV+KptKkzcNHwehgX0YxYsV56tkaVgWkg6d63KZj11qgm xWzUpdiGYXXVTFfEPSEVSu3psqBGIHDvv234PMGs2A+sqM8kaynJkbQsJJ7fu9Co oA7clrptZbyGqVB4ASAxWC+PXeuycGnMFplZRfRXagmcmkChxli+Y2MqFekdKHO6 VF6ExuzK7gg3ogZ1R+4sHYYW/KBTSaS+OVHXjJvTppATQbsnAGkZ5/93zTdlnbMh Ua9WOICaOats7XDcDhgpSmClL5SdOWQ+THCeT5hrnI7CttefihdPp4fqrDOPJ0O+ fhcVv1J80GJIIPq2g48MzmxQoT08tKxomM9EeZbApnV9ptQxz6RgLAYYGryYUqjn 7v3Aoc6YS6WWEicZ6iR1j3AD5mE/kV0/GxZ8L52MPyVb4gvhiVU= =/itJ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 8 and authenticating Basic Auth users
Hello André, It's routed through a server... A co-worker noticed a Tomcat valve that might do the trick... https://github.com/lokechenlin/tomcat-auto-login-valve Your thoughts? Tony -Original Message- From: André Warnier (tomcat) [mailto:a...@ice-sa.com] Sent: Saturday, October 13, 2018 4:38 PM To: users@tomcat.apache.org Subject: Re: Tomcat 8 and authenticating Basic Auth users On 13.10.2018 18:54, Tony Esposito wrote: > Hello André, > > Thank you for taking the time to put together this excellent explanation. > > I do not have control over the server that is passing me the Basic Auth > header, unfortunately. Ok, so to make things clearer : when Tomcat receives a request for this "myapp" application, where does this request come from ? From a user browser, or from another server directly ? > > You mentioned "In other words, there is no "trick" to add to stop Tomat > trying to authenticate the client. By default, it doesn't. > If it does, it is because it was asked to, by something added to the default > configuration." > > Ok, maybe the server IS asking for Basic Auth. I inherited this > server (and this dilemma) show how/where do I check to see if Basic > Auth is 'on'? Because I don't see it and (less valid) That's the puzzle indeed, if the "myapp" webapp's web.xml does not contain any thing, and neither does the general conf/web.xml (which gets merged with every webapp's web.xml, so it was a good idea to check there too). I think that you will have to activate (and look at) the Access Log, to find out which requests really come into your server. Look here : http://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#Access_Log_Valve The Access Log produces lines like this : 127.0.0.1 - - [10/Oct/2017:17:54:41 +0200] "GET /favicon.ico HTTP/1.1" 200 21630 The penultimate value is the status code returned by Tomcat to the client, for this request. The last value is the (data) size of the response (excluding headers). You will be looking for requests which trigger a status code 401. If there are any, that is a clear sign that the corresponding application (with the URL in the same line) has some auth. requirement. > I was told by the previous web admin that Basic Auth was turned off. Disregard that. Basic Auth cannot be "turned off". It is an inherent part of the code (of any webserver, because it is mandated by the HTTP RFC); it is always there. But it "activates" only when it is told to activate. > > Thank you again for your time > > Tony > > > -Original Message- > From: André Warnier (tomcat) [mailto:a...@ice-sa.com] > Sent: Saturday, October 13, 2018 7:53 AM > To: users@tomcat.apache.org > Subject: Re: Tomcat 8 and authenticating Basic Auth users > > On 13.10.2018 04:56, Tony Esposito wrote: >> But you still want your application to see this Basic Auth header, because >> it needs to check the "standard password" in it, right ? >> (Otherwise, describe precisely what you want). >> >> If there is a way to disable Basic Auth (i.e. not compel the user to >> authenticate yet again) without triggering on the password or ignoring the >> header altogether, then the password is not important. >> I mentioned the password in the hopes that I could use it in some way to >> trigger the disabling of Basic Auth. >> >> P.S. >> >> 1) You say "Installed 'out of the box - as is'", but what box ? >> The standard Tomcats 8.0 or 8.5 do not have an active Connector for port >> 8088. >> So it does not look as if it is so 'out of the box - as is'. >> Where does that Tomcat come from, really ? >> >> It was installed by the previous admin -- I inherited it. >> Of course, there are other web apps on other ports. For example, there are >> 2 Connectors defined in the server.xml file. >> When I said 'as is' I was thinking in the context of Basic Auth. I have >> done nothing to change Basic Auth. >> >> 2) your application has a WEB-INF/web.xml file in it. >> What does it say about authentication ? >> The /webapps/WEB-INF/myapp/web.xml file for each >> app has no security constraints. >> The /conf/web.xml file also has no security >> constraints. >> There is no web.xml file under >> /webapps/ROOT/WEB-INF. >> Was there anything in particular you were referring to? >> > No. But that is strange. > Not that this would imply in any way that I encourage you to set up some form > of bastard authentication without really knowing what you're doing > (obviously), but here are some pointers : > > A browser (or any respectful-of-the-HTTP-rfc client), will *send* an > "Authorization: > Basic" header (which contains a user-id and password in clear, just > Base64-encoded) to a server, *only* after the following has happened : > 1) the client makes a first request to the server, for some URL > 2) the server checks if the requested resource is "protected". > If not, it sends the resource to the client and that's then end of this > request. > 3) If the resource is protected, the serv
Re: Tomcat 8 and authenticating Basic Auth users
On 13.10.2018 18:54, Tony Esposito wrote: Hello André, Thank you for taking the time to put together this excellent explanation. I do not have control over the server that is passing me the Basic Auth header, unfortunately. Ok, so to make things clearer : when Tomcat receives a request for this "myapp" application, where does this request come from ? From a user browser, or from another server directly ? You mentioned "In other words, there is no "trick" to add to stop Tomat trying to authenticate the client. By default, it doesn't. If it does, it is because it was asked to, by something added to the default configuration." Ok, maybe the server IS asking for Basic Auth. I inherited this server (and this dilemma) show how/where do I check to see if Basic Auth is 'on'? Because I don't see it and (less valid) That's the puzzle indeed, if the "myapp" webapp's web.xml does not contain any thing, and neither does the general conf/web.xml (which gets merged with every webapp's web.xml, so it was a good idea to check there too). I think that you will have to activate (and look at) the Access Log, to find out which requests really come into your server. Look here : http://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#Access_Log_Valve The Access Log produces lines like this : 127.0.0.1 - - [10/Oct/2017:17:54:41 +0200] "GET /favicon.ico HTTP/1.1" 200 21630 The penultimate value is the status code returned by Tomcat to the client, for this request. The last value is the (data) size of the response (excluding headers). You will be looking for requests which trigger a status code 401. If there are any, that is a clear sign that the corresponding application (with the URL in the same line) has some auth. requirement. I was told by the previous web admin that Basic Auth was turned off. Disregard that. Basic Auth cannot be "turned off". It is an inherent part of the code (of any webserver, because it is mandated by the HTTP RFC); it is always there. But it "activates" only when it is told to activate. Thank you again for your time Tony -Original Message- From: André Warnier (tomcat) [mailto:a...@ice-sa.com] Sent: Saturday, October 13, 2018 7:53 AM To: users@tomcat.apache.org Subject: Re: Tomcat 8 and authenticating Basic Auth users On 13.10.2018 04:56, Tony Esposito wrote: But you still want your application to see this Basic Auth header, because it needs to check the "standard password" in it, right ? (Otherwise, describe precisely what you want). If there is a way to disable Basic Auth (i.e. not compel the user to authenticate yet again) without triggering on the password or ignoring the header altogether, then the password is not important. I mentioned the password in the hopes that I could use it in some way to trigger the disabling of Basic Auth. P.S. 1) You say "Installed 'out of the box - as is'", but what box ? The standard Tomcats 8.0 or 8.5 do not have an active Connector for port 8088. So it does not look as if it is so 'out of the box - as is'. Where does that Tomcat come from, really ? It was installed by the previous admin -- I inherited it. Of course, there are other web apps on other ports. For example, there are 2 Connectors defined in the server.xml file. When I said 'as is' I was thinking in the context of Basic Auth. I have done nothing to change Basic Auth. 2) your application has a WEB-INF/web.xml file in it. What does it say about authentication ? The /webapps/WEB-INF/myapp/web.xml file for each app has no security constraints. The /conf/web.xml file also has no security constraints. There is no web.xml file under /webapps/ROOT/WEB-INF. Was there anything in particular you were referring to? No. But that is strange. Not that this would imply in any way that I encourage you to set up some form of bastard authentication without really knowing what you're doing (obviously), but here are some pointers : A browser (or any respectful-of-the-HTTP-rfc client), will *send* an "Authorization: Basic" header (which contains a user-id and password in clear, just Base64-encoded) to a server, *only* after the following has happened : 1) the client makes a first request to the server, for some URL 2) the server checks if the requested resource is "protected". If not, it sends the resource to the client and that's then end of this request. 3) If the resource is protected, the server checks if the client's request already contains some form of authorization. If the "protection" indicates that this is protected by a "HTTP Basic authentication", then what the server will be looking for, is a "Authorization:" header, with a type "Basic". 4) if the request already contains such a header, the server decodes it into a user-id/password, and /then/ checks with whatever back-end is configured (can be a file, or a database, or whatever - that's what Tomcat calls a "Realm"), to see if these credentials are correct. 5) If the credential
RE: Tomcat 8 and authenticating Basic Auth users
Hello André, Thank you for taking the time to put together this excellent explanation. I do not have control over the server that is passing me the Basic Auth header, unfortunately. You mentioned "In other words, there is no "trick" to add to stop Tomat trying to authenticate the client. By default, it doesn't. If it does, it is because it was asked to, by something added to the default configuration." Ok, maybe the server IS asking for Basic Auth. I inherited this server (and this dilemma) show how/where do I check to see if Basic Auth is 'on'? Because I don't see it and (less valid) I was told by the previous web admin that Basic Auth was turned off. Thank you again for your time Tony -Original Message- From: André Warnier (tomcat) [mailto:a...@ice-sa.com] Sent: Saturday, October 13, 2018 7:53 AM To: users@tomcat.apache.org Subject: Re: Tomcat 8 and authenticating Basic Auth users On 13.10.2018 04:56, Tony Esposito wrote: > But you still want your application to see this Basic Auth header, because it > needs to check the "standard password" in it, right ? > (Otherwise, describe precisely what you want). > > If there is a way to disable Basic Auth (i.e. not compel the user to > authenticate yet again) without triggering on the password or ignoring the > header altogether, then the password is not important. > I mentioned the password in the hopes that I could use it in some way to > trigger the disabling of Basic Auth. > > P.S. > > 1) You say "Installed 'out of the box - as is'", but what box ? > The standard Tomcats 8.0 or 8.5 do not have an active Connector for port 8088. > So it does not look as if it is so 'out of the box - as is'. > Where does that Tomcat come from, really ? > > It was installed by the previous admin -- I inherited it. > Of course, there are other web apps on other ports. For example, there are 2 > Connectors defined in the server.xml file. > When I said 'as is' I was thinking in the context of Basic Auth. I have done > nothing to change Basic Auth. > > 2) your application has a WEB-INF/web.xml file in it. > What does it say about authentication ? > The /webapps/WEB-INF/myapp/web.xml file for each > app has no security constraints. > The /conf/web.xml file also has no security > constraints. > There is no web.xml file under > /webapps/ROOT/WEB-INF. > Was there anything in particular you were referring to? > No. But that is strange. Not that this would imply in any way that I encourage you to set up some form of bastard authentication without really knowing what you're doing (obviously), but here are some pointers : A browser (or any respectful-of-the-HTTP-rfc client), will *send* an "Authorization: Basic" header (which contains a user-id and password in clear, just Base64-encoded) to a server, *only* after the following has happened : 1) the client makes a first request to the server, for some URL 2) the server checks if the requested resource is "protected". If not, it sends the resource to the client and that's then end of this request. 3) If the resource is protected, the server checks if the client's request already contains some form of authorization. If the "protection" indicates that this is protected by a "HTTP Basic authentication", then what the server will be looking for, is a "Authorization:" header, with a type "Basic". 4) if the request already contains such a header, the server decodes it into a user-id/password, and /then/ checks with whatever back-end is configured (can be a file, or a database, or whatever - that's what Tomcat calls a "Realm"), to see if these credentials are correct. 5) If the credentials are ok, the server returns the requested resource, and that's the end of the request. 6) If the credentials are not ok, the server returns a response to the client, with a "status code" 401, meaning "needs authentication". If the resource is protected by an authentication "Basic", then the server response will include a "WWW-authenticate: Basic" header. 7) when the client receives this response, if it is a browser, it will then popup a login dialog, to request the user-id/password from the user. When the user has entered that userid/pw, the client will re-send the same request to the server, but this time with a "Authorization:" header containing the userid/passwrd entered by the user. (If that client is not a browser, it is supposed to fetch a userid/pw from somewhere, and do the same). 8) go back to (2) That is how Basic Auth works, in the HTTP RFC and in Tomcat. There is something special about Basic Auth, in the sense that once a client has succesfully accessed a location on the server, it will keep sending the same Authorization: header for that same location, without prompting the user again, until you close the program and start anew. Now consider the above carefully, because it has some implications : a) the server will not send a 401 rsponse to the client, if the accessed resource is not
Re: Tomcat 8 and authenticating Basic Auth users
On 13.10.2018 04:56, Tony Esposito wrote: But you still want your application to see this Basic Auth header, because it needs to check the "standard password" in it, right ? (Otherwise, describe precisely what you want). If there is a way to disable Basic Auth (i.e. not compel the user to authenticate yet again) without triggering on the password or ignoring the header altogether, then the password is not important. I mentioned the password in the hopes that I could use it in some way to trigger the disabling of Basic Auth. P.S. 1) You say "Installed 'out of the box - as is'", but what box ? The standard Tomcats 8.0 or 8.5 do not have an active Connector for port 8088. So it does not look as if it is so 'out of the box - as is'. Where does that Tomcat come from, really ? It was installed by the previous admin -- I inherited it. Of course, there are other web apps on other ports. For example, there are 2 Connectors defined in the server.xml file. When I said 'as is' I was thinking in the context of Basic Auth. I have done nothing to change Basic Auth. 2) your application has a WEB-INF/web.xml file in it. What does it say about authentication ? The /webapps/WEB-INF/myapp/web.xml file for each app has no security constraints. The /conf/web.xml file also has no security constraints. There is no web.xml file under /webapps/ROOT/WEB-INF. Was there anything in particular you were referring to? No. But that is strange. Not that this would imply in any way that I encourage you to set up some form of bastard authentication without really knowing what you're doing (obviously), but here are some pointers : A browser (or any respectful-of-the-HTTP-rfc client), will *send* an "Authorization: Basic" header (which contains a user-id and password in clear, just Base64-encoded) to a server, *only* after the following has happened : 1) the client makes a first request to the server, for some URL 2) the server checks if the requested resource is "protected". If not, it sends the resource to the client and that's then end of this request. 3) If the resource is protected, the server checks if the client's request already contains some form of authorization. If the "protection" indicates that this is protected by a "HTTP Basic authentication", then what the server will be looking for, is a "Authorization:" header, with a type "Basic". 4) if the request already contains such a header, the server decodes it into a user-id/password, and /then/ checks with whatever back-end is configured (can be a file, or a database, or whatever - that's what Tomcat calls a "Realm"), to see if these credentials are correct. 5) If the credentials are ok, the server returns the requested resource, and that's the end of the request. 6) If the credentials are not ok, the server returns a response to the client, with a "status code" 401, meaning "needs authentication". If the resource is protected by an authentication "Basic", then the server response will include a "WWW-authenticate: Basic" header. 7) when the client receives this response, if it is a browser, it will then popup a login dialog, to request the user-id/password from the user. When the user has entered that userid/pw, the client will re-send the same request to the server, but this time with a "Authorization:" header containing the userid/passwrd entered by the user. (If that client is not a browser, it is supposed to fetch a userid/pw from somewhere, and do the same). 8) go back to (2) That is how Basic Auth works, in the HTTP RFC and in Tomcat. There is something special about Basic Auth, in the sense that once a client has succesfully accessed a location on the server, it will keep sending the same Authorization: header for that same location, without prompting the user again, until you close the program and start anew. Now consider the above carefully, because it has some implications : a) the server will not send a 401 rsponse to the client, if the accessed resource is not protected by a Basic authentication b) without a 401 received from the server, a normal client will not send an "Authorization:" header c) if the client nevertheless sends an Authorization header, for a resource that is not protected on the server, the server will ignore this header So there is something wrong, either in your explanations so far, or in the configuration of your server, or the client, because the server should not be "challenging" the client (with a 401), unless the application which the client tries to access is protected by a Basic authentication. And the client should not be sending a Basic Authorization header, unless it has been challenged previously by the server (with a 401). Which comes back to something Christopher mentioned already a good while back, but which you seem to keep ignoring : if you do not want the client to try to authenticate, then do not protect your application. In other words, there is no "trick" to add to s
