-
Notifications
You must be signed in to change notification settings - Fork 9
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
Add HOTP algorithm #106
Add HOTP algorithm #106
Conversation
…econditions for HOTP digits
I have a PR for TOTP cooking as well, but I'm still figuring out how to test it as it's implemented using |
Yes, the initial time will be Then you can do |
Does that mean that you cannot test with |
Note you can always upgrade a |
require(digits >= 6, s"digits must be at least 6, was $digits") | ||
require(digits < 10, s"digits must be less than 10, was $digits") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's wrap this in F.catchNonFatal
so that errors suspend properly into F
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, why do we need Sync
here? Would Functor
be enough? In which case you can leave the require
as-is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there's a design question here whether we need an Hotp
capability trait actually since it's not hiding bigger constraints. We could implement these as methods on an object, that take Functor
and Hmac
constraints. I'd need to look to other Typelevel libs for inspiration on the right way to do this :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should there possibly be effectful equivalents of require
, assume
and assert
in cats-effect Sync
? It's the lowest part of the Typelevel hierarchy that has knowledge that E
is Throwable
and can raiseError
I think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, that's interesting :) We have ApplicativeThrow#catchNonFatal
and there may be similar methods in there.
Hmm I don't really know what to do with this test failure. I don't get the same failure locally and there is no actual output from the failed test in the log. I have not been testing with the Chrome JSEnv locally and that seems to be the one that is failing in these test runs but I know very little about Scala.js.
|
This comment was marked as resolved.
This comment was marked as resolved.
Oh, in my case it's just that I haven't used chromedriver for ages so it's out of date, never mind - I get the same thing as the CI server, "tests unsuccessful" but with no output related to those tests:
|
Yup, sorry, you are stumbling into scalameta/munit#492. Anyway, did you mention you are running the tests with However, Node.js supports sync and async crypto via different APIs. This is why I was running the tests with both |
@armanbilge I think the tests on this PR were failing for the same reason as #108 |
You mean because of the old Node.js? I thought the tests were failing in the browser. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice addition, thank you!
Co-authored-by: Arman Bilge <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fantastic! 😃
I couldn't resist adding this since it's very easy if HMAC is already there 😛