These settings affect how certain fields are used or validated within the realm.
AuthRocket has two ways of handling usernames:
When treating emails as the username, LoginRocket (hosted logins) will automatically keep the email and username in sync. However, the API itself will not do this and it is technically possible to use one email address for username and a different one for the email field.
This only affects users whose user_type is human. API-type (aka system) users always function as may be anything since API keys are rarely associated with a functioning email address.
By default, AuthRocket requires every User’s email to be unique within the realm (must be unique). Change this to may be duplicated if you don’t mind if email addresses are duplicated across accounts.
Once set to may be duplicated, this setting cannot be changed back to must be unique.
Note that username functions as an alternate primary key and must always be unique, regardless of this setting or Usernames for Humans.
In addition to passwords for humans, AuthRocket has the ability to authenticate API keys for system (API type) users. While passwords are always stored using a one-way hash function (bcrypt), API keys can either be hashed (uses a faster one-way function than bcrypt) or encrypted. When encrypted, this makes the API keys retrievable, which is useful if you want to be able to display API keys to your users on-demand (instead of just once, when first created).
If you let AuthRocket automatically generate the actual API keys for your API type users, the keys by default are just random strings. Sometimes it’s helpful to add a prefix to the keys so help users (or your support team) identify them as keys. If you wish to add such a prefix on newly created keys, set it here. This does not affect new keys where you provide the actual key.
Questions? Find a Typo? Get in touch.