[Update] Hi all,
During the design review for this project. Following things were discussed. - Problems with existing design 1. Operational issues - Performance may degrade with the number of users 2. Bounded to schema - Extensions should not depend on databases - Make this feature an Extension. - To avoid the above mentioned design issues, use IS-Analytics to retrieve data about sessions. (For the POC ) - Use existing session information in IS-Analytics if possible. Create a new stream with required session information. - Use Siddhi to publish and retrieve the basic session information and meta data. - This approach allow users to write/ modify their own ways of session management logic with Siddhi. - This session information will then moved inside the identity server and this feature can be used without analytics components. please add anything I have missed. Regards, Dimuth Menikgama On Mon, Apr 2, 2018 at 5:31 PM, Vihanga Liyanage <[email protected]> wrote: > 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> > -- *Dimuth Menikgama* *Software Engineer* *WSO2* *Mobile : + 94 702337977 <%2B%2094%2011%202145345%20%C2%A0Ext.%205737>* * <%2B%2094%2011%202145300>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
