+ In release 1.3, the VIVO authorization system has some extensive changes. + In summary, these are:
+ With release 1.3, each authenticated user will have a user account. + If someone logs in using an external authentication system, + and no user account matches their external login credentials, + an account will be created. +
++ The user will be prompted to enter information for the account being created: + first name, last name, and e-mail address. +
++ Prior to release 1.3, each user account was identified by a Username field. + This field was labeled as “E-mail address” on some pages in VIVO, + but so mail was ever sent. + In release 1.3, this has changed, so the e-mail address is fully used, + both for identification and for communication with the user. +
++ Prior to release 1.3, the Username field (also referred to as “e-mail address”) + was used for several purposes: +
+ With release 1.3, these functions are handled by two separate fields + called EmailAddress field and ExternalAuthId. +
+ Note: With release 1.3, the ExternalAuthId can now be matched against + either an untyped literal or a string literal in the Profile page. ++
+ There are other changes to the internal structure of the user accounts data, + but they are important mostly to the VIVO software developers, + and you are not likely to notice them. +
++ If you are upgrading to VIVO release 1.3 from an existing VIVO installation, + the user accounts in your system will be migrated into the new data structures. + When migrating an account, both the EmailAddress field and the ExternalAuthId field + will be set to the value of the Username field in the old account. + The new account should behave as the old account did. +
+
+ When creating a new user account, or editing an existing one,
+ the system requires that your e-mail address be in a valid form,
+ like somebody@somewhere.edu.
+ You should plan for this as part of your migration to release 1.3
+
+ With release 1.3, VIVO users receive e-mail notifications + when an account is created or modified for them or by them. +
++ When an administrator creates a user account, + the user will receive an e-mail notification, + telling them that the account has been created, + and providing a link to VIVO that will allow them to set a password on the account. +
+ Note: when creating the account, + the administrator may indicate that it will only be used + with an external authentication system like Shibboleth or CUWebAuth. + In this case, the account will not require a password, + and the e-mail notification message to the user will not provide a password link. ++ +
+ When an administrator edits a user account, he may choose to reset the password. + As with a new account, the user will receive notification + with a link to VIVO that will allow them to set a new password. +
++ If a user changes the e-mail address on his account, + he will receive a notification message to that effect. +
++ If a user account is auto-created for a user with external authentication credentials, + the user will receive a notification message. +
+
+ The e-mail notification relies on two configuration properties:
+ email.smtpHost and email.replyTo.
+ If either of these properties is missing or empty,
+ VIVO will not attempt to send e-mail notifications to users.
+
+ This can be useful for small or experimental installations of VIVO, + or where e-mail notification is not desired. +
++ If e-mail notifications are disabled, + an administrator must set a password on each new account, + since the user will have no way of setting it. + When the user logs in for the first time, + VIVO will require them to change their password to one of their own choosing. +
++ Prior to release 1.3, each VIVO installation was created with a default administrator’s account. + In release 1.3, there is no such account. + Instead, each VIVO installation will have a “root” account. +
++ The email address for the root account is specified in deploy.properties, like this: +
rootUser.emailAddress = vivo_root@mydomain.edu+ The password for this account is automatically set to
rootPassword,
+ but you will be required to change the password the first time you log in.
+
+ Note: the initialAdminUser is no longer use.
+
+
+ + The root account is not a site administrator’s account – + it is more powerful than a site administrator’s acocunt. + The root account is permitted to visit any page in a VIVO application. + It is permitted to see any data property, and to enter data into any field. + As such, the root account can be very useful and rather dangerous. + It can also give you a distorted view of what your VIVO site looks like, + since data is shown which other accounts cannot see. +
++ The root account is not intended for routine, every day use. + The best way to use the root account is to create a site administrator’s account. + After that, use the root account only when necessary. +
+If your VIVO installation is running in RDB mode, and you'd like to convert to SDB, you can start the conversion process in the background diff --git a/example.deploy.properties b/example.deploy.properties index e77e0408..ef144bb2 100644 --- a/example.deploy.properties +++ b/example.deploy.properties @@ -72,8 +72,8 @@ vitro.home.directory = /usr/local/vivo/data # the "Contact Us" form will be disabled and users will not be notified of # changes to their accounts. # -email.smtpHost = smtp.my.domain.edu -email.replyTo = vivoAdmin@my.domain.edu +email.smtpHost = smtp.mydomain.edu +email.replyTo = vivoAdmin@mydomain.edu # # The basic parameters for a database connection. Change the end of the @@ -110,7 +110,7 @@ VitroConnection.DataSource.validationQuery = SELECT 1 # for this user is initially set to "rootPassword", but you will be asked to # change the password the first time you log in. # -rootUser.emailAddress = root@myDomain.com +rootUser.emailAddress = vivo_root@mydomain.edu # # How is a logged-in user associated with a particular Individual? One way is