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(). >>>> 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 <input type="file" ..> 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 >>> >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
