[
https://issues.apache.org/jira/browse/JSEC-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dragut Razvan updated JSEC-59:
------------------------------
Description:
Hi hi,
As discussed in this thread :
http://n2.nabble.com/Subject-Session-relationship-td2303079.html, this feature
request refers to accessing the active sessions in JSecurity.
It would be useful at times to have access to the active sessions and
implicitly to subject creation. One of the scenarios that will benefit from
this, is to implement features like 'kick' (logout some random users by a super
admin). However, currently there is a workaround to implement this using
permissions ( see Les' response in thread mentioned above ).
This feature requires some debate, voting , usage scenarios with
weaks/strongs/why/when along with implementation/approach ideas, because it
seems it might have performance implications if JSecurity users will be able to
iterate in a standard way through potential thousands of sessions.
My initial need was to kick all the logged in users (subjects) to enforce them
login again in order to accept new terms and conditions, therefore I needed
access to all active subjects.
I understand the subject is currently created at the beginning of
request/transaction and dropped at the end of it.
Question : What would be the impact of caching the subject instead of
create/drop ? In case this feature will be implemented I think caching the
subject might save some resources and might be faster than creating it, though
I have no figures.
was:
Hi hi,
As discussed in this thread :
http://n2.nabble.com/Subject-Session-relationship-td2303079.html, this feature
request refers to accessing the active sessions in JSecurity.
It would be useful at times to have access to the active sessions and
implicitly to subject creation. One of the scenarios that will benefit from
this, is to implement features like 'kick' (logout some random users by a super
admin). However, currently there is a workaround to implement this using
permissions ( see Les' response in thread mentioned above ).
This feature requires some debate, voting , usage scenarios with
weaks/strongs/why/when along with implementation/approach ideas, because it
seems it might have performance implications if JSecurity users will be able to
iterate in a standard way through potential thousands of sessions.
> JSecurity user access to active sessions
> ----------------------------------------
>
> Key: JSEC-59
> URL: https://issues.apache.org/jira/browse/JSEC-59
> Project: JSecurity
> Issue Type: New Feature
> Components: Session Management
> Reporter: Dragut Razvan
> Priority: Minor
>
> Hi hi,
> As discussed in this thread :
> http://n2.nabble.com/Subject-Session-relationship-td2303079.html, this
> feature request refers to accessing the active sessions in JSecurity.
> It would be useful at times to have access to the active sessions and
> implicitly to subject creation. One of the scenarios that will benefit from
> this, is to implement features like 'kick' (logout some random users by a
> super admin). However, currently there is a workaround to implement this
> using permissions ( see Les' response in thread mentioned above ).
> This feature requires some debate, voting , usage scenarios with
> weaks/strongs/why/when along with implementation/approach ideas, because it
> seems it might have performance implications if JSecurity users will be able
> to iterate in a standard way through potential thousands of sessions.
> My initial need was to kick all the logged in users (subjects) to enforce
> them login again in order to accept new terms and conditions, therefore I
> needed access to all active subjects.
> I understand the subject is currently created at the beginning of
> request/transaction and dropped at the end of it.
> Question : What would be the impact of caching the subject instead of
> create/drop ? In case this feature will be implemented I think caching the
> subject might save some resources and might be faster than creating it,
> though I have no figures.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
