Community

Forums » SEPHP Feature Requests

Max# Logins for User ID per ML

  • gs
    • 857 posts
    July 27, 2017 3:26 PM EDT

    A summary of the feature request.  Currently, a User may login multiple times (no idea of the limit).  This FR is to include an ML setting to limit the #Logins (concurrent).

    Details of settings, steps to use or see this feature, benefits.  Benefit is for security and monetization purposes - most software (that I'm familiar with) allows only 1 login per User.  I'm not referring to allowing multiple tabs in a browser for the same User, I'm specically referring to multiple logins in different browsers, different devices, etc.  The reason I prefer a numerical setting is that ADMINs may wish to allow certain MLs > 1 Login (for example, your highest paid subscription level; or ADMINs for Groups, so the generic 'admin' login could be used multiple times concurrently; or for MLs that are focused on logins for all family members). 

    Add screenshots when possible.  My guess is that this new setting should appear (anywhere) on the existing ML Settings page.



    Any other information you want to share that is relevant to the feature being requested. This might include the lines of code that you have identified as needing improvements and potential solutions (and your opinions on their merits).  none.


    This post was edited by gs at July 30, 2017 4:05 PM EDT
    • 3528 posts
    July 28, 2017 5:10 AM EDT

    I wasn't aware of any other scripts that have a setting for this. It is one that I liked when you submitted it in the github feature request section. 

  • gs
    • 857 posts
    July 28, 2017 1:53 PM EDT
    Donna said:

    I wasn't aware of any other scripts that have a setting for this. It is one that I liked when you submitted it in the github feature request section. 

    I apologize - when I mentioned 'software' I wasn't referring to CMS type scripts, but software in general.  I'm more familiar with business apps (both localized and web-based) and allowing multiple logins for the same User is a huge no-no (except sometimes for certain User types like ADMINs).  For these apps it's both a security and monetization/licensing thing.  My belief is that SE may want to take into consideration that SE is used for more than individuals/groups, especially through the use of many 3rd-Party Plugins.  Thus, the foundation/Core should provide more for the ADMINs that need more than the typical 'friends' and 'communities' people typically think of with CMS like SE/Oxwall/etc.  Yes, 3rd-Party Plugins will continue to do much of what SE doesn't do (and probably shouldn't do), but they still require a robust foundation to tie into and build upon.

    • 62 posts
    July 30, 2017 2:15 PM EDT

    You just want to limit concurrent logins? So a user can be signed into only one location at a time? If you login to one location, other locations are logged out. Many websites and scripts have the kind of feature and I like the idea of SE having this as an option as well.

  • gs
    • 857 posts
    July 30, 2017 3:50 PM EDT
    Casey said:

    You just want to limit concurrent logins? So a user can be signed into only one location at a time? If you login to one location, other locations are logged out. Many websites and scripts have the kind of feature and I like the idea of SE having this as an option as well.

    Thanks Casey for your input. 

    ==>"...only one location at a time ..."

    Actually, the FR is to allow defining a max# per ML rather than only Max#=1.  For example, in my case I would like ADMIN to be allowed 12 or more primarily due to testing as I typically work with 2-3 browers and 5-6 devices open at a time; some MLs only 1, others 3, others 5 (such as moderators) or whatever.  The MLs that include Mobile App could be allowed 2 (Mobile App + 1 Desktop Browser for example).

    When attempting to login as Max+1, then the oldest login get's logged-out (rather than logging out all other sessions).

    I'm referring to logged-in sessions (not browser Tabs in the same browser).  So for example, if I'm logged into 3 browsers in Win7, and 2 on an Android Tablet, that's a total of 5 sessions (regardless of how many browser tabs are open in each - as for example, I will often have 5-10 Tabs per browser).


    This post was edited by gs at July 30, 2017 3:55 PM EDT
    • 3528 posts
    July 31, 2017 5:23 AM EDT
    gs said:

    When attempting to login as Max+1, then the oldest login get's logged-out (rather than logging out all other sessions).

     

     

    I recommend having the older session get a notice that someone is trying to log in as their account and then they can approve or deny for security. Otherwise, a hacker could get in as someone and kick them out.

    • 69 posts
    July 31, 2017 7:51 AM EDT

    What about the situation when some user is logged into the community from home, mobile, tablet and some work computer? The situation like this is pretty normal for communities.

  • gs
    • 857 posts
    July 31, 2017 10:03 AM EDT
    Donna said:
    gs said:

    When attempting to login as Max+1, then the oldest login get's logged-out (rather than logging out all other sessions).

     

     

    I recommend having the older session get a notice that someone is trying to log in as their account and then they can approve or deny for security. Otherwise, a hacker could get in as someone and kick them out.


    This assumes the person has access to the original session, which they may not (device not nearby, problem with device or software, etc.). Maybe an email could be sent (as you suggested like google does for many apps), but even this sould be a setting in ADMINcp.

    As far as hackers go, if they're good enough simple SE security is meaningless. Besides, this would only address the issue when Max#+1 is attempted, and do nothing to prevent earlier logins no different than what a hacker could presently do.  Also, it seems you're assuming the hacker is the 'newest' User, not the 'oldest' one, which if the hacker is the oldest login, then the legitimate User could be potentially locked out forever if the hacker never 'approves' to be logged out to allow the 'newest' User to login (of course if a hacker changes the account password all bets are off). 

    In addition, preventing a 'new' login could potentially lock the legitimate User completely out if they can't (for whatever reason) confirm/deny the 'newest' login request.  I see the point in possibly (optional ADMINcp setting) alerting the User to a new login (personally I'd not use this as I'd be getting these messages all day long), but IMHO there's more potential detrimental issues in requiring confirmation from an older login to approve a newer one.

     


    This post was edited by gs at July 31, 2017 10:38 AM EDT
  • gs
    • 857 posts
    July 31, 2017 10:09 AM EDT

    BTW - in other environments I would do as Donna recommended. For example, in situations requiring higher security where there's IT/Admin staff available 24/7, this works. So if I'm in a work accounting app which is available only from within the office, then this is easily controllable, and if I'm locked out, someone with higher authority with proper security/access can 'let me back in' if it's determined that 'I am actually me'.


    This post was edited by gs at July 31, 2017 10:34 AM EDT
  • gs
    • 857 posts
    July 31, 2017 10:15 AM EDT
    Eugene Sutula said:

    What about the situation when some user is logged into the community from home, mobile, tablet and some work computer? The situation like this is pretty normal for communities.


    Good point/question Eugene, but this is already addressed. The Max# Concurrent sessions is total, so 4 devices 2 browsers each would require a minimum Max#=8. This is why this is also a monetization feature - upper MLs are allowed more flexibility (right now all Users can theoretically login as many times as they wish, or shall I say an account may be logged-in to a potentially unlimited number of times thus one account could be used by many people).


    This post was edited by gs at July 31, 2017 10:35 AM EDT