Hi Ruwan, I share the same concern as Dimuthu, losing data in older sessions. I understand that you have a way to identify the oldest session. If we can get some information about that session, at least a device ID, we can pop up a confirmation box as follows.
"Your session limit has reached. We have to close "xxx" session in order to create a new one. Please confirm." If the user said "OK", we close the session and create a new one. No new UI will be required. This is of cause if we can get information about the oldest session. If we can't do that as well, then I think the best way to go forward is moving all of this to the next phase. Just MHO. Thanks, Vihanga. On Mon, Apr 2, 2018 at 3:27 PM, Ruwan Abeykoon <[email protected]> wrote: > Hi Dimuthu, > +1 on the second phase. > > But I am worried about the "Unlikely case" .. > The problem is that the user is not able to login, which means he can not > use any services, except "call the admin". Usually you can not reach admin > in time when this kind of thing happens. I consider this as "Denial of > Service", which causes loss of productivity in critical situations. > > Cheers, > Ruwan > > > On Mon, Apr 2, 2018 at 9:36 AM, Dimuthu Leelarathne <[email protected]> > wrote: > >> Hi Ruwan, >> >> He has to close the session by closing the browser or logging out from >> other device. >> >> Let's take the unlikely case of user loosing the device or not having the >> other browser (eg. left the extra machine at home etc ...), then we have >> the phase-2 of this project where he can chose to kill the session while >> the authentication is happening for the current session. Or else he can >> call the admin and ask him to kill a session. >> >> thanks, >> Dimuthu >> >> >> On Mon, Apr 2, 2018 at 2:14 PM, Ruwan Abeykoon <[email protected]> wrote: >> >>> Hi Dimuthu, >>> The problem would be that the user will not be able to login at all on a >>> new device, if we choose to stop creation of sessions. Then there is no way >>> to terminate any old sessions, as the user is not authenticated. >>> >>> >>> Cheers, >>> Ruwan >>> >>> On Mon, Apr 2, 2018 at 8:18 AM, Dimuthu Leelarathne <[email protected]> >>> wrote: >>> >>>> Hi All, >>>> >>>> I am in favor of not allowing the user to proceed with the current >>>> session. That is because old sessions could have unsaved data. There is no >>>> harm in stopping the creation of new session. >>>> >>>> thanks, >>>> Dimuthu >>>> >>>> >>>> On Mon, Apr 2, 2018 at 12:09 PM, Ruwan Abeykoon <[email protected]> >>>> wrote: >>>> >>>>> Hi Dimuth/Vihanga, >>>>> I think we need to get the minimal solution implemented and >>>>> demonstrated first. The minimal product would, >>>>> >>>>> 1. Close the oldest session, when the session count exceeds maximum >>>>> allowed count. No need to provide a UI to the user. >>>>> 2. Log the above case in separate identifiable log in IS side. >>>>> >>>>> The reason is, identifying the multiple sessions and allowing this to >>>>> be handled is a major feature itself, and there are number of technical >>>>> hurdles to overcome. >>>>> >>>>> At a later phase, we can add the feedback UI for the user, allow him >>>>> to select which sessions to close, etc. This is again a major feature. >>>>> Because the UI needs to display a lot of information about the session >>>>> (Device, IP, Time, Browser, etc), which we do not capture as of now. >>>>> >>>>> Cheers, >>>>> Ruwan >>>>> >>>>> >>>>> >>>>> On Mon, Apr 2, 2018 at 5:53 AM, Vihanga Liyanage <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Dimuth, >>>>>> >>>>>> I'm not sure I understand your approach. In the first phase of the >>>>>> project, if a user request for a new session, you will just close the >>>>>> existing session and create a new one, without letting the user know. Is >>>>>> that correct? >>>>>> >>>>>> On Mon, Apr 2, 2018 at 10:41 AM, Dimuth Menikgama <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Vihanga, >>>>>>> >>>>>>> AFAIU you are suggesting an improvement to first solution suggested. >>>>>>> Instead of closing the existing session at once, you are suggesting to >>>>>>> notify the user and get the approval before closing. >>>>>>> >>>>>>> This can be added to second phase of this project. In the second >>>>>>> phase, we hope to add functionality to prompt the user with active >>>>>>> session >>>>>>> information (meta data such as device, session start time etc ) and let >>>>>>> user to select what session to close. >>>>>>> >>>>>>> Regards, >>>>>>> Dimuth Menikgama >>>>>>> >>>>>>> >>>>>>> On Mon, Apr 2, 2018 at 10:02 AM, Dimuth Menikgama <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Denuwanthi, >>>>>>>> >>>>>>>> Currently we have decided to implement this as a conditional >>>>>>>> authentication function. Admin user can use this function to get the >>>>>>>> number >>>>>>>> of active sessions and can create a condition with the limit he wants. >>>>>>>> If >>>>>>>> the admin user does not use this function, no conditions will be tested >>>>>>>> based on session count. So the user can create unlimited number of >>>>>>>> sessions >>>>>>>> without any problem. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Dimuth Menikgama. >>>>>>>> >>>>>>>> On Sat, Mar 31, 2018 at 3:24 PM, Vihanga Liyanage <[email protected] >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> Hi Dimuth, >>>>>>>>> >>>>>>>>> >>>>>>>>>>> - >>>>>>>>>>> >>>>>>>>>>> What is the best way to handle new session request when >>>>>>>>>>> maximum allowed session limit is 1? >>>>>>>>>>> - >>>>>>>>>>> >>>>>>>>>>> If there is a session, close that session and create a >>>>>>>>>>> new session. >>>>>>>>>>> - >>>>>>>>>>> >>>>>>>>>>> Notify the user about the existing session and ask to end >>>>>>>>>>> that manually if he want to create a new session. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> IMHO, I think both of these proposed methods are not suitable. >>>>>>>>> Instead what if we notify the user about the limitation on active >>>>>>>>> sessions >>>>>>>>> and ask for the consent to close the existing session from our end? >>>>>>>>> Closing >>>>>>>>> the session manually by the user could be a hassle for him especially >>>>>>>>> if it >>>>>>>>> was another device. We can just invalidate the session from our end >>>>>>>>> without >>>>>>>>> much effort. WDYT? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vihanga. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Vihanga Liyanage >>>>>>>>> >>>>>>>>> Software Engineer | WS*O₂* Inc. >>>>>>>>> >>>>>>>>> M : +*94710124103 <071%20012%204103>* | http://wso2.com >>>>>>>>> >>>>>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> *Dimuth Menikgama* >>>>>>>> >>>>>>>> *Software Engineer* >>>>>>>> *WSO2* >>>>>>>> >>>>>>>> >>>>>>>> *Mobile : + 94 702337977 >>>>>>>> <%2B%2094%2011%202145345%20%C2%A0Ext.%205737>* >>>>>>>> >>>>>>>> * <%2B%2094%2011%202145300>* >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> *Dimuth Menikgama* >>>>>>> >>>>>>> *Software Engineer* >>>>>>> *WSO2* >>>>>>> >>>>>>> >>>>>>> *Mobile : + 94 702337977 >>>>>>> <%2B%2094%2011%202145345%20%C2%A0Ext.%205737>* >>>>>>> >>>>>>> * <%2B%2094%2011%202145300>* >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Vihanga Liyanage >>>>>> >>>>>> Software Engineer | WS*O₂* Inc. >>>>>> >>>>>> M : +*94710124103 <071%20012%204103>* | http://wso2.com >>>>>> >>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature> >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Dimuthu Leelarathne >>>> Director, Rapid Response Team >>>> >>>> WSO2, Inc. (http://wso2.com) >>>> email: [email protected] >>>> Mobile: +94773661935 <+94%2077%20366%201935> >>>> Blog: http://muthulee.blogspot.com >>>> >>>> Lean . Enterprise . Middleware >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> >>> *Ruwan Abeykoon* >>> *Associate Director/Architect**,* >>> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> * >>> *lean.enterprise.middleware.* >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Dimuthu Leelarathne >> Director, Rapid Response Team >> >> WSO2, Inc. (http://wso2.com) >> email: [email protected] >> Mobile: +94773661935 <+94%2077%20366%201935> >> Blog: http://muthulee.blogspot.com >> >> Lean . Enterprise . Middleware >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > *Ruwan Abeykoon* > *Associate Director/Architect**,* > *WSO2, Inc. http://wso2.com <https://wso2.com/signature> * > *lean.enterprise.middleware.* > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Vihanga Liyanage Software Engineer | WS*O₂* Inc. M : +*94710124103* | http://wso2.com [image: http://wso2.com/signature] <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
