rodauth 2.36.0 → 2.37.0

data/doc/release_notes/1.12.0.txt

@@ -1,61 +0,0 @@
-= Security Fix
-
-* The password reset key deadline was previously ignored when
-  checking for a password reset key.  This allowed expired keys to
-  be used.  This problem exists in all previous versions.
-
-  The root cause of this issue is that support for deadline checking
-  was not previously implemented.  In previous versions, the deadline
-  was only used to remove old keys when creating a new key.
-
-  Rodauth only allows a single password reset key per account, and
-  deletes password reset keys when passwords are reset. So if the
-  user had subsequently generated a different password reset key, or
-  had already used the password reset key to reset the password,
-  then they would not be vulnerable.  The most likely situation
-  where there exists a vulnerability due to this issue is:
-  
-  * A user requests a password reset.
-  * They do not reset their password or request another
-    password reset.
-  * The password reset key deadline expires.
-  * An attacker gets access to their archived email containing
-    the password reset link, which they use to reset the
-    password for the account.
-
-  Reporting Details:
-
-  * Initially reported on 10/3/2017
-  * Fixed in repository on 10/3/2017
-  * Version 1.12.0 released with fix on 10/3/2017
-
-  Thanks to Chris Hanks for discovering and reporting this issue
-  and supplying an initial fix.
-
-= New Features
-
-* The http_basic_auth feature now supports a
-  require_http_basic_auth configuration method.  When set to true,
-  if authentication is required and the request is not already
-  authenticated, they will get a 401 response instead of a
-  redirect to the login page.
-
-* All of the following Rodauth migration methods now support an
-  options hash:
-
-  * Rodauth.drop_database_authentication_functions
-  * Rodauth.create_database_previous_password_check_functions
-  * Rodauth.drop_database_previous_password_check_functions
-
-  These options allow you to customize the get_salt_name and
-  valid_hash_name database functions, as well as set the the table
-  for the previous_password_check_functions.
-
-* A :search_path option is now supported when using the following
-  Rodauth migration methods on PostgreSQL:
-
-  * Rodauth.create_database_authentication_functions
-  * Rodauth.drop_database_authentication_functions
-
-  This sets the search_path to use inside the function.  For
-  backwards compatibility, it defaults to 'public, pg_temp'.

data/doc/release_notes/1.13.0.txt

@@ -1,34 +0,0 @@
-= New Features
-
-* A cache_templates configuration method has been added, which can be
-  set to false to disable the default caching of templates.  The main
-  time you would want to use this is if you were overriding Rodauth's
-  templates with your own templates and modifying such templates in
-  development mode.  If that is the case, you may want to use
-  something like:
-
-    cache_templates(ENV['RACK_ENV'] != 'development')
-
-* An invalid_previous_password_message configuration method has been
-  added to the change_password feature, which overrides the default
-  invalid_password_message configuration method if the incorrect
-  previous password is used when changing the password.  This is
-  designed for use when invalid_password_message has been overridden
-  and the message doesn't make sense in the change password case.
-
-* A json_response_body(hash) configuration method has been added to
-  the jwt feature, allowing for custom formatting of the JSON
-  response body.  This is called with the hash to use in the
-  response, and should return a JSON-formatted string. Example:
-
-    json_response_body do |hash|
-      super('status'=>response.status, 'detail'=>hash)
-    end
-
-= Other Improvements
-
-* In the jwt feature, if json_response_custom_error_status? is set to
-  true, custom error statuses will be used if only_json? is set to
-  true, even if the request is not in JSON format.  Previously,
-  custom error statuses were only used if the request was in JSON
-  format.

data/doc/release_notes/1.14.0.txt

@@ -1,19 +0,0 @@
-= New Features
-
-* A change_password_notify feature has been added, which emails the
-  user when the change_password feature is used to change their
-  password.  This can alert the user when their password may have
-  been changed without their knowledge.
-
-= Other Improvements
-
-* When using the account_expiration feature with the reset_password
-  feature, resetting the passwords for expired accounts is no longer
-  allowed.  Note that the previous behavior isn't considered a
-  security issue, because even after resetting their password,
-  expired accounts could not login.
-
-* When using the account_expiration feature with the lockout feature,
-  unlocking expired accounts is no longer allowed.  Note that the
-  previous behavior isn't considered a security issue, because even
-  after unlocking the account, expired accounts could not login.

data/doc/release_notes/1.15.0.txt

@@ -1,21 +0,0 @@
-= New Features
-
-* create_account_set_password? and verify_account_set_password?
-  configuration methods have been added to the create_account and
-  verify_account features.  Setting:
-  
-    verify_account_set_password? true
-
-  in your rodauth configuration will change Rodauth so that instead
-  of asking for a password on the create account form, it will ask for
-  a password on the verify account form.
-
-  This can fix a possible issue where an attacker creates an account
-  for a user with a password the attacker knows.  If the user clicks
-  on the link in the verify account email and clicks on the button on
-  the verify account page, the attacker would have have a verified
-  account that they know the password to.
-
-  By setting verify_account_set_password? to true, you can ensure that
-  only the user who has access to the email can enter the password for
-  the account.

data/doc/release_notes/1.16.0.txt

@@ -1,31 +0,0 @@
-= New Features
-
-* A disallow_common_passwords feature has been added.  This feature
-  by default will disallow the 10,000 most common passwords:
-
-    enable :disallow_common_passwords
-
-  You can supply your own file containing common passwords separated
-  by newlines ("\n"):
-
-    most_common_passwords_file '/path/to/file'
-
-  You can also supply a password dictionary directly as any object
-  that responds to include?:
-
-    most_common_passwords some_password_dictionary_object
-
-  The reason only the 10,000 most common passwords are used by
-  default is larger password files would significantly bloat the
-  size of the gem.  Also, because the most common passwords are kept
-  in memory by default for performance reasons, larger password
-  files can bloat the memory usage of the process (the
-  disallow_common_passwords feature should use around 500KB of
-  memory by default).  For very large password dictionaries,
-  consider using a custom object that does not keep all common
-  passwords in memory.
-  
-= Other Improvements
-
-* Rodauth no longer uses the Rack::Request#[] method to get
-  parameter values.  This method is deprecated in Rack 2.  

data/doc/release_notes/1.17.0.txt

@@ -1,23 +0,0 @@
-= Improvements
-
-* Support has been added for using Roda's route_csrf plugin with
-  request-specific CSRF tokens.  When loading the Rodauth into
-  your Roda app, specify the :csrf=>:route_csrf plugin option
-  so that Rodauth will load the route_csrf plugin instead of
-  the csrf plugin.
-
-* The use_request_specific_csrf_tokens? configuration option
-  has been added, it defaults to true when the the
-  :csrf=>:route_csrf option is used when loading the plugin.
-
-* If you have custom templates for the reset password request,
-  unlock account request, or verify account resend link
-  request, you will have to update them to use the new
-  request-specific CSRF token feature.
-
-= Backwards Compatibility
-
-* The csrf_tag configuration method now accepts the path as
-  an optional argument, previously it accepted no arguments.
-  The optional argument defaults to the path of the current
-  request.

data/doc/release_notes/1.18.0.txt

@@ -1,26 +0,0 @@
-= New Features
-
-* flash_error_key and flash_notice_key configuration methods have
-  been added for setting the keys used in the flash hash.
-
-* A confirm_password_redirect_session_key configuration method was
-  added for configuring the session key used for storing the
-  confirm password redirect.
-
-= Other Improvements
-
-* Support for the new Roda sessions plugin has been added. Rodauth
-  now recognizes the :sessions_convert_symbols Roda application option
-  and will default to using string keys instead of symbol keys for
-  session and flash values if the application option is set.
-
-= Backwards Compatibility
-
-* If the :sessions_convert_symbols Roda application option is used,
-  and the jwt feature is used and the jwt_symbolize_deeply?
-  configuration method is not used, then the session data will not
-  have the top-level data converted to symbols.
-
-* If the Roda application defines a clear_session method in the scope,
-  that method is now called by Rodauth to clear the session data. This
-  is for better integration with the Roda sessions plugin.

data/doc/release_notes/1.19.0.txt

@@ -1,116 +0,0 @@
-= New Features
-
-* An email_auth feature has been added, which allows passwordless
-  logins using links sent via email.  This allows usage without any
-  password storage.  If the user does not have a password, when they
-  submit their login, they are sent a link via email.  If the user
-  has a password, they have the option of either entering their
-  password or being sent a link via email.
-
-* A use_multi_phase_login? configuration method has been added.  If
-  this configuration method is set to true, a two-phase login is used,
-  which the login form only has a field for a user's login.  After the
-  login form has been submitted (assuming there is a valid login), a
-  form is displayed with a field for the password.
-
-* Optional email rate limiting is now supported in the lockout,
-  reset_password, and verify_account features, using the following
-  configuration methods:
-
-  * account_lockouts_email_last_sent_column
-  * reset_password_email_last_sent_column
-  * verify_account_email_last_sent_column
-
-  These methods are nil by default.  To enable rate limiting, set
-  these to a symbol representing the column name in the appropriate
-  table.  The recommended column name is email_last_sent.  To use
-  this feature, you'll have to add this column to the appropriate
-  tables:
-
-    DB.add_column :account_lockouts, :email_last_sent, DateTime
-    DB.add_column :account_password_reset_keys, :email_last_sent, DateTime,
-      :null=>false, :default=>Sequel::CURRENT_TIMESTAMP
-    DB.add_column :account_verification_keys, :email_last_sent, DateTime,
-      :null=>false, :default=>Sequel::CURRENT_TIMESTAMP
-
-  When this support is enabled, by default Rodauth will not send
-  an email if an email has been sent within the last 5 minutes. You
-  can change this time period using the following configuration
-  methods, which take the number of seconds that must have elapsed
-  before sending another email:
-
-  * unlock_account_skip_resend_email_within
-  * reset_password_skip_resend_email_within
-  * verify_account_skip_resend_email_within
-
-  The new email_auth feature also supports email rate limiting, and
-  because there are no backwards compatibility issues, the support
-  is enabled by default.
-
-* An after_account_lockout configuration method has been added,
-  which is called directly after locking out an account.  This can
-  be useful for audit logging.
-
-* A default_post_email_redirect configuration has been added, which
-  sets the default for all redirects after emailing if the account
-  is not currently logged in.  Each individual feature that emails
-  still supports the appropriate *_redirect configuration method
-  for specifying behavior for that feature.
-
-* A verify_login_change_duplicate_account_redirect configuration
-  method has been added for where to redirect if a user attempts
-  a login change where the new proposed login already exists.
-
-* before_verify_login_change_email and after_verify_login_change_email
-  configuration methods have been added for executing code before
-  or after the verify login change email is sent.
-
-= Other Improvements
-
-* When using the verify_login_change feature, Rodauth now checks
-  that the new login is not already taken and fails in a more
-  graceful manner.  Previously, Rodauth would not report an
-  error when the login change was requested, and would raise an
-  exception when attempting to verify the login change due to the
-  violation of a uniqueness constraint.
-
-* Rodauth now avoids unnecessary database queries when using the
-  two factor authentication support and the following methods:
-
-  * authenticated?
-  * require_authentication
-  * require_two_factor_setup
-
-* The otp-setup template now looks nicer when using both Bootstrap
-  3 and 4, especially on small screens such as phones.
-
-* If the database_type was not MySQL, the lockout, remember, and
-  reset_password features no longer disable the requiring of the
-  date_arithmetic Sequel extension if another feature that
-  requires the extension is used.
-
-* On MySQL, the rodauth_get_salt database function definition now
-  handles accounts without passwords.  If you previously added the
-  database function and want to support accounts without passwords,
-  then you should drop the function and re-add it via:
-
-    Rodauth.drop_database_authentication_functions(DB)
-    Rodauth.create_database_authentication_functions(DB)
-
-  Note that MySQL does not support CREATE OR REPLACE FUNCTION, so
-  you have to drop the function and then create it, which will
-  temporarily result in the function not being defined.
-
-= Backwards Compatibility
-
-* The before_otp_authentication_route configuration method is
-  deprecated, please switch to before_otp_auth_route instead. This
-  change is made so that before_*_route method names are consistent
-  with the route name.
-
-* The verify_account_email_sent_redirect configuration method now
-  defaults to / instead of /login.  If you were previously not
-  setting this configuration method and would like it to default to
-  /login, you will now have to force the setting:
-
-    verify_account_email_sent_redirect '/login'

data/doc/release_notes/1.2.0.txt

@@ -1,18 +0,0 @@
-= New Features
-
-* An otp_drift configuration method has been added to the otp plugin,
-  which allows you to set the number of seconds of allowed drift. This
-  makes the otp plugin easier to use if the client and server do not
-  have good synchronize to the same time source.
-
-= Other Improvements
-
-* Passwords containing the ASCII NUL character "\0" are no longer
-  allowed, as bcrypt truncates the password at the first NUL
-  character.
-
-  Note that bcrypt only uses the first 72 characters of the password
-  when constructing the hash, but Rodauth does not enforce a limit
-  of 72 characters.  If you want to enforce a maximum password length
-  in your application, use the password_meets_requirements?
-  configuration method with a block and call super inside the block.

data/doc/release_notes/1.20.0.txt

@@ -1,175 +0,0 @@
-= New Features
-
-* An hmac_secret configuration method has been added.  If set,
-  Rodauth will use HMACs for all of the tokens that Rodauth creates.
-  By using HMACs for the tokens, even if the database storing the
-  tokens is compromised (e.g. via an SQL injection vulnerability), the
-  tokens stored in the database will not be usable without knowledge
-  of the HMAC secret.
-
-  The following features are affected by setting the hmac_secret
-  configuration method:
-
-  * email_auth
-  * lockout
-  * otp
-  * remember
-  * reset_password
-  * single_session
-  * verify_account
-  * verify_login_change
-
-  To allow for graceful transition when adding hmac_secret to an
-  existing Rodauth installation, you can use the
-  allow_raw_email_token? configuration method to keep allowing
-  raw tokens.  However, you should remove the allow_raw_email_token?
-  setting after the existing tokens have expired (most tokens expire
-  after 1 day by default).  Verify account tokens do not expire,
-  but users can request a new verify account token if their token has
-  expired.
-
-  For remember tokens, the raw_remember_token_deadline configuration
-  method can be used, which will only allow the use of raw remember
-  tokens before the given deadline, which should be the time in the
-  future when you want to no longer accept raw remember tokens.  You
-  can remove this configuration method after the deadline has passed.
-  By default, the deadline should be set to 14 days after the time
-  you enable hmac_secret, since remember tokens expire in 14 days by
-  default.
-
-  Similarly, in the single_session feature, you can use the
-  allow_raw_single_session_key? configuration method to allow raw
-  single session keys.
-
-  In the otp feature, you cannot mix HMAC and non-HMAC tokens. If
-  the hmac_secret setting is enabled and there are any existing
-  otp tokens already setup, they will stop working.  If you are
-  already using the otp feature and would like to use the hmac_secret
-  configuration method, you need to set the otp_keys_use_hmac?
-  configuration method to false unless you want to invalidate all
-  existing otp tokens.
-
-  The hmac_secret configuration is also used during OTP setup 
-  in the otp feature, to ensure that the OTP secrets for two factor
-  authentication came from the server and were not modified by the
-  user.  If hmac_secret is used, setting up OTP via JSON requires
-  sending a POST request to the otp-setup route.  This request will
-  fail, but included in the response will be the OTP secret and raw
-  OTP secret to use.  Submitting a POST request including the OTP
-  secret and raw OTP secret will allow OTP setup to complete.
-
-* A jwt_refresh feature has been added.  This uses the jwt feature,
-  and issuing short-lived JWTs with exp, iat, and nbf claims, with a
-  database-backed refresh token for issuing another short-lived JWT.
-  The refresh tokens will automatically use HMACs if the hmac_secret
-  configuration method is set.
-
-* Rodauth's handling of form errors is now accessible by default.
-  aria-invalid attributes are now used on all input fields with
-  errors, and aria-describedby attributes are used to tie the input
-  fields to the error messages.
-
-* All hard coded strings are now overridable via configuration
-  methods, with the following configuration methods added:
-
-  * lockout feature
-    * unlock_account_explanatory_text
-    * unlock_account_request_explanatory_text
-  * login_password_requirements_base feature
-    * already_an_account_with_this_login_message
-  * otp feature
-    * otp_provisioning_uri_label
-    * otp_secret_label
-  * recovery_codes feature
-    * add_recovery_codes_heading
-  * reset_password feature
-    * reset_password_explanatory_text
-  * verify_account feature
-    * verify_account_resend_explanatory_text
-
-* The following configuration methods have been added to the base
-  feature, related to customization of input fields in Rodauth forms:
-
-  default_field_attributes :: The default attributes to use for input
-                              field tags, if field_attributes does not
-                              handle the field.
-  field_attributes(field) :: The attributes to use for input fields
-                             with the given parameter name.
-  field_error_attributes(field) :: The attributes to use for input
-                                   fields with the given parameter
-                                   name if the field has an error.
-  formatted_field_error(field, error) :: HTML to use for the given
-                                         parameter name and error
-                                         text.  Uses a span by
-                                         default.
-  input_field_error_class :: The CSS class to add for input fields
-                             with errors.
-  input_field_error_message_class :: The CSS class to add for error
-                                     message spans.
-  input_field_label_suffix :: Adds suffix to all input field labels
-  login_input_type :: The input type to use for login fields.
-                      Defaults to text, but can be set to email,
-                      though that is currently a bad idea if you
-                      want the login fields to have accessible error
-                      handling.
-  mark_input_fields_as_required? :: Whether to mark all input fields
-                                    as required by default. Note that
-                                    this is currently a bad idea if
-                                    you want the fields to have
-                                    accessible error handling.
-
-= Other Improvements
-
-* rotp 5 is now supported in the otp feature.  Previous rotp versions
-  down to rotp 2.1.1 remain supported.
-
-* Performance of Rodauth routes has been improved by using defined
-  methods instead of instance_exec for route dispatching.  Internal
-  unnecessary uses of instance_exec have also been removed for
-  performance reasons.
-
-* When the disallow_password_reuse feature is used without the
-  verify_account feature, and account_password_hash_column
-  configuration is not used, Rodauth no longer tries to call a method
-  that does not exist.
-
-* When using the disallow_password_reuse and verify_account features,
-  with verify_account_set_password? set to true, Rodauth skips adding
-  an empty password to the list of previous passwords.
-
-* Rodauth now avoids an unnecessary DELETE query in the
-  disallow_password_reuse feature if there are no previous passwords.
-  
-* The otp-auth-code field now has an autocomplete=off attribute.
-
-* On Ruby 1.8, new tokens now use URL safe base64 encoding, instead
-  of hex encoding.  Rodauth has always used URL safe base64 encoding
-  for new tokens on Ruby 1.9+.
-
-= Backwards Compatibility
-
-* The following configuration methods have been renamed:
-
-  * email_auth feature
-    * no_matching_email_auth_key_message =>
-      no_matching_email_auth_key_error_flash
-  * lockout feature
-    * no_matching_unlock_account_key_message =>
-      no_matching_unlock_account_key_error_flash
-  * reset_password feature
-    * no_matching_reset_password_key_message =>
-      no_matching_reset_password_key_error_flash
-  * verify_account feature
-    * attempt_to_create_unverified_account_notice_message =>
-      attempt_to_create_unverified_account_error_flash
-    * attempt_to_login_to_unverified_account_notice_message =>
-      attempt_to_login_to_unverified_account_error_flash
-    * no_matching_verify_account_key_message =>
-      no_matching_verify_account_key_error_flash
-  * verify_login_change feature
-    * no_matching_verify_login_change_key_message =>
-      no_matching_verify_login_change_key_error_flash
-      
-  Attempts to use the old method at configuration time, or calling
-  the method on the rodauth object at runtime, will result in a
-  deprecation warning.

data/doc/release_notes/1.21.0.txt

@@ -1,12 +0,0 @@
-= Improvements
-
-* rotp 5.1 is now supported in the otp feature.  Previous rotp
-  versions down to rotp 2.1.1 remain supported.
-
-* When using the otp feature without the sms or recovery_codes
-  features, if an account gets locked out from OTP authentication due
-  to multiple invalid OTP authentication codes, automatically log
-  them out, and redirect them to the login page.  Previously, the
-  default behavior in this case could be a redirect loop if OTP
-  authentication is required for the user on the default_redirect
-  page.

data/doc/release_notes/1.22.0.txt

@@ -1,11 +0,0 @@
-= New Features
-
-* A jwt_cors feature has been added, handling Cross-Origin Resource
-  Sharing when using the jwt feature, including supporting CORS
-  preflight requests.
-
-= Other Improvements
-
-* Mail templates that include links (e.g. for verifying accounts),
-  now add a space after the link and before the newline, fixing
-  issues with some web mail providers that have broken auto-linkers.

data/doc/release_notes/1.23.0.txt

@@ -1,32 +0,0 @@
-= New Features
-
-* When the email_auth feature is used, the link to request email
-  authentication is now displayed if the user inputs an incorrect
-  password.  Previously, it was only shown if the user had not
-  yet entered a password.
-
-* A send_email configuration method has been added, which can be
-  overridden to customize email delivery (such as logging such
-  email). The configuration method block accepts a Mail::Message
-  argument.
-
-* All rodauth.*_route methods that return the name of the route
-  segment now have rodauth.*_path and rodauth.*_url equivalents,
-  which return the path and URL for the related routes, respectively.
-  The rodauth.*_path methods are useful when constructing links to
-  the related Rodauth pages on the same site, and the rodauth.*_url
-  methods are useful for constructing link to the Rodauth pages from
-  other sites or in email.
-
-= Other Improvements
-
-* Specs have been removed from the gem file, reducing gem size by
-  over 20%.
-
-* rodauth.authenticated? now returns true on the OTP setup page
-  when using the otp feature.  Previously, this method returned
-  false on the OTP setup page.  However, as the user has not yet
-  setup OTP when viewing this page, they should be considered
-  fully authenticated, as they would be if they viewed any other
-  page before setting up OTP.  This change probably only affects
-  cases where the layout uses rodauth.authenticated?.

data/doc/release_notes/1.3.0.txt

@@ -1,21 +0,0 @@
-= New Features
-
-* A login_maximum_length configuration method has been added.  This
-  defaults to 255, and rodauth will now show an error message if a
-  user tries to create a login longer than this setting.
-
-= Backwards Compatibility
-
-* Rodauth's documentation and test code now use :Bignum instead of
-  Bignum for database-independent 64-bit integer types.  This is
-  because using Bignum is now deprecated in Sequel as it will stop
-  working correctly in ruby 2.4+, due to the unification of Fixnum
-  and Bignum into Integer.
-
-  Rodauth's library code does not use either :Bignum or Bignum, but if
-  you are starting to use Rodauth and are copying the example
-  migration from Rodauth's documentation, or you are running the
-  migrations in Rodauth's tests, you now need to use Sequel 4.35.0+.
-
-* Some files related to the hosting of the demo site on Heroku have
-  been removed from the repository.

data/doc/release_notes/1.4.0.txt

@@ -1,11 +0,0 @@
-= New Features
-
-* A update_password_hash feature has been added, which will update
-  the password hash for the account whenever the account's current 
-  password hash has a cost different from the currently configured
-  password hash cost.
-
-  This allows you to increase the password hash cost for all
-  accounts or for certain types of accounts, and have the password
-  hashes automatically updated to use the new cost the next time the
-  correct password is provided for the account.