You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now users are required to login with their IACR username and password, but this requires the user to be an IACR member (or have been one in the past). In many cases the job of maintaining the website is delegated to someone with more technical skills who is not an IACR member (e.g., a student hired to do the website, or a contractor). It used to be possible to sign up for an IACR account without becoming a member, but this has the effect of polluting the IACR membership database with accounts of people who have no intent to become members. I would prefer that we allow an IACR member to create a "guest account" so that they could delegate construction and maintenance of the program. These "guest accounts" would be stored in a guest_account table in the programs database rather than the IACR membership database. The login procedure would first check username/password against the IACR membership database, and then check against the guest_account table. The guest_account table would have only a few fields:
who created the account (the iacr membership ID)
when it was created (a datetime)
the userid of the account. This needs to be distinguished from the iacrref field of the IACR membership database, since it is used in the programs table to identify ownership of a record. The guest_account table should have a unique key on this column, and we might as well make it a primary key autoincrement, and use guest_22 as the actual login id.
the username of the account (so it is human-readable). Ideally I'd like to have the username field be unique, though this isn't even guaranteed in the memberdata table of the membership database. We should still put a unique key on this field in the guest_account table.
an email address for the account. This should be a unique column.
the password field, which would be null upon creation.
an auth token used for initial authentication of the email.
The flow for creation of an account would be for the user to first login with an IACR account, and when they are, they are given the ability to edit a program or create a guest account. The form to create a guest account would ask for an email address and name. Submitting the form would create a record in the guest_account table with a random 128-bit token and null password and generate an email to the new user to login at a specific url like /tools/program/confirm?token= that would look up in the database by the token, and offer the user a chance to set their password. Note that if they forget their password, they can reuse the URL with the token to reset their password.
The text was updated successfully, but these errors were encountered:
Right now users are required to login with their IACR username and password, but this requires the user to be an IACR member (or have been one in the past). In many cases the job of maintaining the website is delegated to someone with more technical skills who is not an IACR member (e.g., a student hired to do the website, or a contractor). It used to be possible to sign up for an IACR account without becoming a member, but this has the effect of polluting the IACR membership database with accounts of people who have no intent to become members. I would prefer that we allow an IACR member to create a "guest account" so that they could delegate construction and maintenance of the program. These "guest accounts" would be stored in a guest_account table in the programs database rather than the IACR membership database. The login procedure would first check username/password against the IACR membership database, and then check against the guest_account table. The guest_account table would have only a few fields:
The flow for creation of an account would be for the user to first login with an IACR account, and when they are, they are given the ability to edit a program or create a guest account. The form to create a guest account would ask for an email address and name. Submitting the form would create a record in the guest_account table with a random 128-bit token and null password and generate an email to the new user to login at a specific url like /tools/program/confirm?token= that would look up in the database by the token, and offer the user a chance to set their password. Note that if they forget their password, they can reuse the URL with the token to reset their password.
The text was updated successfully, but these errors were encountered: