You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Boris Petrov <bo...@profuzdigital.com> on 2023/02/16 14:01:05 UTC
What happens with sessions with an infinite timeout?
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
Re: What happens with sessions with an infinite timeout?
Posted by Tamás Cservenák <ta...@cservenak.net>.
Boris,
validate (if needed all) the permissions before
someMethodThatTakesFiveHr(), and then execute the long running task in
something like this (example from Nexus
https://github.com/sonatype/nexus-public/blob/main/components/nexus-thread/src/main/java/org/sonatype/nexus/thread/NexusExecutorService.java)
but also points to some shiro examples.
In short, you will need some "super subject" for long running tasks (hence
validate all a priori, should user be able to do things, as system for sure
will be able to do so).
Again, on example of Nexus, here is the "almighty subject":
https://github.com/sonatype/nexus-public/blob/main/components/nexus-security/src/main/java/org/sonatype/nexus/security/subject/FakeAlmightySubject.java
HTH
T
On Wed, Feb 22, 2023 at 4:37 PM 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, lenny@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 <ar...@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>
> 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, lenny@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>
>> 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
>> >>
>>
>
>
Re: What happens with sessions with an infinite timeout?
Posted by Boris Petrov <bo...@profuzdigital.com>.
OK, thanks a lot for the discussion and help! I'll think about
everything and try to figure out something. :)
Regards!
On 2/23/23 07:42, lenny@flowlogix.com wrote:
> 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 <bo...@profuzdigital.com>
>> 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, lenny@flowlogix.com 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 <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, lenny@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
>>>>>> <ar...@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> 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, lenny@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> 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
>>>>>> >>
>>>>>>
>>>>>
>>>
>
Re: What happens with sessions with an infinite timeout?
Posted by le...@flowlogix.com.
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 <bo...@profuzdigital.com> 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, lenny@flowlogix.com <ma...@flowlogix.com> 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 <boris@profuzdigital.com <ma...@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, lenny@flowlogix.com <ma...@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 <arthurugochukwu@gmail.com <ma...@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 <boris@profuzdigital.com <ma...@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, lenny@flowlogix.com <ma...@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<boris@profuzdigital.com <ma...@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
>>>>> >>
>>>>
>>
Re: What happens with sessions with an infinite timeout?
Posted by Boris Petrov <bo...@profuzdigital.com>.
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, lenny@flowlogix.com 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 <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, lenny@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
>>>> <ar...@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> 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, lenny@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> 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
>>>> >>
>>>>
>>>
>
Re: What happens with sessions with an infinite timeout?
Posted by le...@flowlogix.com.
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, lenny@flowlogix.com <ma...@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 <arthurugochukwu@gmail.com <ma...@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 <boris@profuzdigital.com <ma...@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, lenny@flowlogix.com <ma...@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<boris@profuzdigital.com <ma...@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
>>> >>
>>
Re: What happens with sessions with an infinite timeout?
Posted by Boris Petrov <bo...@profuzdigital.com>.
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, lenny@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 <ar...@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>
>> 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, lenny@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> 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
>> >>
>>
>
Re: What happens with sessions with an infinite timeout?
Posted by le...@flowlogix.com.
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 <ar...@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 <boris@profuzdigital.com <ma...@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, lenny@flowlogix.com <ma...@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<boris@profuzdigital.com <ma...@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
> >>
Re: What happens with sessions with an infinite timeout?
Posted by Arthur Okeke <ar...@gmail.com>.
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> 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, lenny@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>
> 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
> >>
>
Re: What happens with sessions with an infinite timeout?
Posted by Boris Petrov <bo...@profuzdigital.com>.
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, lenny@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> 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
>>
Re: What happens with sessions with an infinite timeout?
Posted by le...@flowlogix.com.
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> 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
>