Thread: Re: [limesurvey-developers] Survey invocation flow diagram
The leading Open Source survey tool
Brought to you by:
c_schmitz
From: Thibault Le M. <Thi...@su...> - 2008-04-30 07:16:46
|
Macasek, Michael A. a écrit : > As I mentioned in today’s developer meeting here is the flow diagram > for the decisions made on how a survey is executed. It is not the > prettiest thing but it works. I am sure there will be questions so > fire away!!! Thanks a lot for this document: that's exactly the kind of things I am looking for in order to understand LS2 code. > > Also as I indicated this has not yet been fully implemented. > > Note: confidential is the new name for pseudo-anonymous surveys, it > implies we know who you are but we wont tell anyone what you said. > Hopefully that will reduce some of the confusion with the old name. Thanks for the renaming, it will indeed reduce the confusion. However I'm still concerned with the sentence "we wont tell anyone what you said", I would have preferred the sentence "We know if you've answered or not, but there is no possibility to know what you answered, either with the GUI, or by using low level investigation (SQL queries)". Other questions/remarks: * "Does prev state exist?" ==> if No, I suppose you jump to state "GO!!!" (transition arrow is missing) * About user management I really think we should differentiate the "Real User" notion with his own attributes (name, email, password... which can be managed by an external directory), from the "Internal User" notion in which you can have the 'conf_user' or 'anonymous user' notion For instance: External Real User module LDAP // instance ldap1: lemeur: tl...@li..., password=froggy (attributes can change over time) Internal Real User module Database: mmacasek : mma...@mi..., password=tommy (attributes can change over time) LS2 Internal User database: uid=lemeur, ... other internal attributes mmacasec, ... conf_user ??? anonymous_user ??? Otherwise we would have to synchronize information from the several external directories to the internal User table. But I'm quite sure this has already been taken into account... am I right ? Do you have more details concerning the anonymous and conf_user handling process or is it still in design state ? Thanks again for this very valuable document, Thibault PS: Carsten, I've already sent this email to the list and it is waiting moderator approval as I first forgot to remove the attached picture... so please do not forward it to the list. |
From: Macasek, M. A. <mma...@mi...> - 2008-04-30 14:32:09
Attachments:
survey_flow.jpg
|
Thanks for reviewing this! I attached a new version which includes the arrow you indicated was missing. I agree that my description of the confidential user is not sufficient. :) I am not 100% clear on your comments regarding user management. Let me give a quick description of how users are currently being handled: There is one user table; all users are stored there. This table has fields for additional attributes beyond username and password (refer to the data model for all the details). Each authenticated user account has an authentication tag associated with it indicating which type of authentication is required for this user (lsDB, CAS, etc). In addition to authenticated user there are the confidential and anonymous user accounts in the users table. These users are not authenticated user account as you are not able to log into the system as them. An argument can be made to split these 2 types out to a separate table but for now they all live together. The confidential and anonymous user accounts are denoted by not having an authentication tag and have a system_user tag of either confidential (not yet updated in the code from the previous pseudo-anonymous name) or anonymous. For an anonymous survey when the user starts the survey an anonymous user account is created and put in the user session as the user. If the user was previously logged into the system this effectively logs them out since it replace their authenticated session user with an anonymous user account. The anonymous user account username is randomly generated via mt_rand() for now. All actions a user performs on the anonymous survey are tied to this account. When the user is done the survey they are returned to the landing page of the service in an unauthenticated state. If the user leaves a survey before it is completed they are not able to resume it as a new anonymous user account is always generated when an anonymous survey is started. For the confidential survey when an authenticated user starts the survey the system first checks to see if this user has a confidential user account in the system, if not it creates one (details to follow). The confidential user is then added to the users session as the conf_user and all actions taken by that user on the survey are recorded as belonging to that confidential user account. When the user finishes the survey they are returned to their dashboard page in their authenticated state. Now I realize that a few sentences ago I indicated that the system checks to see if a confidential user account for the logged in user exists which implies the system can match an authenticated user to a confidential user account. This is true, given an authenticated user account the confidential user account can be derived, however, given a confidential user account the authenticated user cannot be derived. A confidential user account is currently generated by taking the authenticated username concatenated with the authenticated users DB dependant id (row id) which is then md5 hashed. Using the DB dependant id means that if you move these records to a new DB it will likely break the connection between the authenticated user and the confidential user account as the DB dependant id will have changed. So why do it this way? This will allows us to profile a confidential user account in terms of continuous surveys and for that matter any set of surveys. This is likely to be a big deal to anyone attempting to use surveys for marketing purposes, happiness of employees, etc. So to sum up that last paragraph a given authenticated user account can be traced to a confidential user account via an algorithm but a given confidential account cannot be traced back to an authenticated user account. Since the connection includes a DB dependant id (row id) if it is changed/removed the link will be broken. The alternative here is to have some type of flag that is set when an authenticated user completes a confidential survey and all the results are tied to a random account as done for anonymous surveys. This would not allow for the trending across surveys for a given confidential user which we believe is something important that we need to support. I believe that covers the 'how users work' question. Thoughts? Michael Macasek On 4/30/08 3:15 AM, "Thibault Le Meur" <Thi...@su...> wrote: > Macasek, Michael A. a écrit : >> As I mentioned in today¹s developer meeting here is the flow diagram >> for the decisions made on how a survey is executed. It is not the >> prettiest thing but it works. I am sure there will be questions so >> fire away!!! > Thanks a lot for this document: that's exactly the kind of things I am > looking for in order to understand LS2 code. > >> >> Also as I indicated this has not yet been fully implemented. >> >> Note: confidential is the new name for pseudo-anonymous surveys, it >> implies we know who you are but we wont tell anyone what you said. >> Hopefully that will reduce some of the confusion with the old name. > Thanks for the renaming, it will indeed reduce the confusion. > However I'm still concerned with the sentence "we wont tell anyone what > you said", I would have preferred the sentence "We know if you've > answered or not, but there is no possibility to know what you answered, > either with the GUI, or by using low level investigation (SQL queries)". > > > Other questions/remarks: > * "Does prev state exist?" ==> if No, I suppose you jump to state > "GO!!!" (transition arrow is missing) > * About user management I really think we should differentiate the "Real > User" notion with his own attributes (name, email, password... which can > be managed by an external directory), from the "Internal User" notion in > which you can have the 'conf_user' or 'anonymous user' notion > > For instance: > > > External Real User module LDAP // instance ldap1: > lemeur: tl...@li..., password=froggy (attributes can change > over time) > > Internal Real User module Database: > mmacasek : mma...@mi..., password=tommy (attributes can change > over time) > > LS2 Internal User database: > uid=lemeur, ... other internal attributes > mmacasec, ... > conf_user ??? > anonymous_user ??? > > Otherwise we would have to synchronize information from the several > external directories to the internal User table. > > But I'm quite sure this has already been taken into account... am I right ? > > Do you have more details concerning the anonymous and conf_user handling > process or is it still in design state ? > > > Thanks again for this very valuable document, > Thibault > > > PS: Carsten, I've already sent this email to the list and it is waiting > moderator approval as I first forgot to remove the attached picture... > so please do not forward it to the list. > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > limesurvey-developers mailing list > lim...@li... > https://lists.sourceforge.net/lists/listinfo/limesurvey-developers |
From: Thibault Le M. <Thi...@su...> - 2008-04-30 19:31:18
|
Hi Michael, Thanks for this cristal clear explanation of how "users" are managed in LS2. in-line comments below: > There is one user table; all users are stored there. This table has fields > for additional attributes beyond username and password (refer to the data > model for all the details). Each authenticated user account has an > authentication tag associated with it indicating which type of > authentication is required for this user (lsDB, CAS, etc). ok, then am I right in the following assumptions: 1- There is no need to declare a user in the user's table if he is to be authenticated via an external backend (let's say LDAP): the user will be automatically imported once authenticated by one of the authorized authentication modules 2- if the user's entry is in an external directory (ldap for instance), additionnal user's attributes such as user email, real name, ... might be copied to the internal DB but are always reloaded from the LDAP directory at login time: this is to ensure that we use up-to-date user's information from the directory and not possibly obsoleted information stored in our internal DB (caching in the DB is possible, but all fields should be resynchronized at each login time) 3- About "authentication types", o better "authentication instances": If I have several LDAP directorie (ldap1, ldap2), I will be able to define 2 "authentication types" called ldap1 and ldap2 even if they both relates to the same authentication mechanism > In addition to authenticated user there are the confidential and anonymous > user accounts in the users table. These users are not authenticated user > account as you are not able to log into the system as them. An argument can > be made to split these 2 types out to a separate table but for now they all > live together. Given what follows about confidential users, I would really prefer to have confidential users in a different table than the one used for real users: this may reduce confidential data exposure by separating those connected sensible information... am I right ? Moreover, it sounds more logical to split the lsDB user management from the internally used user-table (let's called this one the "functionnal user table"): imagine someone needs to develop an alternative lsDB user management interface, it will be safer to use a table different from the functionnal user table because DB permissions can be differentiated. > The confidential and anonymous user accounts are denoted by > not having an authentication tag and have a system_user tag of either > confidential (not yet updated in the code from the previous pseudo-anonymous > name) or anonymous. > > For an anonymous survey when the user starts the survey an anonymous user > account is created and put in the user session as the user. If the user was > previously logged into the system this effectively logs them out since it > replace their authenticated session user with an anonymous user account. ok, makes sense > The > anonymous user account username is randomly generated via mt_rand() for now. > All actions a user performs on the anonymous survey are tied to this > account. When the user is done the survey they are returned to the landing > page of the service in an unauthenticated state. If the user leaves a survey > before it is completed they are not able to resume it as a new anonymous > user account is always generated when an anonymous survey is started. ok > > For the confidential survey when an authenticated user starts the survey the > system first checks to see if this user has a confidential user account in > the system, if not it creates one (details to follow). The confidential user > is then added to the users session as the conf_user and all actions taken by > that user on the survey are recorded as belonging to that confidential user > account. When the user finishes the survey they are returned to their > dashboard page in their authenticated state. Now I realize that a few > sentences ago I indicated that the system checks to see if a confidential > user account for the logged in user exists which implies the system can > match an authenticated user to a confidential user account. This is true, > given an authenticated user account the confidential user account can be > derived, however, given a confidential user account the authenticated user > cannot be derived. A confidential user account is currently generated by > taking the authenticated username concatenated with the authenticated users > DB dependant id (row id) which is then md5 hashed. Using the DB dependant id > means that if you move these records to a new DB it will likely break the > connection between the authenticated user and the confidential user account > as the DB dependant id will have changed. I understand > So why do it this way? This will > allows us to profile a confidential user account in terms of continuous > surveys and for that matter any set of surveys. This is likely to be a big > deal to anyone attempting to use surveys for marketing purposes, happiness > of employees, etc. Ok I see now why you implemented it this way. > The alternative here is to have some type of flag that is set when an > authenticated user completes a confidential survey and all the results are > tied to a random account as done for anonymous surveys. This would not allow > for the trending across surveys for a given confidential user which we > believe is something important that we need to support. As far as I am concerned, this alternative is just another kind of confidential survey: a confidential survey more similar to 'election systems'. I think LS2 needs both kinds of confidential surveys: * the one you've implemented and which enables 'continuous survey tracking' * the one I'm used to have with LS1 and which is more like an electronic election system Is it possible to adapt both systems in LS2, that is to say to implement your proposed alternative as an optionnal parameter of a confidential survey ? > I believe that covers the 'how users work' question. Yes, again you've been very clear, and I thank you for this. I hope I was a little more understandable this time ;-) Regards, Thibault ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Macasek, M. A. <mma...@mi...> - 2008-05-05 15:00:03
|
Ok so the supporting of multiple authentication types (including multiple of the same type) is something we probably need to support but we have not put much thought into as of yet. As for the 3rd survey assignment type we probably need to do that. Any thoughts on a name for that type? M On 4/30/08 3:31 PM, "Thibault Le Meur" <Thi...@su...> wrote: > Hi Michael, > > Thanks for this cristal clear explanation of how "users" are managed in LS2. > > in-line comments below: > >> There is one user table; all users are stored there. This table has fields >> for additional attributes beyond username and password (refer to the data >> model for all the details). Each authenticated user account has an >> authentication tag associated with it indicating which type of >> authentication is required for this user (lsDB, CAS, etc). > > ok, then am I right in the following assumptions: > > 1- There is no need to declare a user in the user's table if he is to > be authenticated via an external backend (let's say LDAP): the user > will be automatically imported once authenticated by one of the > authorized authentication modules > > 2- if the user's entry is in an external directory (ldap for > instance), additionnal user's attributes such as user email, real > name, ... might be copied to the internal DB but are always reloaded > from the LDAP directory at login time: this is to ensure that we use > up-to-date user's information from the directory and not possibly > obsoleted information stored in our internal DB (caching in the DB is > possible, but all fields should be resynchronized at each login time) > > 3- About "authentication types", o better "authentication instances": > If I have several LDAP directorie (ldap1, ldap2), I will be able to > define 2 "authentication types" called ldap1 and ldap2 even if they > both relates to the same authentication mechanism > >> In addition to authenticated user there are the confidential and anonymous >> user accounts in the users table. These users are not authenticated user >> account as you are not able to log into the system as them. An argument can >> be made to split these 2 types out to a separate table but for now they all >> live together. > > Given what follows about confidential users, I would really prefer to > have confidential users in a different table than the one used for > real users: this may reduce confidential data exposure by separating > those connected sensible information... am I right ? > > Moreover, it sounds more logical to split the lsDB user management > from the internally used user-table (let's called this one the > "functionnal user table"): imagine someone needs to develop an > alternative lsDB user management interface, it will be safer to use a > table different from the functionnal user table because DB permissions > can be differentiated. > >> The confidential and anonymous user accounts are denoted by >> not having an authentication tag and have a system_user tag of either >> confidential (not yet updated in the code from the previous pseudo-anonymous >> name) or anonymous. >> >> For an anonymous survey when the user starts the survey an anonymous user >> account is created and put in the user session as the user. If the user was >> previously logged into the system this effectively logs them out since it >> replace their authenticated session user with an anonymous user account. > > ok, makes sense > >> The >> anonymous user account username is randomly generated via mt_rand() for now. >> All actions a user performs on the anonymous survey are tied to this >> account. When the user is done the survey they are returned to the landing >> page of the service in an unauthenticated state. If the user leaves a survey >> before it is completed they are not able to resume it as a new anonymous >> user account is always generated when an anonymous survey is started. > > ok > >> >> For the confidential survey when an authenticated user starts the survey the >> system first checks to see if this user has a confidential user account in >> the system, if not it creates one (details to follow). The confidential user >> is then added to the users session as the conf_user and all actions taken by >> that user on the survey are recorded as belonging to that confidential user >> account. When the user finishes the survey they are returned to their >> dashboard page in their authenticated state. Now I realize that a few >> sentences ago I indicated that the system checks to see if a confidential >> user account for the logged in user exists which implies the system can >> match an authenticated user to a confidential user account. This is true, >> given an authenticated user account the confidential user account can be >> derived, however, given a confidential user account the authenticated user >> cannot be derived. A confidential user account is currently generated by >> taking the authenticated username concatenated with the authenticated users >> DB dependant id (row id) which is then md5 hashed. Using the DB dependant id >> means that if you move these records to a new DB it will likely break the >> connection between the authenticated user and the confidential user account >> as the DB dependant id will have changed. > > I understand > > >> So why do it this way? This will >> allows us to profile a confidential user account in terms of continuous >> surveys and for that matter any set of surveys. This is likely to be a big >> deal to anyone attempting to use surveys for marketing purposes, happiness >> of employees, etc. > > Ok I see now why you implemented it this way. > >> The alternative here is to have some type of flag that is set when an >> authenticated user completes a confidential survey and all the results are >> tied to a random account as done for anonymous surveys. This would not allow >> for the trending across surveys for a given confidential user which we >> believe is something important that we need to support. > > As far as I am concerned, this alternative is just another kind of > confidential survey: a confidential survey more similar to 'election > systems'. > > I think LS2 needs both kinds of confidential surveys: > * the one you've implemented and which enables 'continuous survey tracking' > * the one I'm used to have with LS1 and which is more like an > electronic election system > > Is it possible to adapt both systems in LS2, that is to say to > implement your proposed alternative as an optionnal parameter of a > confidential survey ? > >> I believe that covers the 'how users work' question. > > Yes, again you've been very clear, and I thank you for this. > > I hope I was a little more understandable this time ;-) > > Regards, > Thibault > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > |