Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

authenticate_otp now returns timestamp or nil instead of boolean #57

Closed
asehra opened this issue Jun 27, 2019 · 5 comments
Closed

authenticate_otp now returns timestamp or nil instead of boolean #57

asehra opened this issue Jun 27, 2019 · 5 comments

Comments

@asehra
Copy link

asehra commented Jun 27, 2019

ROTP changed their implementation of verify to return timestamp (eg 1561654770) when the otp is valid and nil otherwise instead of a true or false. README still says that authenticate_otp returns true or false.

@Pahicz
Copy link

Pahicz commented Jul 12, 2019

Is it ok, that I get 0 as return value? I am using counter based OTP.

@mamaremere
Copy link

@Pahicz , it seems that for counter based OTP, ROTP returns the value of the counter instead of the timestamp. nil still means that the token is not verified. Here's the documentation from ROTP: https://github.com/mdp/rotp#counter-based-otps

@imrubyist
Copy link

We run through this problem too. Getting a timestamp or nil (when it should be false). Any update or workaround for this?

@mamaremere
Copy link

@kevinhq , this gem, active_model_otp respects the response received from rotp, the gem that does all the heavy-lifting:

For time-based tokens, rotp will return an integer timestamp for success or nil for failure.

For counter-based tokens, rotp will return the current count for success or nil for failure.

The docs on this gem should probably be updated, but I don't see much activity from the maintainer.

@pedrofurtado
Copy link
Collaborator

PR #85 merged 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants