Simple and secure authentification mechanism for single Shiny applications. Credentials can be stored in an encrypted SQLite database or on your own SQL Database (Postgres, MySQL, ...). Source code of
翻译准备中
安全HTML · RGitHub @datastorm-open在线运营者未确认
试用过了吗? 点一下就好,无需登录。
Simple and secure authentification mechanism for single shiny applications.
翻译准备中
正在加载完整 README。
查看完整 README ↗Simple and secure authentication mechanism for single 'Shiny' applications. Credentials can be stored in an encrypted 'SQLite' database or on your own SQL Database (PostgreSQL, MySQL, ...). Source code of main application is protected until authentication is successful.
Shiny for Python: a Python version, pyshinymanager, is under development.
Live demo:
You can authenticate with:
shiny / password: shinyshinymanager / password: shinymanager (Admin)Online documentation: https://datastorm-open.github.io/shinymanager/
Using options("shinymanager.pwd_validity"), you can set password validity period. It defaults to Inf. You can specify for example options("shinymanager.pwd_validity" = 90) if you want to force user changing password each 90 days.
Using options("shinymanager.pwd_failure_limit"), you can set password failure limit. It defaults to Inf. You can specify for example options("shinymanager.pwd_failure_limit" = 5) if you want to lock user account after 5 wrong password.
Using options("shinymanager.reset_password" = TRUE), a "Forgot password?" link is added on the authentication page. A user can reset the password by entering a valid username and its associated email : a temporary password is generated, sent by email, and the user is forced to change it on next login. A generic message is displayed (before sending the email) to avoid account enumeration. Known limits : an account that can't reset its password gets a dedicated message and a failed sending shows an error popup, which both reveal that the account exists. The reset button is enabled again after the same minimal delay (a few seconds) whatever the outcome, unless the sending takes longer. Every attempt is recorded in the logs, and sending errors are also raised as R warnings. No reset is done for an expired account or an account not authorized for the application.
With options("shinymanager.reset_password" = "username"), the form only asks for a username and the temporary password is sent to the email stored for that user (if any).
Note : the temporary password replaces the current one as soon as the email is sent, before the user proves access to the mailbox. Anyone who knows a username (and its email with TRUE) can thus invalidate the password of this account, and use up its resets when shinymanager.reset_password_max is set. We recommend the TRUE mode rather than "username", and to set shinymanager.reset_password_max knowing this risk.
With options("shinymanager.reset_password_validity" = 20), the temporary password sent by email is only valid for 20 minutes (default : no expiration). A new request replaces the previous one. Passwords generated by an admin are not concerned, and an admin reset cancels a pending emailed password. The expiration is stored as text (UTC) in a temp_pwd_expire column of the pwd_mngt table : created automatically with SQLite, to be added as a text column (e.g. varchar(19), STRING with BigQuery / Spark) with a SQL backend. The send_mail function does not receive the validity : we recommend to mention it in the email, reading it with getOption("shinymanager.reset_password_validity") (see example below).
With options("shinymanager.reset_password_max" = 3), a user can only request 3 resets in a row (default : no limit). The counter is reset on the next successful login with a non temporary password, or by an admin reset. It is stored in a n_user_reset column of the pwd_mngt table : created automatically with SQLite, to be added as an integer column with a SQL backend.
With options("shinymanager.reset_password_unlock" = FALSE), an account locked by shinymanager.pwd_failure_limit can only be unlocked by an admin : no email is sent (default TRUE : the reset unlocks the account).
It requires an email column in the credentials (use options("shinymanager.email_column") for another column name), a SQLite / SQL backend, and a send_mail function passed to secure_server. Otherwise the link is hidden, with a warning giving the reason. Set the option before the authentication page is built (in global.R for example, not in the server function). No email package is mandatory : provide your own sending function (any backend), or use the optional helper send_smtp_mail() (based on the suggested package emayili).
以上为 README 的开头部分。其余内容请阅读原文。 查看完整 README ↗