On 2024/07/03 20:17:06 Christopher Schultz wrote: > Francesco, > > On 7/2/24 05:44, Francesco Chicchiriccò wrote: > > On 2024/06/27 14:47:48 Christopher Schultz wrote: > >> Rainer, > >> > >> On 6/21/24 07:55, Rainer Jung wrote: > >>> Am 20.06.24 um 17:52 schrieb Christopher Schultz: > >>>> Francesco, > >>>> > >>>> On 6/20/24 09:03, Francesco Chicchiriccò wrote: > >>>>> On 2024/06/20 12:18:15 Konstantin Kolinko wrote: > >>>>>> чт, 20 июн. 2024 г. в 13:25, Francesco Chicchiriccò > >>>>>> <ilgro...@apache.org>: > >>>>>>> > >>>>>>> Hi there, > >>>>>>> at Syncope we usually use the latest Tomcat versions to run a large > >>>>>>> chunk of our integration tests. > >>>>>>> > >>>>>>> In our master branch we relay on Tomcat 10.1.x, and upgrading to > >>>>>>> 10.1.25 from 10.1.24 went smooth as usual. > >>>>>>> > >>>>>>> In our 3_0_X branch we relay on Tomcat 9.0.x; with 9.0.89 > >>>>>>> everything goes as expected, but with 9.0.90 we are getting the > >>>>>>> exception [1]. > >>>>>>> > >>>>>>> Any idea of what could be changed in 9.0.90 within this regard? > >>>>>>> Thank you. > >>>>>>> > >>>>>>> [1] https://gist.github.com/ilgrosso/be1fb1f2ea205eef60fb221973f87b34 > >>>>>>> > >>>>>> > >>>>>> The "java.lang.IllegalStateException: The request object has been > >>>>>> recycled and is no longer associated with this facade" message means > >>>>>> that a Request object has been (illegally) stored and is accessed > >>>>>> outside of its lifecycle - when the underlying structures and buffers > >>>>>> have already been recycled and may have been reused to process > >>>>>> subsequent requests. > >>>>>> > >>>>>> Mark wrote: > >>>>>>> You could try explicitly setting discardFacades to false. > >>>>>> > >>>>>> In general, not recommended. > >>>>>> https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html#Connectors > >>>>>> > >>>>>> Calling getScheme() might be safe (as IIRC the info will come from a > >>>>>> connector configuration), but anything beyond that may lead to either > >>>>>> false results or to security issues. It would be better to identify > >>>>>> and fix the underlying cause. > >>>>> > >>>>> Are you suggesting there is something to fix on Syncope's or CXF's > >>>>> code? Or rather on Tomcat? > >>>> > >>>> This is a protection that Tomcat is providing to the application. > >>>> There is no known bug in Tomcat's code. > >>>> > >>>> It's not clear to me whether Syncope's or CXF's code is retaining such > >>>> a reference, but, given the stack trace I would suspect that > >>>> UserServiceImpl in Syncope's code is where you should start looking. > >>>> > >>>>> As I am writing above, we have no issues with Tomcat 9.0.89 nor with > >>>>> Tomcat 10.1.25. > >>>> > >>>> It looks like this change was made in 9.0.90 *only* and was not ported > >>>> to the other June releases. Honestly, this change should have been > >>>> made to all active branches... I'm not sure why Rémy only applied it > >>>> to 9.0.x. > >>> > >>> The default value for discardFacades is already "true" in 10.1 and 11 > >>> and the old system property > >>> org.apache.catalina.connector.RECYCLE_FACADES no longer exists for > >>> these. So setting discardFacades to "true" in 9.0.x makes the default > >>> behavior consistent. > >> > >> +1 thanks for pointing this out. This commit was Rémy aligning 9.0.x > >> with the other active branches, not making it /out/ of alignment. > >> > >>> No idea, why the application now shows different behavior for 9.0.x > >>> and 10.1.x. > >> Agreed. But wrapping in HttpServletRequestWrapper, using Async, and > >> performing what the OP described as "multiplex[ing] the incoming request > >> onto atomic requests, injected to CXF service processing" sounds like a > >> recipe for retaining references to these objects after they go out of > >> scope. > > > > Hi Chris, > > the fix mentioned above was exactly addressed to copy (as opposite as > > reference) the needed values from the original request. > > While coding the fix, however, I've discovered that the Syncope master > > branch (run on Tomcat 10.1) was already updated to work this way, while the > > 3_0_X branch (run on Tomcat 9) was simply not as fresh. > > > > Everything is back working as expected, thanks for information. > > > > Finally, about: > > > >> If your application is retaining a reference to an HttpServletRequest > >> after the request has been completed, then your application has a bug. > >> You can tell me it doesn't have a bug, but it does. If you want > >> information from that request, you should copy it out of the request. > > > > I just wanted to reassure you that my intention was not to deny there was > > an issue, just to explain that probably it was not much about "security > > and/or privacy". > > I disagree. If you retain references to those objects, it's entirely > possible to return data in a response to the wrong user. Or get > information from a request whose user has changed out from underneath you. > > Any time user A and user B can see each other's data, that's a privacy > and/or security issue in my book.
Hi Chris, I couldn't agree more with your book, in the general case. But in this context the caller is one, which is conveying multiple JAX-RS requests onto a single HTTP request, so we don't have user A and user B, only a single user. Regards. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
