Re: multi-tenant web app
On 18.04.2013, at 15:37, Jeffrey Janner jeffrey.jan...@polydyne.com wrote: Here's a real world example of doing this, by JFRog regarding their Artifactory SAAS. Spoiler: the crucial point is putting as many dependencies as possible into the shared classloader (where possible is not as easy as it sounds: http://www.youtube.com/watch?v=tE3eo0CuQCc Rainer Rainer, That's a very long video to sit through, but it looks interesting. Any chance someone's summarized it somewhere? It was a JavaOne session, don't know if the slides are available for public. The interesting part w.r.t this thread starts at about 18:00 in the video. Before that, the discuss multi tenancy and SAAS in general and why they chose the strategy of one web app per tenant. Summary of the core part is: in-depth review every used library for any kind of shared state: * static references in the classes * specifically global (static) registries * caches * thread pools * loggers Work with the developers to remove them or run own forks if that doesn't work out. And review again on new releases. They show some specific examples in libraries they use. Later (from around 35:00) they discuss how this approach changed their development and release process, and the last minutes are QA (don't remember if that was relevant). Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 7.0 spring web applcaiton context - Fedora 17
-Original Message- From: Mark Eggers [mailto:its_toas...@yahoo.com] Sent: Friday, April 19, 2013 12:43 AM To: Tomcat Users List Subject: Re: Tomcat 7.0 spring web applcaiton context - Fedora 17 On 4/18/2013 8:20 PM, Khurram Raza wrote: -Original Message- From: Mark Eggers [mailto:its_toas...@yahoo.com] Sent: Thursday, April 18, 2013 9:55 PM To: users@tomcat.apache.org Subject: Re: Tomcat 7.0 spring web applcaiton context - Fedora 17 On 4/18/2013 6:35 PM, Khurram Raza wrote: Hi, After spending days I am writing my problem on this forum. The problem is when I undeploy a webapp or shutdown tomcat, spring WebApplicationContext is closed and spring singleton beans destroyed before webapp Servlet's destroy() method is called. This leads me to 'java.lang.IllegalStateException' in Servlet's destroy() method where I am cleaning my resources and destroying dynamically created spring beans and datasources. This happens with tomcat 7.0.39 only on Linux (fedora 17) platform. On windows this works perfectly fine on tomcat 7.0.39. I have also tried my webapp on tomcat-7.0.29 tomcat 7.0.25 on linux but the problem persists. I have tried same webapp on tomcat-7.0.29 tomcat-7.0.23 on windows and this work fine without any problem. So I am not sure why it breaks in Linux environment. Here is the log snippet generated on both Linux and Windows: Windows (webapp log snippet) ... 2013-04-14 20:33:16,510 INFO [localhost-startStop-2] com.mycompany.servlet.DSServlet - DSServlet|destroy() 2013-04-14 20:33:16,510 INFO [localhost-startStop-2] com.mycompany.servlet.DSServlet - Releasing resources... 2013-04-14 20:33:16,510 DEBUG [localhost-startStop-2] com.mycompany.servlet.DSServlet - Spring application context: WebApplicationContext for namespace 'contoller-servlet': startup date [Sun Apr 14 20:32:53 EDT 2013]; root of context hierarchy 2013-04-14 20:33:16,510 DEBUG [localhost-startStop-2] com.mycompany.servlet.DSServlet - Obtaining 'jdbc_rdb' beans of type DSBean from the spring application context... 2013-04-14 20:33:16,510 DEBUG [localhost-startStop-2] com.mycompany.servlet.DSServlet - 'jdbc_rdb' beans obtained from the spring application context... 2013-04-14 20:33:16,510 DEBUG [localhost-startStop-2] com.mycompany.servlet.DSServlet - 'jdbc_rdb' beanName: jdbc_rdb_127.0.0.1 2013-04-14 20:33:16,947 INFO [localhost-startStop-2] org.springframework.context.support.AbstractApplicationContext - Closing WebApplicationContext for namespace 'contoller-servlet': startup date [Sun Apr 14 20:32:53 EDT 2013]; root of context hierarchy 2013-04-14 20:33:16,947 DEBUG [localhost-startStop-2] org.springframework.beans.factory.support.AbstractBeanFactory - Returning cached instance of singleton bean 'lifecycleProcessor' 2013-04-14 20:33:16,947 INFO [localhost-startStop-2] org.springframework.beans.factory.support.DefaultSingletonBeanRegistr y - Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@ 2 4e 4af4d: defining beans [springApplicationContext,/result.html,org.springframework.web.servle t .v iew.InternalResourceViewResolver#0]; root of factory hierarchy Linux (webapp log snippet) ... 2013-04-13 23:41:08,532 INFO [localhost-startStop-2] org.springframework.context.support.AbstractApplicationContext - Closing WebApplicationContext for namespace 'controller-servlet': startup date [Sat Apr 13 23:39:28 EDT 2013]; root of context hierarchy 2013-04-13 23:41:08,535 DEBUG [localhost-startStop-2] org.springframework.beans.factory.support.AbstractBeanFactory - Returning cached instance of singleton bean 'lifecycleProcessor' 2013-04-13 23:41:08,536 INFO [localhost-startStop-2] org.springframework.beans.factory.support.DefaultSingletonBeanRegistr y - Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@ 2 43 84979: defining beans [springApplicationContext,/result.html,org.springframework.web.servle t .v iew.InternalResourceViewResolver#0,jdbc_rdb_127.0.0.1,jdbc_rdb_192.16 8 .0 .31]; root of factory hierarchy 2013-04-13 23:41:08,537 INFO [localhost-startStop-2] com.mycompany.servlet.DSServlet - - DSServlet|destroy() 2013-04-13 23:41:08,544 INFO [localhost-startStop-2] com.mycompany.servlet.DSServlet - - Releasing resources... 2013-04-13 23:41:08,545 DEBUG [localhost-startStop-2] com.mycompany.servlet.DSServlet - - Spring application context: WebApplicationContext for namespace 'controller-servlet': startup date [Sat Apr 13 23:39:28 EDT 2013]; root of context hierarchy 2013-04-13 23:41:08,546 DEBUG [localhost-startStop-2] com.mycompany.servlet.DSServlet - - Obtaining 'jdbc_rdb' beans of type DSBean from the spring application context... 2013-04-13 23:41:08,577 ERROR [localhost-startStop-2] com.mycompany.servlet.DSServlet - Unable to releaase resources.
Re: Tomcat access log reveals hack attempt: HEAD /manager/html HTTP/1.0 404
On Thu, Apr 18, 2013 at 12:26 PM, André Warnier a...@ice-sa.com wrote:
My contention is that this would be self-defeating for the bots.
91.121.172.164 - - [03/Apr/2013:08:19:50 +0200] GET /robots.txt HTTP/1.1
404 360 - Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)
I definitely saw this in my local access log last night. I was working
with someone's test-case that they sent me, and I stumbled on the 404 error
(see below) in my browser, which clearly shows that this is a tomcat/tomee
server. do the bots read the 404 error HTTP response and check if the
response includes the string lowercase('tomcat') ?
HTTP Status 404 - /prova_fileupload_primefaces/
type Status report
message /prova_fileupload_primefaces/
description The requested resource is not available.
Apache Tomcat (TomEE)/7.0.39
---
it really showed up like this, below; i copied the text to text editor and
copied the text above.
HTTP Status 404 - /prova_fileupload_primefaces/
--
*type* Status report
*message* */prova_fileupload_primefaces/*
*description* *The requested resource is not available.*
--
Apache Tomcat (TomEE)/7.0.39
Re: Tomcat access log reveals hack attempt: HEAD /manager/html HTTP/1.0 404
On Wed, Apr 17, 2013 at 01:45:22PM -0400, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 4/17/13 1:27 PM, André Warnier wrote: Leo Donahue - RDSA IT wrote: -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: Tomcat access log reveals hack attempt: HEAD /manager/html HTTP/1.0 404 That's the idea. That is one reason why I brought this discussion here : to check if, if the default factory setting was for example 1000 ms delay for each 404 answer, could anyone think of a severe detrimental side-effect ? What if I send 10,000 requests to your server for some file that is not there? Then you will just have to wait 10,000+ seconds in total before you get all your corresponding 404 responses. Which is exactly the point. Sounds like a DOS to me. What you really want to do is detect an attacker (or annoying client) and block them without having to use your own resources. Maintaining a socket connection for an extra second you don't otherwise have to do is using a resource, even if the CPU is entirely idle, and even if you can return the request-processing thread to the thread-pool before you wait that 1 second to respond. Good advice in general, but what you want to do depends on what you intend to accomplish. If your objective is to carry on with legitimate business without too much interference from the bots, then the thing to do is to detect bots and stop listening to them. I think that André's argument is that we might prefer a different objective: to spend (a reasonable amount of) resources to harm bot performance so that people stop deploying the nasty things. This is worth pondering. It fits nicely with the view that there are two classes of threats: those properly dealt with, and those still alive. The problem with active resistance is, of course, that when the bad guys stop deploying bots they'll start doing something else. To be effective for more than a moment, we need to surround all the enemy's tactical options. At that point a smart enemy will give up and go home, while a stupid (or desperate) one will come on and be destroyed. Either way, you win. But this is very hard to arrange. So we have to consider what going active will cost, and how the enemy's behavior will change. The reward is still there for him if he can grasp it. What's the next soft spot, and can we defend or harden it? Can we afford to win the bot battle, or is it better to just shrug them off? -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. signature.asc Description: Digital signature
Re: Tomcat access log reveals hack attempt: HEAD /manager/html HTTP/1.0 404
On Wed, Apr 17, 2013 at 01:24:04PM -0500, Caldarale, Charles R wrote: From: Leo Donahue - RDSA IT [mailto:leodona...@mail.maricopa.gov] Subject: RE: Tomcat access log reveals hack attempt: HEAD /manager/html HTTP/1.0 404 So you are saying it could be possible to know in advance that certain requests are for repeated requests of nothing or being made by a bot, versus regular legitimate requests, in order to move those bot requests off to another thread? Nothing of the sort. You simply put each 404 response on queue, and have an existing timer thread send it out when the appropriate delay has been achieved. No threads are tied up during the delaying action. However, sockets *are* tied up. We don't get this benefit for free; it costs both kernel and application memory. Even if the limits on these are infinitely adjustable, we might not want to adjust them that high because they are doing another job for us. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. signature.asc Description: Digital signature
Re: Access-log ordering
On 18.04.2013 23:58, Christopher Schultz wrote:
Mark is of course right. Adding some info here concerning your log format:
We are using the following format string:
%a %t quot;%rquot; %s %D
The value of %t is the interesting one, of course, but it's
resolution is only in seconds, and we are seeing an access log file
like this:
127.0.0.1 [18/Apr/2013:16:19:08 -0400] POST /request/B HTTP/1.1 200 108
127.0.0.1 [18/Apr/2013:16:19:08 -0400] POST /request/A HTTP/1.1 200 263
In TC 7 you can log start time and end time and also milliseconds:
%{begin}t %{begin:msec_frac}t %{end}t %{end:msec_frac}t
or (maybe a bit slower but formatted more nicely)
%{begin:dd/MMM/:HH:mm:ss.SSS Z}t %{end:dd/MMM/:HH:mm:ss.SSS Z}t
The %{begin:msec}t and %{end:msec}t can also be useful. They are
milliseconds since the epoch, so not nicely readable for humans, but
nice for doing calculations.
AFAIR times are consistent if you use multiple formatting tokens, to te
time for begin and end is only taken once and then the various formats
use those two time values consistently.
The end: prefix is the default, so it can be ommitted.
Regards,
Rainer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: security-role-ref doesn't work
What version are you using? Mine doesn't contain this attribute pair at all... security-role-ref /security-role-ref -Original Message- From: Jakub 1983 [mailto:jjaku...@gmail.com] Sent: Thursday, April 18, 2013 8:51 PM To: Tomcat Users List Subject: security-role-ref doesn't work my tomcat users: role rolename=tomcat/ role rolename=role1/ role rolename=manager-gui/ role rolename=admin/ user username=tomcat password=tomcat roles=tomcat,manager-gui,admin/ user username=both password=tomcat roles=tomcat,role1/ user username=role1 password=tomcat roles=role1/ following code fails: security-constraint web-resource-collection web-resource-nameSample Application/web-resource-name descriptionRequire users to authenticate/description url-pattern*.jsp/url-pattern http-methodPOST/http-method http-methodGET/http-method /web-resource-collection auth-constraint role-nameadminLocal/role-name /auth-constraint user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint security-role role-nameadminLocal/role-name /security-role security-role-ref role-nameadmin/role-name role-linkadminLocal/role-link /security-role-ref if I change security-role.role-name to admin, and in auth-constraint.role-name also to admin, than I can login, but why doesnt' it work with security-role-ref ? regards Jakub - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: security-role-ref doesn't work
On 19/04/2013 21:37, Propes, Barry L wrote: What version are you using? Mine doesn't contain this attribute pair at all... security-role-ref /security-role-ref The version being used is irrelevant. security-role-ref is only valid inside a servlet element. There might still be a bug here - I'm currently looking at the source to check - but it isn't the bug the OP thinks they have found. Mark -Original Message- From: Jakub 1983 [mailto:jjaku...@gmail.com] Sent: Thursday, April 18, 2013 8:51 PM To: Tomcat Users List Subject: security-role-ref doesn't work my tomcat users: role rolename=tomcat/ role rolename=role1/ role rolename=manager-gui/ role rolename=admin/ user username=tomcat password=tomcat roles=tomcat,manager-gui,admin/ user username=both password=tomcat roles=tomcat,role1/ user username=role1 password=tomcat roles=role1/ following code fails: security-constraint web-resource-collection web-resource-nameSample Application/web-resource-name descriptionRequire users to authenticate/description url-pattern*.jsp/url-pattern http-methodPOST/http-method http-methodGET/http-method /web-resource-collection auth-constraint role-nameadminLocal/role-name /auth-constraint user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint security-role role-nameadminLocal/role-name /security-role security-role-ref role-nameadmin/role-name role-linkadminLocal/role-link /security-role-ref if I change security-role.role-name to admin, and in auth-constraint.role-name also to admin, than I can login, but why doesnt' it work with security-role-ref ? regards Jakub - 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: security-role-ref doesn't work
On 19/04/2013 21:47, Mark Thomas wrote: On 19/04/2013 21:37, Propes, Barry L wrote: What version are you using? Mine doesn't contain this attribute pair at all... security-role-ref /security-role-ref The version being used is irrelevant. security-role-ref is only valid inside a servlet element. There might still be a bug here - I'm currently looking at the source to check - but it isn't the bug the OP thinks they have found. Digging in to this Tomcat's behaviour is specification compliant. security-role-ref are only intended to work with a specific Servlet and only with calls to isUserInRole(). However, that means there are various places where it would be helpful to do a role mapping where it is not currently possible. I have started a discussion on the dev list about how to handle this. It will probably move to the Servlet EG unless I have missed something obvious. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 7.0 spring web applcaiton context - Fedora 17
Hi Mark, I recently noticed that I cannot use 'ServletContextListener' in my webapp as you can see below in web.xml, load-on-startup for DispatcherServlet is 1 and DSServlet is 2. I need spring application context in DSServlet whish is why I am creating data sources after spring application context is initialized, so I cannot simply use 'ServletContextListner'. Any other thoughts or ideas ? Thanks. -Original Message- From: Mark Eggers [mailto:its_toas...@yahoo.com] Sent: Fri 4/19/2013 12:42 AM To: Tomcat Users List Subject: Re: Tomcat 7.0 spring web applcaiton context - Fedora 17 On 4/18/2013 8:20 PM, Khurram Raza wrote: -Original Message- From: Mark Eggers [mailto:its_toas...@yahoo.com] Sent: Thursday, April 18, 2013 9:55 PM To: users@tomcat.apache.org Subject: Re: Tomcat 7.0 spring web applcaiton context - Fedora 17 On 4/18/2013 6:35 PM, Khurram Raza wrote: Hi, After spending days I am writing my problem on this forum. The problem is when I undeploy a webapp or shutdown tomcat, spring WebApplicationContext is closed and spring singleton beans destroyed before webapp Servlet's destroy() method is called. This leads me to 'java.lang.IllegalStateException' in Servlet's destroy() method where I am cleaning my resources and destroying dynamically created spring beans and datasources. This happens with tomcat 7.0.39 only on Linux (fedora 17) platform. On windows this works perfectly fine on tomcat 7.0.39. I have also tried my webapp on tomcat-7.0.29 tomcat 7.0.25 on linux but the problem persists. I have tried same webapp on tomcat-7.0.29 tomcat-7.0.23 on windows and this work fine without any problem. So I am not sure why it breaks in Linux environment. Here is the log snippet generated on both Linux and Windows: Windows (webapp log snippet) ... 2013-04-14 20:33:16,510 INFO [localhost-startStop-2] com.mycompany.servlet.DSServlet - DSServlet|destroy() 2013-04-14 20:33:16,510 INFO [localhost-startStop-2] com.mycompany.servlet.DSServlet - Releasing resources... 2013-04-14 20:33:16,510 DEBUG [localhost-startStop-2] com.mycompany.servlet.DSServlet - Spring application context: WebApplicationContext for namespace 'contoller-servlet': startup date [Sun Apr 14 20:32:53 EDT 2013]; root of context hierarchy 2013-04-14 20:33:16,510 DEBUG [localhost-startStop-2] com.mycompany.servlet.DSServlet - Obtaining 'jdbc_rdb' beans of type DSBean from the spring application context... 2013-04-14 20:33:16,510 DEBUG [localhost-startStop-2] com.mycompany.servlet.DSServlet - 'jdbc_rdb' beans obtained from the spring application context... 2013-04-14 20:33:16,510 DEBUG [localhost-startStop-2] com.mycompany.servlet.DSServlet - 'jdbc_rdb' beanName: jdbc_rdb_127.0.0.1 2013-04-14 20:33:16,947 INFO [localhost-startStop-2] org.springframework.context.support.AbstractApplicationContext - Closing WebApplicationContext for namespace 'contoller-servlet': startup date [Sun Apr 14 20:32:53 EDT 2013]; root of context hierarchy 2013-04-14 20:33:16,947 DEBUG [localhost-startStop-2] org.springframework.beans.factory.support.AbstractBeanFactory - Returning cached instance of singleton bean 'lifecycleProcessor' 2013-04-14 20:33:16,947 INFO [localhost-startStop-2] org.springframework.beans.factory.support.DefaultSingletonBeanRegistry - Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@2 4e 4af4d: defining beans [springApplicationContext,/result.html,org.springframework.web.servlet .v iew.InternalResourceViewResolver#0]; root of factory hierarchy Linux (webapp log snippet) ... 2013-04-13 23:41:08,532 INFO [localhost-startStop-2] org.springframework.context.support.AbstractApplicationContext - Closing WebApplicationContext for namespace 'controller-servlet': startup date [Sat Apr 13 23:39:28 EDT 2013]; root of context hierarchy 2013-04-13 23:41:08,535 DEBUG [localhost-startStop-2] org.springframework.beans.factory.support.AbstractBeanFactory - Returning cached instance of singleton bean 'lifecycleProcessor' 2013-04-13 23:41:08,536 INFO [localhost-startStop-2] org.springframework.beans.factory.support.DefaultSingletonBeanRegistry - Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@2 43 84979: defining beans [springApplicationContext,/result.html,org.springframework.web.servlet .v iew.InternalResourceViewResolver#0,jdbc_rdb_127.0.0.1,jdbc_rdb_192.168 .0 .31]; root of factory hierarchy 2013-04-13 23:41:08,537 INFO [localhost-startStop-2] com.mycompany.servlet.DSServlet - - DSServlet|destroy() 2013-04-13 23:41:08,544 INFO [localhost-startStop-2] com.mycompany.servlet.DSServlet - - Releasing resources... 2013-04-13 23:41:08,545 DEBUG [localhost-startStop-2] com.mycompany.servlet.DSServlet - - Spring application context: WebApplicationContext for namespace 'controller-servlet': startup date [Sat Apr 13 23:39:28 EDT
