Re: Custom Connector class
2015-12-16 14:11 GMT+01:00 Christopher Schultz <ch...@christopherschultz.net >: > Roel, > > On 12/16/15 4:56 AM, Roel Storms wrote: > > It should, if you implement parseParameter and all these other methods > > before getStream is called, in the wrapper itself. But since you haven't > > implemented HttpServletRequest.getParameter* in you example Filter, you > > will end up using Request.getParameter* which will not use > > the HttpServletRequest.getStream since it has no knowledge of this > wrapper. > > The wrapped object never uses the wrapped implementation of methods since > > it has no knowledge of the wrapping. > > I'm sorry I wasn't clear, but I was suggesting that you use my Filter as > inspiration for writing a Valve. The Valve wouldn't wrap > HttpServletRequest. Instead, it would wrap Tomcat's coyote Request > class, which *is* used to fetch the input stream (or reader). > > -chris > > Ok, first of all, sorry for the Top posting, it's a nasty habit that comes with using the Gmail webclient. Secondly, If it would wrap the Request without intercepting getParameter() then a call to HttpServletRequest.getParameter would delegate to the wrapped Request which in my case, would be a wrapped version of the original Request. But since I am not intercepting getParameter, it will result in Request.getParameter being called which leads me back to the previous e-mail. As long as I am not implementing all the methods that eventually call getStream, getInputStream and getReader, I won't get the desired behavior. I agree that your filter could be an inspiration for a Valve but it would have to cover all the methods mentioned in the previous e-mail and it wouldn't suffice to . I have several sequence diagrams explaining what I mean. https://www.dropbox.com/s/ebjs6ixpyqs742n/getParameter.jpg?dl=0 https://www.dropbox.com/s/c9sj00nwqcs9l7y/getParameter2.jpg?dl=0 The first diagram describes what happens if you intercept getReader, getInputStream and getStream but don't intercept getParameter. The second diagram shows the interaction as it's supposed to happen but requires the wrapper implementing all these methods without delegating them to the wrapped Request. The other alternative is extending Request with an implementation of getStream without implementations for getParameter, parseParameters or readPostBody. This would result in the following (if I use dynamic binding correctly): https://www.dropbox.com/s/0a3k9qqzonicjvf/getParameter3.jpg?dl=0 I will also look into what Konstantin suggested. > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Custom Connector class
It should, if you implement parseParameter and all these other methods before getStream is called, in the wrapper itself. But since you haven't implemented HttpServletRequest.getParameter* in you example Filter, you will end up using Request.getParameter* which will not use the HttpServletRequest.getStream since it has no knowledge of this wrapper. The wrapped object never uses the wrapped implementation of methods since it has no knowledge of the wrapping. 2015-12-16 4:06 GMT+01:00 Christopher Schultz <ch...@christopherschultz.net> : > Roel, > > On 12/15/15 5:13 PM, Roel Storms wrote: > > I don't believe that your suggestion works, but correct me if I'm wrong. > > You aren't overwriting the getInputStream or getReader method. You are > > wrapping them, which is a big difference. Since the internal > > Request#parseParameter() won't use your wrapped version of the method but > > rather uses it's own version which won't work since you've already called > > getInputStream or getReader. > > My code is a Filter which executes too late. If you implement this as a > Valve, you ought to be able to capture the input data (whether it is a > stream or a reader) and re-play it to any code later in the valve > pipeline. I must admit I haven't read all the Connector/Request code so > I don't know for sure if a Valve wrapping the (non-spec-defined) request > object will be sufficient. > > > In your case it works since you aren't calling getParameter(). You're > > implementation works as long as you restrict your application to using > > getReader or getInputStream. Again, correct me if I'm wrong. Calling > > HttpRequestRecorderWrapper.getParameter() in the web application, should > > mess up your wrapper since it doesn't intercepts this method call and > will > > invoke the Request.getParameter() which will call Request.getStream() and > > not HttpRequestRecorderWrapper.getStream() as you're implementation > > requires. > > Servlet code calling HttpServletRequest.getParameter* should end up > calling getInputStream on the wrapper. If that's not what Tomcat does, > I'd consider it a bug because Filters are supposed to be able to replace > request entities and things like that. > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Custom Connector class
I don't believe that your suggestion works, but correct me if I'm wrong. You aren't overwriting the getInputStream or getReader method. You are wrapping them, which is a big difference. Since the internal Request#parseParameter() won't use your wrapped version of the method but rather uses it's own version which won't work since you've already called getInputStream or getReader. In your case it works since you aren't calling getParameter(). You're implementation works as long as you restrict your application to using getReader or getInputStream. Again, correct me if I'm wrong. Calling HttpRequestRecorderWrapper.getParameter() in the web application, should mess up your wrapper since it doesn't intercepts this method call and will invoke the Request.getParameter() which will call Request.getStream() and not HttpRequestRecorderWrapper.getStream() as you're implementation requires. Overwriting the getStream, getInputStream and getReader methods would indeed solve the problem, but the problem is that you aren't overwriting the method. By the way, I believe that parseParameter uses getStream. But again, a wrapper does not overwrite the Request.getInputStream or getReader. I made this same mistake when trying a similar solution to yours. So in order for getParameter to work in a wrapper, you need to wrap parseParameter and implement all the other methods that depend on getStream, getInputStream or getReader, in the wrapper itself. I did the research and I would have to rewrite more then you suggest (getReader(), getStream(), getInputStream(), parseParameter(), readPostBody(), readChunkedPostBody, getParameterMap, getParameterNames, getParameterValues) and maybe it's not even possible since some fields that are used by these implementations are protected and have been set before the Valve is encountered. These fields don't always have getters and you might not be able to reproduce the behavior of getParameter (or any other method) in a wrapper due to this fact. This last part is just an assumption. I haven't validated that this last issue, indeed renders an implementation in a wrapper impossible, but it makes it fairly difficult and error prone. By the way, this is not my only reason for diving into Tomcat. I need modification to the Manager as well and since it is just a proof of concept, I am not worried about maintaining this code, which would indeed be almost impossible. Thanks for the advice on the size of requests. I'm still pondering on that issue. Roel 2015-12-15 2:10 GMT+01:00 Christopher Schultz <ch...@christopherschultz.net> : > Roel, > > On 12/12/15 11:17 AM, Roel Storms wrote: > > I believe that this is not entirely what I need. As far as I understand > the > > code it will detect if getInputStream or getReader has been called by the > > servlet application. Depending on the usingReader boolean that was set > as a > > result, it will either use _inputReaderBuffer or _inputStreamBuffer to > > fetch the body. > > > > In my case I need to retrieve the body in advance and still allow the web > > application to call either method, getInputStream, getReader, > getParameter. > > If I choose to call getInputStream in my Valve to retrieve the body then > > the web application will be restricted to using getInputStream. If I > choose > > getReader then the web application will be restricted to using getReader. > > If a web application would use ServletRequest.getParameter the > > documentation says the following: > > > > "If the parameter data was sent in the request body, such as occurs with > an > > HTTP POST request, then reading the body directly via getInputStream() > > < > https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletRequest.html#getInputStream() > > > > or getReader() > > < > https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletRequest.html#getReader() > > > > can > > interfere with the execution of this method." > > > > According to my understanding of the original Tomcat request code, > > Request.getParam depends on Request.parseParameters which in turn uses > > Request.readPostBody that uses Request.getStream to obtain the data. > > getStream also fetches the inputStream of a request so I believe it won't > > work in combination with a call to getReader. > > > > Since your wrapper is not overwriting any method like getParam > > (getParameterNames, getParameterValues, getParameterMap) I believe these > > methods will still behave incorrectly when called by the target > application. > > > > I could indeed build a wrapper that would overwrite getStream, getReader, > > getInputStream, getParam, getParameterNames, etc. But then I would be > > generating a lot of duplicate
Re: Custom Connector class
Chris, I believe that this is not entirely what I need. As far as I understand the code it will detect if getInputStream or getReader has been called by the servlet application. Depending on the usingReader boolean that was set as a result, it will either use _inputReaderBuffer or _inputStreamBuffer to fetch the body. In my case I need to retrieve the body in advance and still allow the web application to call either method, getInputStream, getReader, getParameter. If I choose to call getInputStream in my Valve to retrieve the body then the web application will be restricted to using getInputStream. If I choose getReader then the web application will be restricted to using getReader. If a web application would use ServletRequest.getParameter the documentation says the following: "If the parameter data was sent in the request body, such as occurs with an HTTP POST request, then reading the body directly via getInputStream() <https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletRequest.html#getInputStream()> or getReader() <https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletRequest.html#getReader()> can interfere with the execution of this method." According to my understanding of the original Tomcat request code, Request.getParam depends on Request.parseParameters which in turn uses Request.readPostBody that uses Request.getStream to obtain the data. getStream also fetches the inputStream of a request so I believe it won't work in combination with a call to getReader. Since your wrapper is not overwriting any method like getParam (getParameterNames, getParameterValues, getParameterMap) I believe these methods will still behave incorrectly when called by the target application. I could indeed build a wrapper that would overwrite getStream, getReader, getInputStream, getParam, getParameterNames, etc. But then I would be generating a lot of duplicate code. Since my implementation is purely experimental I don't think it's such big of a problem to modify Tomcat internals (the Connector class). Roel 2015-12-09 18:06 GMT+01:00 Christopher Schultz <ch...@christopherschultz.net >: > Roel, > > On 12/9/15 8:03 AM, Roel Storms wrote: > > The real requirement is being able to process the body of a request in a > > Valve without restricting the servlet to call request.getInputStream, > > getReader and getStream. I have tried by wrapping the request but some > > behavior can't be masked. It is also much more simple to implement by > just > > extending the Request class and using this in Connector.createRequest(). > > > > So the actual requirement is a Valve wanting to process the body but > still > > allowing the target application to call whatever processing method they > > chose. When the Valve would chose to process the body by calling > > Request.getInputStream(). The servlet wouldn't be able to call getReader > or > > getParam anymore. I would like my Valve to be transparent in that sense. > > What you want to do can be done with a Valve as long as you don't mind a > bit of typing. > > See this thread where I built pretty much exactly what you're requesting: > http://tomcat.markmail.org/thread/fumpfuspt7a3nesz > > I implemented mine as a Filter, not as a Valve. > > There's no need to go writing your own Request implementation. > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Custom Connector class
The real requirement is being able to process the body of a request in a Valve without restricting the servlet to call request.getInputStream, getReader and getStream. I have tried by wrapping the request but some behavior can't be masked. It is also much more simple to implement by just extending the Request class and using this in Connector.createRequest(). So the actual requirement is a Valve wanting to process the body but still allowing the target application to call whatever processing method they chose. When the Valve would chose to process the body by calling Request.getInputStream(). The servlet wouldn't be able to call getReader or getParam anymore. I would like my Valve to be transparent in that sense. 2015-12-09 13:07 GMT+01:00 Konstantin Kolinko <knst.koli...@gmail.com>: > 2015-12-09 14:13 GMT+03:00 Roel Storms <roel.sto...@gmail.com>: > > Hello, > > > > In Tomcat 4.1 it used to be possible to specify a custom class for the > > Connector: https://tomcat.apache.org/tomcat-4.1-doc/config/coyote.html > > > > In the newest versions it's only possible to provide a custom Protocol. > > However I would like to modify the Request that is created by the > > Connector.createRequest() method. Is this no longer possible via > > configuration? > > > > > As a note: > If such a feature ever going to be implemented, the place to fix is > org.apache.catalina.startup.ConnectorCreateRule class. > > Instances of Connector are created via that rule, instead of a > standard class creation rule, and so (unlike other elements processed > by digester) className attribute does not work here. > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Custom Connector class
Hello, In Tomcat 4.1 it used to be possible to specify a custom class for the Connector: https://tomcat.apache.org/tomcat-4.1-doc/config/coyote.html In the newest versions it's only possible to provide a custom Protocol. However I would like to modify the Request that is created by the Connector.createRequest() method. Is this no longer possible via configuration? Kind regards, Roel Storms
Re: ServletRequest.getInputStream, getReader, getParameter.
The only way cookie based session management is secure, is when you apply a number of countermeasures: Correct flags, path and domain attributes, no un-trusted applications on subdomains (solved by origin cookies), ... You run it over TLS to withstand sniffers. There is no clean mechanism to share a session between domains. Again people have invented solutions. OWASP had quite some information on the subject: https://www.owasp.org/index.php/Session_Management_Cheat_Sheet Session management in Tomcat is secure because the developpers of tomcat have applied (almost) all of these countermeasures but not everyone is using middleware like Tomcat. If as you say there is no problem with session management, then why was 'Broken Authentication and Session Management' second on the list of the 10 Most Critical Web Application Security Risks according to OWASP? This is what SecSess is doing for you: http://randomoverload.org/wp-content/uploads/2015/09/2e36hF7158F31.jpg When I am in a hurry to get a website up and running and I have no resources to do so, security is going to be my last concern. If we can create a session management mechanism which outperforms current session management out of the box and allow an application developer to pick this option without any modification to his source code I think we could reduce the problem big time. I'm not claiming they aren't solved. I am claiming there is not A SOLUTION, but merely patches on an insecure mechanism. In theory everything should just run over TLS but for some reason that is not the case and for some reason there are still major problems with authentication and session management. I think we should look at the number of available solutions and try to improve it. I am not going to argue about something which clearly doesn't belong on this mailing list anymore. But I disagree with you on the fact that session management is fine the way it is. Thanks for the advice and I clearly have some technical stuff to work out. Roel 2015-11-24 19:15 GMT+01:00 Christopher Schultz <ch...@christopherschultz.net >: > Roel, > > On 11/24/15 10:43 AM, Roel Storms wrote: > > 2015-11-24 16:11 GMT+01:00 Christopher Schultz < > ch...@christopherschultz.net > >> : > > > >> Roel, > >> > >> On 11/24/15 9:44 AM, Roel Storms wrote: > >>> I am trying to protect the client from: > >>> > >>> Session fixation > >> > >> Tomcat already provides session-fixation protection when using URL-based > >> or cookie-based session-tracking. When authentication occurs, Tomcat > >> will change the session identifier, effectively mitigating session > >> fixation. > >> > >> I'm not saying that Tomcat is vulnerable if used correctly. I am saying > > that > > naive implementations using cookie based session management can be > > vulnerable. Tomcat and other middleware will indeed try to cover up > > these security issues. We want to change the basic shortcoming that an > SID > > acts as a bearer token. > > But you are saying that you want to replace bearer tokens (defined by > you as intractable) with a new kind of bearer token. I don't see you > having much luck without a lot of infrastructure. Since one of your > initial requirements was "minimal infrastructure", your proposal is > current indistinguishable from magic. > > >>> Session hijacking > >> > >> I'm interested in your plan for this that (a) is transparent to the > >> application, (b) is easy to implement on the server and (c) does not > >> require any changes to the client. > >> > > I have changed the client. I have a working implementation in Chrome > > that does everything except for body integrity checking. TLS also > > need both client and server side implementations. Cookies also have > > to be supported at the client side. > > So, this is something that the application doesn't have to know about, > but every other component in the works DOES need to have it? The list of > conflicting requirements here is really amusing to me. > > >>> Maybe I also want to check integrity of the response since otherwise an > >>> active MitM attack can still modify this. > >> > >> If you have solved the client -> server integrity, then server -> client > >> integrity ought to be trivial. > >> > > > > True, but I'm not sure I want to cover active MitM. If you want to > protect > > against that you should use TLS. I'm simply trying to replace the > > fundamental insecurity of SID. > > If you can change both client and server, then simply negotiate a secret > (during your "safe" session-establishment step, which you hav
Re: ServletRequest.getInputStream, getReader, getParameter.
It's to implement a new session mechanism that guarantees integrity of the requests sent in the session and also protect the session from attacks based on stealing or replacing the session identifier. This is a thesis I'm working on and this Tomcat valve should prove that migration from cookie base session management to this new session management can go without large modifications at client and server-side. That's why it is important to make it transparent to the user/developer. Performance is already going to be an issue in multiple places but I'll see what I can come up with. I am weighing of transparency, ease of migration, performance and security all the time. Checking at the Apache httpd level will make it harder to migrate to this new session management mechanism and has some other disadvantages. In theory i could do this session management in a proxy but this has it's own disadvantages. Session scope is an important aspect in it's security and scope is harder to get right in a proxy or in the httpd server since I want to limit scope to the web application context and maybe allow explicit session sharing between web applications. As you can see I still have a lot to do. If I need any more information I will not hesitate to ask. Thanks for all the info! 2015-11-23 23:01 GMT+01:00 André Warnier (tomcat) <a...@ice-sa.com>: > On 23.11.2015 21:14, Roel Storms wrote: > >> Ok, thank you for the clear response. I see the problem with file type >> elements. >> > > If you really have an overwhelming need to pre-check whole POST bodies > before passing them to a Tomcat application, you may want to think about > fronting your Tomcat server with an Apache httpd server. You could then do > the checking at the Apache httpd level, before forwarding the request to > Tomcat. And of course not forward it at all if the check fails. > Doing this at the front-end level would not "consume" the request body, as > it does when you do this under Tomcat. > All in all, you would still end up reading the request body twice. But > depending on your use case, it may be worth it. > > In your initial post below, you wrote "..some integrity checking on HTTP > requests (the details aren't important)..". > But if you want further help or recommendations, I believe that more > details about what exactly you are trying to achieve and/or check, would be > important. > After all, Tomcat is already making a fair amount of checking by default, > on any received HTTP request, before it will forward it to any > application. So it would be interesting to have an idea of which extra > checks you want to make. > > > > >> 2015-11-23 17:18 GMT+01:00 André Warnier (tomcat) <a...@ice-sa.com>: >> >> On 23.11.2015 16:31, Mark Thomas wrote: >>> >>> On 23/11/2015 14:30, Roel Storms wrote: >>>> >>>> Hello, >>>>> >>>>> I am working on a Valve that does some integrity checking on HTTP >>>>> requests >>>>> (the details aren't important) where I need this valve to have access >>>>> to >>>>> the HTTP request body as well. I used request.getInputStream to fetch >>>>> the >>>>> data. However when a web application makes use of my valve, the >>>>> getParameter method does not return the parameters submitted via POST >>>>> anymore. This is documented behavior according to the spec of >>>>> ServletRequest ( >>>>> >>>>> >>>>> https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletRequest.html#getInputStream() >>>>> ). >>>>> >>>>> I was wondering why it was designed this way, >>>>> >>>>> >>>> Given the potential size of a request body, streaming is the only viable >>>> option. >>>> >>>> since numerous complaints >>>> >>>>> have arisen from this behavior and some ugly workarounds have been >>>>> devised >>>>> which unfortunately stop working from Tomcat 7 (servlet 3.0): >>>>> >>>>> >>>>> >>>>> https://stackoverflow.com/questions/10210645/http-servlet-request-lose-params-from-post-body-after-read-it-once >>>>> >>>>> This shows how easily code like this could break. >>>>> >>>>> >>>> What that shows is the folks haven't thought through what they are >>>> trying to do. Consider the following: >>>> >>>> Tomcat provides request R. >>>> Filter reads request body using R.getInputStream(). >>>&
Re: ServletRequest.getInputStream, getReader, getParameter.
TLS will sign everything and therefor will not allow fine-grained integrity checking. Why do we want this? Middleboxes might alter some non-security sensitive information and I don't want to drop those requests. But I am looking into TLS already to see if I can use it for my purpose. We certainly don't want the full encryption or authentication that TLS can offer. No encryption since we don't want to interfere with caching and no authentication since setting up the certificates is often one of the reasons for small web apps not to use TLS. You have to get your certificate from an authority, keep it safe, install it and pay for it. We notice that adoption of TLS is not as great as we'd like it to be for securing cookie based session management so we need an alternative that will be adopted more easily and guarantee security of sessions better than plain cookie based session management. As a thesis it is an interesting subject to study although it's quite probable that the people too busy to use TLS will also be too busy to use our session management mechanism. Using TLS without certificates is only possible with the DH_Anon cyphersuite which is often disabled by clients and server. " The server MUST send a Certificate message whenever the agreed- upon key exchange method uses certificates for authentication (this includes all key exchange methods defined in this document except DH_anon)." RFC 5246 (TLS 1.2) " The following cipher suites are used for completely anonymous Diffie-Hellman communications in which neither party is authenticated. Note that this mode is vulnerable to man-in-the- middle attacks. Using this mode therefore is of limited use: These cipher suites MUST NOT be used by TLS 1.2 implementations unless the application layer has specifically requested to allow anonymous key exchange." RFC 5246 Also we want to support mixed content web apps without having the risk of being vulnerable to session hijacking. Some of these properties can be obtained by using SSL session identifier in Tomcat as your session mechanism. Again, I am still doing some research and maybe what I am doing is not worth it. 2015-11-24 11:36 GMT+01:00 Mark Thomas <ma...@apache.org>: > On 24/11/2015 10:12, Roel Storms wrote: > > It's to implement a new session mechanism that guarantees integrity of > the > > requests sent in the session and also protect the session from attacks > > based on stealing or replacing the session identifier. This is a thesis > I'm > > working on and this Tomcat valve should prove that migration from cookie > > base session management to this new session management can go without > large > > modifications at client and server-side. That's why it is important to > make > > it transparent to the user/developer. Performance is already going to be > an > > issue in multiple places but I'll see what I can come up with. > > > > I am weighing of transparency, ease of migration, performance and > security > > all the time. Checking at the Apache httpd level will make it harder to > > migrate to this new session management mechanism and has some other > > disadvantages. In theory i could do this session management in a proxy > but > > this has it's own disadvantages. Session scope is an important aspect in > > it's security and scope is harder to get right in a proxy or in the httpd > > server since I want to limit scope to the web application context and > maybe > > allow explicit session sharing between web applications. As you can see I > > still have a lot to do. If I need any more information I will not > hesitate > > to ask. Thanks for all the info! > > What does this get you over and above using TLS (which is rapidly > becoming a given due to HTTP/2) and configuring Tomcat to use the TLS > session ID as the HTTP session identifier? > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: ServletRequest.getInputStream, getReader, getParameter.
I am trying to protect the client from: Session fixation Session hijacking Assure that requests that are received in an established session can't be modified in transit (integrity of requests). Maybe I also want to check integrity of the response since otherwise an active MitM attack can still modify this. An attack could consists of an attacker modifying the action attribute of a form to send login data to the attacker instead of the web application. But this again looks a lot like TLS with DH_anon. Al we want is to replace the current session mechanism where the ID is a bearer token by a mechanism based on a shared secret (shared via DH). This will inhibit script based attacks that steal the SID and also eavesdropping attacks. It's not perfect but we also believe that if you have an active MitM, you have bigger problems than securing your session management. The perfect solution is still something including SSL/TLS (it's not cookie based since even over SSL cookies can be leaked if not set properly and we don't want a configuration mistake to become a security issue). I am not trying to protect from: An active MitM attack during session establishment Malware at either client or server-side 2015-11-24 15:19 GMT+01:00 Christopher Schultz <ch...@christopherschultz.net >: > Roel, > > On 11/24/15 5:12 AM, Roel Storms wrote: > > It's to implement a new session mechanism that guarantees integrity of > the > > requests sent in the session and also protect the session from attacks > > based on stealing or replacing the session identifier. This is a thesis > I'm > > working on and this Tomcat valve should prove that migration from cookie > > base session management to this new session management can go without > large > > modifications at client and server-side. That's why it is important to > make > > it transparent to the user/developer. Performance is already going to be > an > > issue in multiple places but I'll see what I can come up with. > > > > I am weighing of transparency, ease of migration, performance and > security > > all the time. Checking at the Apache httpd level will make it harder to > > migrate to this new session management mechanism and has some other > > disadvantages. In theory i could do this session management in a proxy > but > > this has it's own disadvantages. Session scope is an important aspect in > > it's security and scope is harder to get right in a proxy or in the httpd > > server since I want to limit scope to the web application context and > maybe > > allow explicit session sharing between web applications. As you can see I > > still have a lot to do. If I need any more information I will not > hesitate > > to ask. Thanks for all the info! > > Are you trying to protect the client and server from an evil proxy, or > are you trying to protect the server from an evil client? > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: ServletRequest.getInputStream, getReader, getParameter.
2015-11-24 16:11 GMT+01:00 Christopher Schultz <ch...@christopherschultz.net >: > Roel, > > On 11/24/15 9:44 AM, Roel Storms wrote: > > I am trying to protect the client from: > > > > Session fixation > > Tomcat already provides session-fixation protection when using URL-based > or cookie-based session-tracking. When authentication occurs, Tomcat > will change the session identifier, effectively mitigating session > fixation. > > I'm not saying that Tomcat is vulnerable if used correctly. I am saying that naive implementations using cookie based session management can be vulnerable. Tomcat and other middleware will indeed try to cover up these security issues. We want to change the basic shortcoming that an SID acts as a bearer token. There has been academic papers criticizing this bearer token pattern. https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final162.pdf > > Session hijacking > > I'm interested in your plan for this that (a) is transparent to the > application, (b) is easy to implement on the server and (c) does not > require any changes to the client. > > I have changed the client. I have a working implementation in Chrome that does everything except for body integrity checking. TLS also need both client and server side implementations. Cookies also have to be supported at the client side. > > Assure that requests that are received in an established session can't be > > modified in transit (integrity of requests). > > Without TLS or trusted code running on the client, I don't see a viable > solution. > See above. > > > Maybe I also want to check integrity of the response since otherwise an > > active MitM attack can still modify this. > > If you have solved the client -> server integrity, then server -> client > integrity ought to be trivial. > True, but I'm not sure I want to cover active MitM. If you want to protect against that you should use TLS. I'm simply trying to replace the fundamental insecurity of SID. > > > An attack could consists of an attacker modifying the action > > attribute of a form to send login data to the attacker instead of the > > web application. > > A reasonable attack scenario, especially with the attacker has a MitM > position. > > > But this again looks a lot like TLS with DH_anon. > > It does? Or do you mean even if TLS is used with anon-auth (i.e. ZERO > auth), the client isn't protected from MitM? Doing integrity checking on both request and response and doing this integrity check for almost the entire HTTP request/response looks a lot like TLS. > > > Al we want is to replace the current session mechanism > > where the ID is a bearer token by a mechanism based on a shared secret > > (shared via DH). > > How is this different from "standard" TLS-sessions (formal TLS sessions, > not Tomcat's session ids in cookies transmitted via TLS)? The difference is that TLS assures integrity of the entire packet. Which is not compatible with web infrastructure. Also TLS is often not deployed. Or even if it is deployed there is still mixed content being server. Our sessions would be applicable to both types of content. "To our knowledge, SecSess is the only session management mechanism explicitly designed to be compatible with currently deployed Web infrastructure, such as web caches." https://lirias.kuleuven.be/bitstream/123456789/503824/1/p2171-de_ryck.pdf I haven't validated this claim but my thesis builds upon this paper. > > > This will inhibit script based attacks that steal the SID > > and also eavesdropping attacks. It's not perfect but we also believe that > > if you have an active MitM, you have bigger problems than securing your > > session management. > > Of course. That doesn't make it an interesting scenario, though. > > > The perfect solution is still something including SSL/TLS (it's not > > cookie based since even over SSL cookies can be leaked if not set > > properly and we don't want a configuration mistake to become a > > security issue). > > Configuration mistakes can always result in vulnerabilities. The only > way to fail-safe would be to disallow all "unsafe" configurations, which > would make the software *quite* unusable. > Some configurations which are possible for cookies or tricks which are possible with url-rewriting aren't possible with a session management mechanism that was explicitly designed as a session management mechanism. Now the middleware is trying to shield this underlying complexity from application developers but it doesn't make the complexity disappear. Someone still takes care of it. In this case Tomcat does. We want a session mechanism that shield every middleware developpe
Re: ServletRequest.getInputStream, getReader, getParameter.
Ok, thank you for the clear response. I see the problem with file type elements. 2015-11-23 17:18 GMT+01:00 André Warnier (tomcat) <a...@ice-sa.com>: > On 23.11.2015 16:31, Mark Thomas wrote: > >> On 23/11/2015 14:30, Roel Storms wrote: >> >>> Hello, >>> >>> I am working on a Valve that does some integrity checking on HTTP >>> requests >>> (the details aren't important) where I need this valve to have access to >>> the HTTP request body as well. I used request.getInputStream to fetch the >>> data. However when a web application makes use of my valve, the >>> getParameter method does not return the parameters submitted via POST >>> anymore. This is documented behavior according to the spec of >>> ServletRequest ( >>> >>> https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletRequest.html#getInputStream() >>> ). >>> >>> I was wondering why it was designed this way, >>> >> >> Given the potential size of a request body, streaming is the only viable >> option. >> >> since numerous complaints >>> have arisen from this behavior and some ugly workarounds have been >>> devised >>> which unfortunately stop working from Tomcat 7 (servlet 3.0): >>> >>> >>> https://stackoverflow.com/questions/10210645/http-servlet-request-lose-params-from-post-body-after-read-it-once >>> >>> This shows how easily code like this could break. >>> >> >> What that shows is the folks haven't thought through what they are >> trying to do. Consider the following: >> >> Tomcat provides request R. >> Filter reads request body using R.getInputStream(). >> Filter caches request body. >> Filter wraps request R to provide R', over-riding getInputStream() to >> provide the cached body. >> Filter passes R' to the application. >> Application calls R'.getParameter() >> R'.getParameter() calls R.getParameter() >> >> Keep in mind at this point R has zero knowledge of R'. >> >> R calls getInputStream() to read request body but that InputStream has >> already been read. >> >> The problem is the wrapper, R'. Over-riding getInputStream() is not >> enough. It needs to over-ride every method that may access that >> InputStream. Which is non-trivial because it means re-implementing a lot >> of functionality the container would normally provide for you out of the >> box. >> >> Overwriting getInputStream to return a cached version doesn't work anymore >>> >> >> Nope. That never worked. See my explanation above. >> >> since the parameter attribute isn't populated by using getInputStream. How >>> exactly it is populated remains a mystery to me. Any advice on how to >>> solve >>> this properly? >>> >> >> Write a better wrapper. >> >> Performing an integrity check without getInputStream or getReader but with >>> getParameters, will not work if the data submitted is not in the expected >>> format. >>> >> >> See above. >> >> Mark >> >> > To emphasize a point made by Mark above : a POST body can potentially > contain one or more elements. So imagine a POST > which contains a 50 MB uploaded file. > You'd need to read it once (for your Valve) and cache it, then re-read the > cached version to parse it for parameters. That would have a serious > impact on performance. > (That's what Mark means by "streaming.."). > And because it is a Valve, it would run before the request has been mapped > to any application, so the hit would be for all applications in the server. > > (Of course, in some authentication scenarios, this already happens behind > the scenes. But you can avoid it by designing the application accordingly. > See : https://tomcat.apache.org/tomcat-8.0-doc/config/http.html --> > Common Attributes --> maxSavePostSize) > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
ServletRequest.getInputStream, getReader, getParameter.
Hello, I am working on a Valve that does some integrity checking on HTTP requests (the details aren't important) where I need this valve to have access to the HTTP request body as well. I used request.getInputStream to fetch the data. However when a web application makes use of my valve, the getParameter method does not return the parameters submitted via POST anymore. This is documented behavior according to the spec of ServletRequest ( https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletRequest.html#getInputStream() ). I was wondering why it was designed this way, since numerous complaints have arisen from this behavior and some ugly workarounds have been devised which unfortunately stop working from Tomcat 7 (servlet 3.0): https://stackoverflow.com/questions/10210645/http-servlet-request-lose-params-from-post-body-after-read-it-once This shows how easily code like this could break. Overwriting getInputStream to return a cached version doesn't work anymore since the parameter attribute isn't populated by using getInputStream. How exactly it is populated remains a mystery to me. Any advice on how to solve this properly? Performing an integrity check without getInputStream or getReader but with getParameters, will not work if the data submitted is not in the expected format. Kind regards, Roel Storms
Re: ServletRequest.getInputStream, getReader, getParameter.
2015-11-23 16:31 GMT+01:00 Mark Thomas <ma...@apache.org>: > On 23/11/2015 14:30, Roel Storms wrote: > > Hello, > > > > I am working on a Valve that does some integrity checking on HTTP > requests > > (the details aren't important) where I need this valve to have access to > > the HTTP request body as well. I used request.getInputStream to fetch the > > data. However when a web application makes use of my valve, the > > getParameter method does not return the parameters submitted via POST > > anymore. This is documented behavior according to the spec of > > ServletRequest ( > > > https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletRequest.html#getInputStream() > > ). > > > > I was wondering why it was designed this way, > > Given the potential size of a request body, streaming is the only viable > option. > > > since numerous complaints > > have arisen from this behavior and some ugly workarounds have been > devised > > which unfortunately stop working from Tomcat 7 (servlet 3.0): > > > > > https://stackoverflow.com/questions/10210645/http-servlet-request-lose-params-from-post-body-after-read-it-once > > > > This shows how easily code like this could break. > > What that shows is the folks haven't thought through what they are > trying to do. Consider the following: > > Tomcat provides request R. > Filter reads request body using R.getInputStream(). > Filter caches request body. > Filter wraps request R to provide R', over-riding getInputStream() to > provide the cached body. > Filter passes R' to the application. > Application calls R'.getParameter() > R'.getParameter() calls R.getParameter() > > Keep in mind at this point R has zero knowledge of R'. > > R calls getInputStream() to read request body but that InputStream has > already been read. > > The problem is the wrapper, R'. Over-riding getInputStream() is not > enough. It needs to over-ride every method that may access that > InputStream. Which is non-trivial because it means re-implementing a lot > of functionality the container would normally provide for you out of the > box. > > > Overwriting getInputStream to return a cached version doesn't work > anymore > > Nope. That never worked. See my explanation above. > > > since the parameter attribute isn't populated by using getInputStream. > How > > exactly it is populated remains a mystery to me. Any advice on how to > solve > > this properly? > > Write a better wrapper. > > A better wrapper would need to implement every method using the stream. To get a correct output from parseParameters it doesn't suffice to override readPostBody and readChunkedPostBody since these are overridden in the wrapper but the implementation of parseParameter in the Request won't use them. Overriding parseParameters as well, can't be done since it uses a lot of protected flags (parametersParsed, usingInputStream, usingReader,...). This would mean overriding almost the entire Request. Every time you need a protected attribute or operation in your overriding implementation, you need to override this attribute and operation as well. In the end you would copy almost the entire request. > Performing an integrity check without getInputStream or getReader but with > > getParameters, will not work if the data submitted is not in the expected > > format. > > See above. > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
apache fop remains active in servlet environment
I use apache fop in a servlet to display some xml as pdf. When I have used
that functionality in my webapp my (Tomcat 6.0) web container doesn't want
to undeploy. It deletes everything in the webapps/*context* directory except
WEB-INF/lib/batik.jar and WEB-INF/lib/fop.jar. When trying to delete the
files manually windows tells me they are in use.
I use this code to render the xml into pdf
ByteArrayOutputStream out = new ByteArrayOutputStream();
FopFactory ff=FopFactory.newInstance();
TransformerFactory tf=TransformerFactory.newInstance();
StreamSource xslfo=new
StreamSource(this.getServletContext().getRealPath(lid-pdf.xsl));
try {
Transformer tt=tf.newTransformer(xslfo);
Fop fp=ff.newFop(MimeConstants.MIME_PDF, out);
SAXResult res=new SAXResult(fp.getDefaultHandler());
Source src= new DOMSource(doc);
DOMResult dd=new DOMResult();
assert(src!=null);
assert(res!=null);
tt.transform(src, dd);
Transformer t2=tf.newTransformer();
// System.out.println(res.getNode().getFirstChild());
t2.transform(new DOMSource(dd.getNode()), res );
//Prepare response
response.setContentType(application/pdf);
assert(out.size()0);
response.setContentLength(out.size());
// System.out.println(Version.getVersion());
//Send content to Browser
response.getOutputStream().write(out.toByteArray());
response.getOutputStream().flush();
out.close();
} catch (FOPException e) {
// TODO Auto-generated catch block
throw new ServletException(e);
} catch (TransformerConfigurationException e1) {
// TODO Auto-generated catch block
throw new ServletException(e1);
} catch (TransformerException e) {
// TODO Auto-generated catch block
throw new ServletException(e);
}
System.gc();
Anyone has any ideas?
Roel
--
View this message in context:
http://www.nabble.com/apache-fop-remains-active-in-servlet-environment-tf4896511.html#a14023743
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: apache fop remains active in servlet environment
And how can i use that to render an in-memory DOM object? The xml I need to
render is constructed on the fly from database records and then fed to fop.
Roel
mgainty wrote:
FOP 0.94 has working servlet code
which can be called specifying the xml and xsl
http://servername/fop/servlet/FopServlet?xml=data.xmlxslt=format.xsl
OR just using the fo param
http://servername/fop/servlet/FopServlet?fo=readme.fo
http://archive.apache.org/dist/xmlgraphics/fop/binaries/
M--
- Original Message -
Wrom: YRWTQTIPWIGYOKSTTZRCLBDXRQBGJS
To: users@tomcat.apache.org
Sent: Thursday, November 29, 2007 6:25 AM
Subject: apache fop remains active in servlet environment
I use apache fop in a servlet to display some xml as pdf. When I have
used
that functionality in my webapp my (Tomcat 6.0) web container doesn't
want
to undeploy. It deletes everything in the webapps/*context* directory
except
WEB-INF/lib/batik.jar and WEB-INF/lib/fop.jar. When trying to delete the
files manually windows tells me they are in use.
I use this code to render the xml into pdf
ByteArrayOutputStream out = new ByteArrayOutputStream();
FopFactory ff=FopFactory.newInstance();
TransformerFactory tf=TransformerFactory.newInstance();
StreamSource xslfo=new
StreamSource(this.getServletContext().getRealPath(lid-pdf.xsl));
try {
Transformer tt=tf.newTransformer(xslfo);
Fop fp=ff.newFop(MimeConstants.MIME_PDF, out);
SAXResult res=new SAXResult(fp.getDefaultHandler());
Source src= new DOMSource(doc);
DOMResult dd=new DOMResult();
assert(src!=null);
assert(res!=null);
tt.transform(src, dd);
Transformer t2=tf.newTransformer();
// System.out.println(res.getNode().getFirstChild());
t2.transform(new DOMSource(dd.getNode()), res );
//Prepare response
response.setContentType(application/pdf);
assert(out.size()0);
response.setContentLength(out.size());
// System.out.println(Version.getVersion());
//Send content to Browser
response.getOutputStream().write(out.toByteArray());
response.getOutputStream().flush();
out.close();
} catch (FOPException e) {
// TODO Auto-generated catch block
throw new ServletException(e);
} catch (TransformerConfigurationException e1) {
// TODO Auto-generated catch block
throw new ServletException(e1);
} catch (TransformerException e) {
// TODO Auto-generated catch block
throw new ServletException(e);
}
System.gc();
Anyone has any ideas?
Roel
--
View this message in context:
http://www.nabble.com/apache-fop-remains-active-in-servlet-environment-tf489
6511.html#a14023743
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/apache-fop-remains-active-in-servlet-environment-tf4896511.html#a14030465
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
apache fop and security manager problem
I wrote a servlet converting some xml to a pdf. The code (appended) is
basically a slightly modified version of the example code in the fop faq
about servlets.
When I start Tomcat 5.5 with a security manager I get this weird exception
(appended) when I try to access the servlet.
When I don’t start it with a security manager the servlet just works.
I don’t get why.
I added following jars to my common/endorsed folder:
serializer-2.7.0.jar
xalan-2.7.0.jar
xercesImpl-2.7.1.jar
The other jar’s that came with fop are in common/lib, contents of that
folder:
avalon-framework-4.2.0.jar
batik-all-1.6.jar
commons-el.jar
commons-io-1.1.jar
commons-logging-1.0.4.jar
fop.jar
jasper-compiler-jdt.jar
jasper-compiler.jar
jasper-runtime.jar
jsp-api.jar
naming-factory-dbcp.jar
naming-factory.jar
naming-resources.jar
servlet-api.jar
xml-apis-1.3.02.jar
xmlgraphics-commons-1.1.jar
Any thoughts?
Sincerely
Roel
java.lang.UnsupportedOperationException: Don't know how to handle
application/pdf as an output format. Neither an FOEventHandler, nor a
Renderer could be found for this output format.
org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.j
ava:224)
org.apache.fop.fo.FOTreeBuilder.init(FOTreeBuilder.java:98)
org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:147)
org.apache.fop.apps.Fop.init(Fop.java:82)
org.apache.fop.apps.FopFactory.newFop(FopFactory.java:204)
be.jprupel.Dbase.Static.FopExport.doPost(FopExport.java:92)
javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
java.lang.reflect.Method.invoke(Unknown Source)
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:243)
java.security.AccessController.doPrivileged(Native Method)
javax.security.auth.Subject.doAsPrivileged(Unknown Source)
org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:275)
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:16
1)
code:
ByteArrayOutputStream out = new
ByteArrayOutputStream();
FopFactory ff=FopFactory.newInstance();
TransformerFactory
tf=TransformerFactory.newInstance();
StreamSource xslfo=new
StreamSource(Doc.localContext.concat(/lid-pdf.xsl));
try {
Templates tt=tf.newTemplates(xslfo);
Fop fp=ff.newFop(MimeConstants.MIME_PDF,
out);
DOMResult res = new DOMResult();
Source src= new DOMSource(doc);
tt.newTransformer().transform(src, res);
Transformer t2=tf.newTransformer();
t2.transform(new DOMSource(res.getNode()), new
SAXResult(fp.getDefaultHandler()));
//Prepare response
response.setContentType(application/pdf);
response.setContentLength(out.size());
//Send content to Browser
response.getOutputStream().write(out.toByteArray());
response.getOutputStream().flush();
} catch (FOPException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (TransformerConfigurationException e1) {
// TODO Auto-generated catch block
e1.printStackTrace();
} catch (TransformerException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.472 / Virus Database: 269.9.1/854 - Release Date: 19/06/2007
13:12
Betr.: Re: Problem with HttpSessionListener
Juan,
what you also could do is, adjusting your code as follows:
public void sessionCreated(HttpSessionEvent e){
System.out.println(sessionCreated - id = + e.getSession().getId());
e.getSession().setAttribute(test, new String(testValue));
}
add this line
System.out.println(sessionGetAttribute - id = +
request.getSession().getId());
before/after this line
String test = (String)request.getSession().getAttribute(test);
so you will be able to see if the get- and setAttribute happen on the same
session and not different ones
Roel
Christopher Schultz [EMAIL PROTECTED] 11/10/2006 16:27
Juan,
public class HttpTestListener implements HttpSessionListener {
public void sessionCreated(HttpSessionEvent e){
e.getSession().setAttribute(test, new String(testValue);
}
Okay. I assume that there's an extra ) end the end, otherwise your
code doesn't compile. I'll chalk that up to a copy-paste error.
listener
listener-classcom.test.HttpTestListener/listener-class
/listener
Okay, that looks good.
And, finally, in a servlet I try to recover the value of test:
...
String test = (String)request.getSession().getAttribute(test);
...
After this, the value of de variable test is null
What have I to do if I want to recover the value of test?
I'm guessing that you are never setting that value.
Try changing your code to this:
public void sessionCreated(HttpSessionEvent e){
System.out.println(sessionCreated!!!);
e.getSession().setAttribute(test, new String(testValue));
}
...and then check your catalina.out log (or standard output log,
whatever that is). If you aren't getting these messages, then your
listener is not configured correctly.
Make sure that your web.xml is actually in WEB-INF (I have sometimes
forgotten to copy web.xml from my development directory into the Tomcat
deployment, so double-check). You might consider doing a fresh install
of your application into the Tomcat webapp directory (or re-deploy the
WAR file) to make sure that Tomcat doesn't somehow have a stale copy of
web.xml lying around. Make sure you restart Tomcat, too ;)
I hope that helps.
-chris
**
Disclaimer: zie www.aquafin.be
From Tomcat 5.0.28 to 5.5.20
Hi all, i want to migrate from tomcat 5.0 to tomcat 5.5, but it's not going very smoothly. i noticed that the Logger-tag isn't valid anymore, so i deleted it out of server.xml and use log4j instead. but i'm very confused with the contexts. i keep getting this warning/info-message: A docBase C:\Program Files\Apache Software Foundation\Tomcat AG4W\webapps\AquaGis4Web inside the host appBase has been specified, and will be ignored i tried a lot of things, but none of the ones i tried let disappear that message. and if i succeed in letting disappear that message, i can't access my application anymore. i have (like in tomcat 5.0.28) a xml-file under conf/[engine]/[host] with the name of my web-application. content of the file: ?xml version='1.0' encoding='utf-8'? !-- Tomcat AquaGis4Web Context -- Context path=/AquaGis4Web docBase=AquaGis4Web debug=2 reloadable=true crossContext=true ResourceLink name=jdbc/db global=jdbc/db type=java.lang.String / /Context my server.xml contains 2 global jndi resources (db to authenticate users, connection to sql-db) and 1 engine with 1 host. so it looks like this: Server port=8005 shutdown=SHUTDOWN Listener className=org.apache.catalina.core.AprLifecycleListener / Listener className=org.apache.catalina.mbeans.ServerLifecycleListener / Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener / Listener className=org.apache.catalina.storeconfig.StoreConfigLifecycleListener/ !-- Global JNDI resources -- GlobalNamingResources !-- Editable user database that can also be used by UserDatabaseRealm to authenticate users -- Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users.xml / !-- database Tomcat 5.5 -- Resource name=jdbc/db auth=Container type=javax.sql.DataSource driverClassName=net.sourceforge.jtds.jdbc.Driver url=*** username=*** password=*** maxActive=20 maxIdle=5 maxWait=10 removeAbandoned=true removeAbandonedTimeout=5 logAbandoned=true / /GlobalNamingResources !-- Define the Tomcat Stand-Alone Service -- Service name=Catalina !-- Define a non-SSL HTTP/1.1 Connector on port 8080 -- Connector port=8080 maxHttpHeaderSize=8192 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 connectionTimeout=2 disableUploadTimeout=true / !-- Define an AJP 1.3 Connector on port 8009 -- Connector port=8009 enableLookups=false redirectPort=8443 protocol=AJP/1.3 / !-- Define the top level container in our container hierarchy -- Engine name=Catalina defaultHost=localhost Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase / Host name=localhost appBase=webapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false / /Engine /Service /Server which adjustments i have to do to get rid of that message but still be able to access my web-application. any tips, hints, suggestions, remarks,... are welcome thanks a lot for your time With kind regards Roel ** Disclaimer: zie www.aquafin.be
Betr.: RE: From Tomcat 5.0.28 to 5.5.20
OK, i did read it -- conclusion: you don't have to set it. so i adjusted my web-app.xml by deleting the path-attribute, resulting in: ?xml version='1.0' encoding='utf-8'? !-- Tomcat AquaGis4Web Context -- Context displayName=AquaGis4Web docBase=AquaGis4Web debug=2 reloadable=true crossContext=true ResourceLink name=jdbc/db global=jdbc/db type=java.lang.String / /Context but still getting the A docBase C:\Program Files\Apache Software Foundation\Tomcat AG4W\webapps\AquaGis4Web inside the host appBase has been specified, and will be ignored - message Caldarale, Charles R [EMAIL PROTECTED] 10/10/2006 15:45 From: Roel De Nijs [mailto:[EMAIL PROTECTED] Subject: From Tomcat 5.0.28 to 5.5.20 i want to migrate from tomcat 5.0 to tomcat 5.5, but it's not going very smoothly. but i'm very confused with the contexts. any tips, hints, suggestions, remarks For a start, read the 5.5 doc for Context, in particular the description of the path attribute: The value of this field must not be set except when statically defining a Context in server.xml, as it will be infered [sic] from the filenames used for either the .xml context file or the docBase. http://tomcat.apache.org/tomcat-5.5-doc/config/context.html - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ** Disclaimer: zie www.aquafin.be
Memory Management between different webapps
Hi, I have a tomcat with ± 10 web-applications. Is there a maximum or some guidance in the number of web-apps you can put in one instance of Tomcat? And i start tomcat with the options -Xmx1024m -Xms1024m -- is there some information or articles about how tomcat is spreading all this memory over the web-apps? Is this completely random, or first come first gets? What if a web-app is called for the first time and all possible memory is allocated to other web-apps? Many thanks already Roel ** Disclaimer: zie www.aquafin.be
Betr.: RE: Memory Management between different webapps
The problem we are confronted with: all our web-apps are running fine in our test-environment, even if workload is simulated to be very high. If we go to production environment (which is an exact copy of the test-environment) then tomcat gives OOME, sometimes 3-4 times a day. And it looks to be at random situations, so it's a really big mistery why in test everything goes well and in production it crashes more then once a day. And it's doing it for approx 4 months now, so it's time it's getting solved. [EMAIL PROTECTED] 2/02/2006 11:06 From: Roel De Nijs [mailto:[EMAIL PROTECTED] I have a tomcat with ± 10 web-applications. Is there a maximum or some guidance in the number of web-apps you can put in one instance of Tomcat? Tomcat itself uses relatively little memory per-webapp (a few megabytes, depending on version). The major load comes from the number of simultaneous connections (and hence the size of the thread pool) and, even more, from how the webapps are written. You're in the best place to evaluate these. And i start tomcat with the options -Xmx1024m -Xms1024m -- is there some information or articles about how tomcat is spreading all this memory over the web-apps? Is this completely random, or first come first gets? What if a web-app is called for the first time and all possible memory is allocated to other web-apps? It's all one big object memory, shared between all the webapps. Roughly (there are many more nuances than this): whenever it gets full, the garbage-collector is run. If there's not enough space to allocate an object after the garbage collector has run, you get an OutOfMemoryError. So memory will be allocated as your webapps request it (and potentially returned to the Java VM's pool of free memory some unknown time after they stop using it); if a webapp is called for the first time and there's not enough space to allocate the memory required for its startup, you'll get an OOME. To my knowledge, there is no way of partitioning memory inside a single JVM such that the amount available to a given webapp can be restricted. - Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ** Disclaimer: zie www.aquafin.be
Betr.: Re: The Future of Tomcat
or they think coffee and/or island :-) [EMAIL PROTECTED] 2/02/2006 16:50:03 True, but the HTTP server is still what most people think of when they hear the name Apache. Probably same people, that think of Applets or Javascript when they hear the word Java? Dave Leon :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ** Disclaimer: zie www.aquafin.be
