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 <bo...@profuzdigital.com> 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, le...@flowlogix.com <mailto:le...@flowlogix.com> 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 <arthurugochu...@gmail.com
>>> <mailto:arthurugochu...@gmail.com>> 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 <bo...@profuzdigital.com
>>> <mailto:bo...@profuzdigital.com>> 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, le...@flowlogix.com <mailto:le...@flowlogix.com> 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<bo...@profuzdigital.com
>>> >> <mailto:bo...@profuzdigital.com>> 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
>>> >>
>>
