Password-Protected Dashboards


From what I have seen on the forums, it seems like even if I have a password-protected dashboard, I cannot make it so that a user logging into the dashboard can create their own password. In other words, I provide a global password that I control, but the end user cannot then use this password to create their own secure password. Is my understanding correct? The end user has security specifications they need to meet, and if I am providing passwords to all users, that may not be sufficient to meet their needs.

If you’re using our password-protected dashboards feature, then yes: You as the dashboard creator set a single password, and you may give that password to individuals whom you would like to give view-level access to the dashboard to.

If you are looking for specific passwords per user, I recommend building out an application experience, which has its own user management features built in. Then, you can serve the dashboard in question through a dashboard experience page, even personalizing portions of the dashboard to display per-user data as defined through the user’s group and device association.

Thank you, Dylan. So if my understanding is correct, by building out the application experience, users would be able to log-in with passwords that they create to meet security requirements, just as you would logging into anything else?

Correct. I don’t know what your security requirements are but Losant only enforces a minimum of 8 characters. However, you can set your own unique requirements in the workflows that deal with authentication and forgot password flows.

We have a Change Password Experience Form template that you may be interested in. It includes resources for allowing signed-in users to change their password, including support for more advanced password entropy rules (as regular expressions). The template does not include a sign-in page (though we have a template for that too) or a user account creation flow.

Thank you for the additional information and for the templates. Since we already have a sign-in page as part of our user experience, that should not be an issue. If there are any other questions, I will follow up, but I think the templates will suffice for now.