Yea, I figured :) I have seen this anti-pattern many, many times, so don’t feel too bad :) You are misusing Principal as a state saving mechanism. This is where Jakarta Batch and MicroProfile Long Running Actions come in. These will manage state for you.
> On Feb 22, 2023, at 4:31 PM, Boris Petrov <[email protected]> wrote: > > Lenny, I mostly (only?) need the principal after the long running operations > - for example to log in the DB that the operation has completed and who the > initiator was. I could get it beforehand and pass it around... but that's a > lot of boilerplate. I would think that getting the principal shouldn't > touch/require a session. Why is it so? > > Tomas, I actually have the same thing as your "FaktAlmightySubject" (I call > it "GodUser" :D) but it's not exactly what I want - I really need the > original user that started the operation - for logging purposes and whatnot. > > Thanks to everyone for the time and discussion! > > On 2/22/23 20:11, [email protected] <mailto:[email protected]> wrote: >> Your use case is inherently insecure and no security framework is designed >> for this. >> Authentication, by definition, has a well-defined length of time associated >> with it. The less that period is, the more secure the system is. >> Let’s say the password got hacked and the account is locked. You don’t want >> the authentication to last any longer. >> >> Bottom line is that you have to design your system in such a way that time >> period of authentication is short and well-defined. >> This is where Jakarta Batch and MP Long-Running Actions come in. >> Also, if you want to be really “insecure” (at your own risk, of course) you >> can get the principal at the beginning and pass it into your other >> asynchronous called. >> You aren’t using the principal as a “state saving’ mechanism so you don’t >> have to pass it into your other functions are you? >> If yes, this a very bad code / design smell. >> >>> On Feb 22, 2023, at 9:36 AM, Boris Petrov <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi, sorry for the late answer. I'm not sure I understand you correctly. >>> Imagine the following case: >>> >>> void newFrontendRequest() { >>> var subject = SecurityUtils.getSubject(); >>> someMethodThatTakesFiveHoursToComplete(); >>> var principal = subject.getPrincipal(); >>> ... >>> } >>> >>> This will blow up on the `getPrincipal` line because this subject's session >>> has expired and is no longer valid. My question is how to handle something >>> like that. Of course in my case things are much more complex, the code is >>> not synchronous, the `getPrincipal` call is not directly after the >>> long-running operation, etc. >>> >>> Thanks! >>> >>> On 2/17/23 21:01, [email protected] <mailto:[email protected]> wrote: >>>> Jakarta Batch or MicroProfile Long-Running Actions are some of the best >>>> practices implementations you are looking for. >>>> >>>>> On Feb 17, 2023, at 6:33 AM, Arthur Okeke <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Since the subject is authenticated at the point you reach the backed then >>>>> maybe you can use some kind of impersonation I.e a backend job runs the >>>>> long running process on behalf of the subject. >>>>> >>>>> On Fri 17. Feb 2023 at 09:52, Boris Petrov <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> OK, thanks for the answer. But in that case how would I handle the >>>>> following case - a request is made from the frontend with some >>>>> authenticated subject. I want to trigger some long-running process and >>>>> do something that requires a valid session after that. The long-running >>>>> process is in a chain of asynchronous stuff and I don't know where it >>>>> will "end" so I can log-out the subject. What are the best practices for >>>>> something like that? >>>>> >>>>> On 2/16/23 19:13, [email protected] <mailto:[email protected]> wrote: >>>>> > I would not recommend it. Unless the Subject is logged out, the session >>>>> > would not be garbage collected. >>>>> > Technically this is possible if every subject is ’sure’ to be logged >>>>> > out, but that’s is unrealistic in a web application. >>>>> > >>>>> >> On Feb 16, 2023, at 8:01 AM, Boris Petrov<[email protected] >>>>> >> <mailto:[email protected]>> wrote: >>>>> >> >>>>> >> Hi all, >>>>> >> >>>>> >> I'm wondering is it "safe" to call `setTimeout(-1);` on a Shiro >>>>> >> session. That is, after I do that, is that a memory leak? Whenever the >>>>> >> `Subject` of that `Session` is GC'd, will the session also be >>>>> >> invalidated and removed from the session-manager or that must be done >>>>> >> manually? Thanks! >>>>> >> >>>>> >> Regards, >>>>> >> Boris >>>>> >> >>>> >>
