Re: Can filters be loaded more than once?
Thanks for the help, Chris. I did note that some of the webapp web.xml files didn't include the async option. I've decided for now we'll use Tomcat's conf/web.xml to set this basic filter and let our webapps not have to think about it. On 8/28/15 12:27 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David, On 8/28/15 2:47 PM, David Wall wrote: I'm using Tomcat 8.0.23, but wondered if a filter defined in the Tomcat conf/web.xml as well as defined in my app's WEB-INF/web.xml file causes the filter to be loaded twice or whether duplicate filters are ignored? If duplicates are ignored, what makes it a duplicate? Just the name, the filter-name and url-pattern combo? The filter-class? I've never looked into this, but I would imagine that Tomcat does no checking for duplicate filter definitions. Otherwise, the above questions are raised :) Is the filter-name field can sensitive? Almost certainly. Noted that Tomcat uses a lowercase 's' for it's filter name. In Tomcat's conf/web.xml: filter filter-namesetCharacterEncodingFilter/filter-name filter-classorg.apache.catalina.filters.SetCharacterEncodingFilter/ filter-class init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param async-supportedtrue/async-supported /filter filter-mapping filter-namesetCharacterEncodingFilter/filter-name url-pattern/*/url-pattern /filter-mapping Note that the above Filter is commented-out by default. In my webapp's WEB-INF/web.xml: filter filter-nameSetCharacterEncodingFilter/filter-name filter-class org.apache.catalina.filters.SetCharacterEncodingFilter /filter-class async-supportedtrue/async-supported !-- Enable if using Vaadin PUSH -- init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param /filter filter-mapping filter-nameSetCharacterEncodingFilter/filter-name url-pattern/*/url-pattern /filter-mapping When using Atmosphere with Vaadin PUSH, I occasionally get an exception that indicates an issue with async operations, and it shows my filter twice in the stack trace: *java.lang.IllegalStateException: A filter or servlet of the current chain does not support asynchronous operations.** * at org.apache.catalina.connector.Request.startAsync(Request.java:1610) Boy, it would be nice if Tomcat told you which Filter of or Servlet of the current change didn't support asynchronous operations. I don't immediately see a good way of getting that information from the Request object. :( - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV4LYQAAoJEBzwKT+lPKRYjMoQAJuw/bu4Efmw/Mc0tm6hXaaU fJBSSsfZJfPGzahCvMGRTciTEe/E7cjsSIHgkdZKy1UUYSx2mnLZNTkiMaQRu2Sg XmmN6nzKC7dtNPrYGgkN+RqbUJXjpeO0vV6RLJHdzGcQ9vQ4409t733QQuFbuzeS DfcCCnSiwK8i4APQyuQWpuT4Th/kyehZfp4mtlIQHN6BsmekRH6VUIHI9rRajPgF zUtPEXnqdlXOD5B2dtRDePQNBVIO5s8Es+GzD68L2m/XseIt6WxbHUYe8lGcKp6g 7O7LBfe+VhgCaIsoC/aPJ9hyA75z1p/O1h8Rcb8ft4G8BYdvVYQl6Dc76XzYdVYy RdSu5FaGBRsCAromAJ0/ThSa2oKPMcrINUkMDdoMGE12Rr5+d/QVO6jMlpq0MgqY PkXox+eB7pzcFFUkU4wWDOe3xqVHgMWW4E3dop+tfCHti9HDhfcgUNP6ch7MAEIm 8+3iZ8DKeyqmvp1TQn9HQcM/I+or0qE3GvQsYZR00Z4C7Rp4/QdmMMhZwNoqgnHw kCxrIgCA2KPeEBYVkTsx9LG0P8dzitDps3EFLTsETSygfd1JmrCPx+8PlrAgjkcM 7FnrJAHX1fZ28EoNMmdf8f0FJ3InmBB9APO3Kw+YbayJeZxuV4gg/dAPZT3PGI0p RYZ2Ubhc8zpwgOTjEHMC =DJRR -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTP 400 with Form based authentication
On 29/08/2015 22:16, Sreyan Chakravarty wrote: Okay this is my first try at container based authentication using Realms in Tomcat. And things have gone wrong. Here is my login page -: snip/ My web.xml security configuration is -: security-constraint web-resource-collection web-resource-nameTECHERS/web-resource-name url-pattern/teacher/success.jsp/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection Remove the methods. By enumerating methods ONLY those methods are protected. PUT, HEAD, DELETE, etc. aould all be permitted. snip/ Now when I click on submit I get the following error page in Tomcat -: *HTTP Status 400 - Invalid direct reference to form login page* *message* *Invalid direct reference to form login page* *description* *The request sent by the client was syntactically incorrect.* Why is this happening ? Any help would be greatly appreciated. Because you requested the login page directly. You need to request the protected page and Tomcat will handle the redirects. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Designating a home page while using Realms
On 29/08/2015 22:26, Sreyan Chakravarty wrote: Okay I have just started to use Realms and container managed authentication and I am confused about as how to specify a home page. Go and read the Servlet spec for how FORM authentication works. Then read the section on how to specify security constraints. Mark Let me explain-: web-resource-collection web-resource-nameTECHERS/web-resource-name url-pattern/teacher/success.jsp/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection Here the only resource protected is /teacher/success.jsp page Now what if I wanted to add more pages to protect like /teacher/upload.jsp Do I add another url-pattern to the same web-resource-collection ? Or do I create another web-resource collection for /teacher/upload.jsp? Also if they are in the same in the web-resource-collection how does Tomcat know to go to /teacher/success.jsp and not /teacher/upload.jsp ? I mean all forms will have j_security_check as action, so which page do I go to after login if multiple pages are protected ? How do I say that success.jsp is the home page and all other pages are protected but not home pages ? Regards Sreyan Chakravarty - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How do LockOutRealms work ?
On 29/08/2015 21:51, Sreyan Chakravarty wrote: Is there any way I can tell the user that what number of login attempt he is on ? While using the LockOutRealm any way to display his login attempt on an html or jsp page ? With the LockOutRealm as currently written, no. If you extend it and write some custom code, yes. I'd think through the risks very carefully before you go down this road. Do the benefits to the users out-weight the additional security risks this would create? Mark On Mon, Aug 24, 2015 at 7:31 PM, Christopher Schultz ch...@christopherschultz.net wrote: Sreyan, On 8/23/15 2:54 PM, Sreyan Chakravarty wrote: I am confused with the functioning of LockOutRealms in Tomcat. My questions are as follows-: 1. Say user at IP 10.10.10.1 has reached the maximum number of invalid login attempts and is locked out. Now say a user from 10.10.10.2 attempts to login, will Tomcat stop him too since he is trying to login for the first time ? If not then how does Tomcat keep track of users that are locked out ? Via there IP's ? If you look at the code [1], you'll see that users are identified by username (or identifier) and no other factors. So, if you get locked-out from 10.10.10.1, you will also be locked-out from 10.10.10.2. However, the lock-out information is not shared amongst cluster members, so the LockOutRealm really only protects a single member of a cluster. If you need proper user-locking, you'll want to mark the user as locked-out in a database or something. You could do that by extending LockOutRealm and taking some other action (such as marking a user as locked in a db) after the registerAuthFailure method completes. 2. When a user is locked out what message is displayed ? Can I display a custom HTML page when a user has been locked out ? In other words how much control do I have over the lock out process and what error messages are shown ? It depends upon the type of authenticator you are using. If you use the BasicAuthenticator or DigestAuthenticator, you'll get a 401 response, and you can customize what page gets returned with a 401. If you use a FormAuthenticator, you can customize the form-error-page. If you are using an x509Authenticator, you cannot customize anything since the failure occurs at the SSL handshake level. In any case, there does not appear to be a way to tell that the user failed due to too-many-authentication-failures. You could request such as feature, but I would personally think nobody would want to implement it... you don't want to leak-out any information about the authentication process if you don't have to. Failed login = failed login, without further clarification. For a truly secure system, the LockOutRealm should also probably waste some time when a locked-out user is found, to simulate the amount of time it takes to properly-authenticate the user and then fail. Hope that helps, -chris [1] http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/realm /LockOutRealm.java?view=markup - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Webapp killing entire Tomcat process
I am running TC 8.0.24. It's been stable ever since I installed it. I have been making changes/enhancements to a web app that has been in production for many years. I have now encountered a situation when I request a certain page, the entire Tomcat process dies. Literally, the Windows service is stopped. There are no errors in any of the Tomcat log files. It's like I went to the task manager and killed the process from there. Fortunately it's on a development machine. But I've got to figure this out before I put it on a production machine. I have been developing web apps for over 15 years. I've obviously had lots of bugs in my code over the years. But I've never encountered a situation where a coding problem caused the entire web app server to die. I'm am pretty much certain that it's something I'm doing in my code to cause it. But in my opinion, no matter what happens in the code, TC shouldn't completely die, correct? So it looks like my bad code has possibly exposed a vulnerability in TC. it's very frustrating and just about impossible to debug when every time I call the page that has the problem, I then have to wait 3-4 minutes after restarting the TC service for it to come back up before I can do anything again. I'm pretty much relegated to table-top visual debug of the code and hope I accidentally see what's wrong. Difficult process at best. I feel like I'm shooting blind. I guess my question is, do you have any suggestions for anything my code might do that could kill the process? At least it might give me a start at what to look for. Thanks. Jerry - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Webapp killing entire Tomcat process
From: Jerry Malcolm [mailto:techst...@malcolms.com] Subject: Webapp killing entire Tomcat process But in my opinion, no matter what happens in the code, TC shouldn't completely die, correct? Nope, it's all one process, and any thread can take it out. Running with a security manager reduces the chance, but doesn't preclude it. Simple silliness such as calling System.exit() will also stop everything. I guess my question is, do you have any suggestions for anything my code might do that could kill the process? At least it might give me a start at what to look for. The first step is to stop running Tomcat as a service, and instead start it from a command prompt using the startup.bat script. You can also attach a debugger this way and watch what's going on, set breakpoints, etc. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Embedded Tomcat 7.0.59 Some vhost are not get Started Properly
Hi, I'm having an intermittent issue relate to tomcat vhost. I'm using embedded tomcat version 7.0.59 and I have my own deployers as well. In some of my virtualhosts apps are get deployed after the server get startup. This happens only in some vhosts (not all vhosts) The actual issue is that I'm adding webapp related info while the deployment. But since vhost is in the NEW state in problematic situations, app context is null. Therefore I can't get the required info through the context. When the issue occur, in the debug mode I can observe that problematic vhost listed after the localhost. But in other cases vhosts are listed prior to the localhost. Can someone put some light to this issue or can someone point me the location where tomcat read the conf/server.xml and get the list of vhost defined in it? Thanks Best Regards /Thusitha --
