Re: basic auth required on https but not required on http
On Wed, Feb 20, 2013 at 10:38 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 2/20/13 1:40 PM, André Warnier wrote: Andrew Winter wrote: On Wed, Feb 20, 2013 at 5:13 AM, André Warnier a...@ice-sa.com wrote: Okay, I have this resolved, now. I went with the FORM authentication method and created a servlet that will create a login screen on an isSecure() connection. For standard HTTP requests I pass over a self submitting form with the credentials included. This will work for the human interfaces and I will just have to deal with any programmatic access problems as I find them. You could probably just force an authenticated user into Tomcat (userPrincipal and that kind of thing) when the connection is internal. That would also probably solve your programmatic access case. Or just use HttpServletRequest.login(String username, String password). No need to force an actual form. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlEllrwACgkQ9CaO5/Lv0PCQeQCfV7OMDpuC7PnQK3pcCVksM5lg MhcAn1TYFdV+9lXESMxeYOeXcYGrFyXi =hSIr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org I have tried the HttpServletRequest.login(String username, String password). I find that it works if I put it in the servlet I made for the FORM login. But it requires a second request to actually reach the page. The first request serves to authenticate only. Is there a way to do this so that I can get to the web app with the same request that does the log in?
Re: basic auth required on https but not required on http
On Feb 20, 2013 5:13 AM, André Warnier a...@ice-sa.com wrote: The standard modus operandi of this list is to not top-post (makes it more difficult to follow the logical flow of conversation). So I've copied your response and my further comments at end. Andrew Winter wrote: I work on an intranet type application. While on the local network calls are made to regular http and authentication is not allowed due to a large number of established services that call the server without providing authentication. However, the server accepts calls from the outside over SSL (regular http port is blocked by firewall). In these cases the use of basic authentication is required. I don't see a way to have work like this. With our older setup we used Apache as a front end and had a virtual host file for each port. One used https and basic auth and the other didn't. Both pointed to the same web app. Now I must send calls directly to Tomcat as we are implementing asynchronous requests. What can I do here? Do the same as under httpd (except one thing) : use separate Host's within the Tomcat configuration (same as VirtualHost under Apache). Deploy a separate copy of your webapps within each Host's appBase. In one Host, you protect them via Basic Auth, in the other Host you do not. Under Tomcat, it is not recommended to use the same appBase (roughly the same as Apache's DocumentRoot) for two separate Host's, because this creates problems of double deployment etc. So use two separate sets of webapps. They are still the same webapp, just deployed twice, in different locations. Is that a problem for you ? Roughly (check the proper syntax on tomcat.apache.org) : server.xml : Engine ... Host name=host1.company.com appBase=/some/dir/number1 .. ... /Host Host name=host2.company.com appBase=/some/dir/number2 .. ... /Host ... /some/dir/number1 |- ROOT/ |- webapp1 |- webapp2 /some/dir/number2 |- ROOT/ |- webapp1 |- webapp2 the 2 webapp1 are the same (same code, same files,..) (*) the 2 webapp2 are the same (*) actually, almost the same, since their WEB-INF/web.xml will be different : one has to be accessed via HTTPS and use Basic Auth, the other one not. Andrew Winter wrote: Thanks. A lot of file IO goes on with this app. There are a couple of files in particular that are held open for the life of the app and written to sporadically. I am thinking that having the same code as two web apps would lead to those files getting clobbered. Is there a way to make the 'same appbase with 2 hosts' version work? On Feb 19, 2013 5:57 PM, André Warnier a...@ice-sa.com wrote: Well, at first I'd say no. Even if you were to point both appBase's at the same disk location (and turn off auto-deploy !), you would still logically have different instances of the webapp running at the same time (one for each host, at least). There are certainly other ways to achieve what you want to do, but I am getting a bit out of my depth here, so be careful of what I'm saying next, and maybe wait for other more qualified people's comments. One way that I could imagine would be to have a single Host with an alias, and wrap your webapp inside of a servlet filter, which would check the host/port that the request came in from. If it came in through the HTTPS connection (or the appropriate HTTPS hostname, or a not-from-Intranet IP address), the filter would allow the request to proceed only if it is authenticated, and otherwise redirect it to a login page e.g. Maybe the URLRewriteFilter servlet filter (www.tuckey.org) would allow such a thing. It's a bit like the workhorse for things like that. Otherwise you'd have to write your own (or get it written). As a servlet-filter based solution, that would not require any modification to your webapp. It would not even know that it is being wrapped that way. There are certainly people on this list who would be available for a little job like that. (Not me though). The problem I ran into earlier with the URLRewriteFilter servlet is that it broke the asynchronous request operation. It may be worth another try as that was when I was using the comet implementation and I have since rewritten it in the servlet api 3 version. I guess my only other option at this point would be to modify the tomcat source to add a port attribute to the web.xml section that defines which resources are too be secured with basic auth? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: basic auth required on https but not required on http
On Wed, Feb 20, 2013 at 5:13 AM, André Warnier a...@ice-sa.com wrote: The standard modus operandi of this list is to not top-post (makes it more difficult to follow the logical flow of conversation). So I've copied your response and my further comments at end. Andrew Winter wrote: I work on an intranet type application. While on the local network calls are made to regular http and authentication is not allowed due to a large number of established services that call the server without providing authentication. However, the server accepts calls from the outside over SSL (regular http port is blocked by firewall). In these cases the use of basic authentication is required. I don't see a way to have work like this. With our older setup we used Apache as a front end and had a virtual host file for each port. One used https and basic auth and the other didn't. Both pointed to the same web app. Now I must send calls directly to Tomcat as we are implementing asynchronous requests. What can I do here? Do the same as under httpd (except one thing) : use separate Host's within the Tomcat configuration (same as VirtualHost under Apache). Deploy a separate copy of your webapps within each Host's appBase. In one Host, you protect them via Basic Auth, in the other Host you do not. Under Tomcat, it is not recommended to use the same appBase (roughly the same as Apache's DocumentRoot) for two separate Host's, because this creates problems of double deployment etc. So use two separate sets of webapps. They are still the same webapp, just deployed twice, in different locations. Is that a problem for you ? Roughly (check the proper syntax on tomcat.apache.org) : server.xml : Engine ... Host name=host1.company.com appBase=/some/dir/number1 .. ... /Host Host name=host2.company.com appBase=/some/dir/number2 .. ... /Host ... /some/dir/number1 |- ROOT/ |- webapp1 |- webapp2 /some/dir/number2 |- ROOT/ |- webapp1 |- webapp2 the 2 webapp1 are the same (same code, same files,..) (*) the 2 webapp2 are the same (*) actually, almost the same, since their WEB-INF/web.xml will be different : one has to be accessed via HTTPS and use Basic Auth, the other one not. Andrew Winter wrote: Thanks. A lot of file IO goes on with this app. There are a couple of files in particular that are held open for the life of the app and written to sporadically. I am thinking that having the same code as two web apps would lead to those files getting clobbered. Is there a way to make the 'same appbase with 2 hosts' version work? On Feb 19, 2013 5:57 PM, André Warnier a...@ice-sa.com wrote: Well, at first I'd say no. Even if you were to point both appBase's at the same disk location (and turn off auto-deploy !), you would still logically have different instances of the webapp running at the same time (one for each host, at least). There are certainly other ways to achieve what you want to do, but I am getting a bit out of my depth here, so be careful of what I'm saying next, and maybe wait for other more qualified people's comments. One way that I could imagine would be to have a single Host with an alias, and wrap your webapp inside of a servlet filter, which would check the host/port that the request came in from. If it came in through the HTTPS connection (or the appropriate HTTPS hostname, or a not-from-Intranet IP address), the filter would allow the request to proceed only if it is authenticated, and otherwise redirect it to a login page e.g. Maybe the URLRewriteFilter servlet filter (www.tuckey.org) would allow such a thing. It's a bit like the workhorse for things like that. Otherwise you'd have to write your own (or get it written). As a servlet-filter based solution, that would not require any modification to your webapp. It would not even know that it is being wrapped that way. There are certainly people on this list who would be available for a little job like that. (Not me though). Okay, I have this resolved, now. I went with the FORM authentication method and created a servlet that will create a login screen on an isSecure() connection. For standard HTTP requests I pass over a self submitting form with the credentials included. This will work for the human interfaces and I will just have to deal with any programmatic access problems as I find them. Thank you for all your help!
Re: basic auth required on https but not required on http
Thanks. A lot of file IO goes on with this app. There are a couple of files in particular that are held open for the life of the app and written to sporadically. I am thinking that having the same code as two web apps would lead to those files getting clobbered. Is there a way to make the 'same appbase with 2 hosts' version work? On Feb 19, 2013 5:57 PM, André Warnier a...@ice-sa.com wrote: Andrew Winter wrote: I work on an intranet type application. While on the local network calls are made to regular http and authentication is not allowed due to a large number of established services that call the server without providing authentication. However, the server accepts calls from the outside over SSL (regular http port is blocked by firewall). In these cases the use of basic authentication is required. I don't see a way to have work like this. With our older setup we used Apache as a front end and had a virtual host file for each port. One used https and basic auth and the other didn't. Both pointed to the same web app. Now I must send calls directly to Tomcat as we are implementing asynchronous requests. What can I do here? Do the same as under httpd (except one thing) : use separate Host's within the Tomcat configuration (same as VirtualHost under Apache). Deploy a separate copy of your webapps within each Host's appBase. In one Host, you protect them via Basic Auth, in the other Host you do not. Under Tomcat, it is not recommended to use the same appBase (roughly the same as Apache's DocumentRoot) for two separate Host's, because this creates problems of double deployment etc. So use two separate sets of webapps. They are still the same webapp, just deployed twice, in different locations. Is that a problem for you ? Roughly (check the proper syntax on tomcat.apache.org) : server.xml : Engine ... Host name=host1.company.com appBase=/some/dir/number1 .. ... /Host Host name=host2.company.com appBase=/some/dir/number2 .. ... /Host ... /some/dir/number1 |- ROOT/ |- webapp1 |- webapp2 /some/dir/number2 |- ROOT/ |- webapp1 |- webapp2 the 2 webapp1 are the same (same code, same files,..) (*) the 2 webapp2 are the same (*) actually, almost the same, since their WEB-INF/web.xml will be different : one has to be accessed via HTTPS and use Basic Auth, the other one not. --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Comet problem - HTTP method GET is not supported by this URL
I am trying to implement a Comet process.
Tomcat 6.0.36
Red Hat Enterprise Linux Server release 6.2 (Santiago)
Java 7u11 (32 bit)
I have implemented CometProcessor. I am using the NIO connector.
When I try the servlet I get: HTTP method GET is not supported by this
URL
Am I doing something wrong?
Thanks!
Code snippet:
public class ConsolidatedActionCenterPush extends HttpServlet implements
CometProcessor,CAC{
private static MessageSender messageSender = null;
static ??
private static final Integer TIMEOUT = 600 * 1000;
@Override
public void destroy() {
messageSender.stop();
messageSender = null;
This would break if there is more than 1 instance of your servlet.
Thank you for drawing my attention to this potential issue. Perhaps I need
to verify an assumption of mine: I am thinking that since I am not using a
distributed environment there will only be one instance of this servlet.
If you want the long story: This is an intranet application and this piece
is used for sending messages to the users. As such there are other threads
that use the static methods to add messages. In the past when I had the
clients polling on an interval it would not have mattered if an instance
came or went. I will reconsider what I have done here.
What filters do you have in the request processing chain for this
servlet? Do they support Comet? (I do not remember whether it is
important for Comet. Just guessing).
You can use new Exception().printStackTrace() to check what valves
and filters are active for you.
Thank you so much! Looking at my stack trace I saw something that made me
suspicious. The invoker servlet. I needed this as we have an mountain of
servlets that have always been called via the package name in the URL.
Once I removed this the Comet functionality worked! So I guess I will be
mapping a lot of servlets in the days to come, but it works so cool.
Re: The APR based Apache Tomcat Native library was not found
We have a COBOL back end that handles the core functions of our product. The only way we have for the servlet based front end to get at that data is via a type 1 odbc driver. It is a real pain because it is not thread safe so we have to funnel all the traffic through a single thread. Anyway, I got the APR working and managed to fire up Tomcat with the APR connector but my original problem (in another email) remains. That being that calls to a Comet servlet I created return a 400 response saying that the URL does not support get requests. I tried NIO first and thought that APR would perhaps solve my problem. So now I am giving up and trying to have a go with glassfish instead. Thanks for your help!! On Thu, Jan 24, 2013 at 12:18 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Andrew, On 1/23/13 9:54 PM, Andrew Winter wrote: Sorry I forgot the versions of things I am using. Tomcat 6.0.36 Red Hat Enterprise Linux Server release 6.2 (Santiago) Java 7u11 (32 bit) I think I found the problem, though. I have to run a 32 bit jvm because a COBOL odbc driver we have to use only comes in a 32 bit version. But the Red Hat box is 64 bit and when I ran 'file' on the libtcnative.so I compiled I found that it is 64 bit. So I think I just need to do a little Googling to see how to compile a 32 bit version and it could work. I think you'll need 32-bit APR and OpenSSL as well, but I've never tried to do mixed 32-bit and 64-bit support libraries. libtcnative.so absolutely must be 32-bit to be loaded by a 32-bit JVM. Reading the Debian multi-arch docs (I'm on Debian), it doesn't sound like a simple install -32 libapr... you'll need a whole set of 32-bit support libraries, etc. What's a COBOL ODBC driver? :( - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlEBbNAACgkQ9CaO5/Lv0PBmMgCfWS3jc3OFGHamEj6vYsKw7Mun 9PgAoKzOudT+RxkvNkcu7v0CEPwoXPmK =nibJ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Comet problem - HTTP method GET is not supported by this URL
Here is the NIO connector: Connector connectionTimeout=2 port=8080 protocol=org.apache.coyote.http11.Http11NioProtocol redirectPort=9192/ Normal servlet requests work, just not the Comet. After I sent this email, I installed the APR and switched back to the standard connector: Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=9192 / The log then showed that the APR connector was being used, but I get the same message when I try to use the comet servlet. Thank you! On Thu, Jan 24, 2013 at 2:45 PM, Mark Thomas ma...@apache.org wrote: On 22/01/2013 16:52, Andrew Winter wrote: I am trying to implement a Comet process. Tomcat 6.0.36 Red Hat Enterprise Linux Server release 6.2 (Santiago) Java 7u11 (32 bit) I have implemented CometProcessor. I am using the NIO connector. When I try the servlet I get: HTTP method GET is not supported by this URL Am I doing something wrong? NIO Connector config from server.xml? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
The APR based Apache Tomcat Native library was not found
I have been having problems getting comet to work and decided to try the APR connector. So I installed APR from the RPM, version apr-1.3.9-3.el6_1.2.i686. I followed instructions that I found locally and online and compiled up the tomcat-native-1.1.23. It installed in the /usr/local/apr/lib folder. In the tomcat6.conf I set the JAVA_OPTS=-Djava.library.path=/usr/local/apr/lib But I still get the message at start: INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/local/apr/lib What am I missing?
Re: The APR based Apache Tomcat Native library was not found
Sorry I forgot the versions of things I am using. Tomcat 6.0.36 Red Hat Enterprise Linux Server release 6.2 (Santiago) Java 7u11 (32 bit) I think I found the problem, though. I have to run a 32 bit jvm because a COBOL odbc driver we have to use only comes in a 32 bit version. But the Red Hat box is 64 bit and when I ran 'file' on the libtcnative.so I compiled I found that it is 64 bit. So I think I just need to do a little Googling to see how to compile a 32 bit version and it could work.
Comet problem - HTTP method GET is not supported by this URL
I am trying to implement a Comet process.
Tomcat 6.0.36
Red Hat Enterprise Linux Server release 6.2 (Santiago)
Java 7u11 (32 bit)
I have implemented CometProcessor. I am using the NIO connector.
When I try the servlet I get: HTTP method GET is not supported by this URL
Am I doing something wrong?
Thanks!
Code snippet:
public class ConsolidatedActionCenterPush extends HttpServlet implements
CometProcessor,CAC{
private static MessageSender messageSender = null;
private static final Integer TIMEOUT = 600 * 1000;
@Override
public void destroy() {
messageSender.stop();
messageSender = null;
}
@Override
public void init() throws ServletException {
messageSender = new MessageSender();
messageSender.start();
ConsolidatedActionCenterBase.setCAC(this);
EventLog.append(ConsolidatedActionCenterPush: init );
//queues = new HashMapString, WorkQueue();
}
@Override
public void event(final CometEvent event) throws IOException,
ServletException {
HttpServletRequest request = event.getHttpServletRequest();
HttpServletResponse response = event.getHttpServletResponse();
}
From catalina log:
Jan 22, 2013 11:46:19 AM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
java.library.path:
/usr/jre732/lib/i386/server:/usr/jre732/lib/i386:/usr/lib:/usr/java/packages/lib/i386:/lib:/usr/lib
Jan 22, 2013 11:46:20 AM org.apache.tomcat.util.net.NioSelectorPool
getSharedSelector
INFO: Using a shared selector for servlet write/read
Jan 22, 2013 11:46:20 AM org.apache.coyote.http11.Http11NioProtocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
Jan 22, 2013 11:46:20 AM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 540 ms
Jan 22, 2013 11:46:20 AM org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
Jan 22, 2013 11:46:20 AM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.36
Jan 22, 2013 11:46:20 AM org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deploying web application directory servlet
Jan 22, 2013 11:46:23 AM org.apache.coyote.http11.Http11NioProtocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
Jan 22, 2013 11:46:23 AM org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:10794
Jan 22, 2013 11:46:23 AM org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/18 config=null
Jan 22, 2013 11:46:23 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 3127 ms
From catalina.out:
Jan 22, 2013 11:46:23 AM org.apache.coyote.http11.Http11NioProtocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
Jan 22, 2013 11:46:23 AM org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:10794
Jan 22, 2013 11:46:23 AM org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/18 config=null
Jan 22, 2013 11:46:23 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 3127 ms
