No, you are exactly right. That is what is necessary to explicitly propagate the Subject state to child threads.
The fact that that state leaks into the child thread currently is the bug I am solving. > On Apr 14, 2025, at 12:16 PM, Tamás Cservenák <ta...@cservenak.net> wrote: > > I might be off, but I was using Shiro since it was JSecurity 0.x, > AFAIR there was something like Subject.associateWith that was doing this? > Basically "to start a new thread" we always used custom thread > factories that did this. > > T > > On Mon, Apr 14, 2025 at 5:28 PM <le...@flowlogix.com> wrote: >> >> Well, 2 weeks isn’t that bad in the “grand scheme of things” >> >> To answer your question, No. >> If a thread wants access to SecurityManager, it needs to explicitly bind it. >> The implicit binding provided by ShiroFilter is solely for the servlet >> thread, not any other thread. >> >>> On Apr 14, 2025, at 2:14 AM, Benjamin Marwell <bmarw...@apache.org> wrote: >>> >>> Hi, I am not able to test this properly in the next two weeks. :( >>> I wonder: If a servlet starts threads, should the thread not be able >>> to see the SecurityManager? >>> >>> Can you give us some more insights? >>> >>> - Ben >>> >>> >>> Am Sa., 12. Apr. 2025 um 23:17 Uhr schrieb <le...@flowlogix.com>: >>>> >>>> Hi, >>>> >>>> During testing of Shiro 2.0.3, I ran into a bug that existed since Shiro >>>> 1.1.0 >>>> It uses InheritableThreadLocal map to save SecurityManager, Session, etc. >>>> I found that it causes ThreadLocal leakages whenever a servlet, for >>>> example, starts any other threads. >>>> >>>> Please see https://github.com/apache/shiro/issues/2081 and >>>> https://github.com/apache/shiro/pull/2082 >>>> >>>> Any feedback would be appreciated. I am looking to merge and release 2.0.4 >>>> that includes this fix ASAP, >>>> so if you have an issue with the way this was fixed, please let me know. >>>> >>>> Thank you! >>>> >>> >> >
