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] 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]>
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] 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]> 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]> 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] 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]> 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
>>
