**Why**:
When looking up a class with `Object.const_defined?`, `false` will be
returned the first time it is called, even when the class exists in the
Rails app. I think this might be due to the way Rails loads classes.
**How**:
Use `ActiveSupport::Inflector#constantize`, which returns the class all
the time when the class exists, and throws a `NameError` when it
doesn't.
The only way I was able to properly test this was to create the
`UserOtpSender` class as a real file in the test Rails app, and create
a Devise Admin user to test the scenario where `AdminOtpSender` does
not exist.
I verified that with the old code, `reset_otp_state` was not being
called when it should be, and that the new code makes the tests pass.
**Why**:
The `encryptor` gem, which is used for the new OTP encryption feature,
requires Ruby 2.0 or later.
Also, Rails 5.0 requires Ruby 2.2.2 or greater, so we need to ignore
1.9.3, 2.0, and 2.1 when running RAILS_VERSION=master on Travis.
The `user` variable was not defined in some specs.
I also removed the error message for the `ArgumentError` spec because
it's different depending on the Ruby version.
**Why**:
To make it easy for people to see what has changed in each release
**How**:
Use the awesome github_changelog_generator to automatically create the changelog for each release based on GitHub issues and pull requests.
**Why**:
To provide an additional layer of security.
The TOTP spec (RFC 6238) recommends encrypting the keys.
http://tools.ietf.org/html/rfc6238
**How**:
Borrow the encryption code from the `attr_encrypted` gem and use it to
encrypt and decrypt the `otp_secret_key` attribute.
Allow users to add encryption by passing in `encrypted: true` to
`has_one_time_password`. This provides backwards-compatibility for
existing users of the gem.
See the README updates for more detailed instructions for both new
and existing users.
**Why**
In some cases, it might be necessary to run some code right after the user signs in, but before the OTP is sent, and also right before a user signs out.
For example, consider this scenario:
- The app requires the user to confirm their phone number before it gets saved. This confirmation is done by sending an OTP to the phone and asking the user to enter it.
- User mistypes the number, then closes the anonymous browser window, or signs out before confirming
- User signs back in, and OTP is sent to the mistyped number. User is now unable to fully sign in since the OTP is being sent to the wrong number
In order to prevent this scenario, we need to be able to reset the `unconfirmed_mobile` to nil before the OTP is sent, and before they sign out so that they can type it in again.
**How**
Allow the gem user to define an OtpSender class with a `reset_otp_state` method
**Why**:
I noticed that recent builds started failing on Travis for no apparent reason. I then saw that Travis was using a different version of bundler compared to builds from 2 months ago. This version of bundler seems to be incompatible with certain versions of Ruby.
By making sure bundler is up to date, it allows Travis to install the gems on all the versions of Ruby that this repo supports.
This makes the gem store a signed cookie for a configurable amount of
time that allows the user to bypass 2FA. Our use-case for this is that
we expire user’s Devise sessions after 12 hours, but don’t want to
force them to authenticate using 2FA every day.
Signed cookies are available since Rails 3. This requires the signing
functionality to be properly configured, but is disabled by setting the
config variable to `0`, the default.
Storing just request.path drops the query string which makes two factory
authentication less useful when the guarded page needs those parameters.
This brings the two factor authentication redirect behavior in line with
devise's.
Moncef Belyamani
Moncef Belyamani
Dmitrii Golub
Adam Magnier
Kevin Pheasey
Kopylov German
Paul Bowsher
JD Trout
The Gitter Badger
Dave Riess
amoose
Denis Savitsky
Albert J. Wong
Jack Turnbull