3.0.0.alpha2 #368
3.0.0.alpha2 #368
Conversation
* WIP: Relying Party model * fixup! WIP: Relying Party model * refactor: make `WebAuthn.configuration` a wrapper for a `RelyingParty` instance * fixup! refactor: make `WebAuthn.configuration` a wrapper for a `RelyingParty` instance * refactor: delegate Configuration methods * refactor: always pass a RelyingParty * use relying party on when creating options * refactor: remove unnecessary aliases * fix: make reader private * refactor: make parent class AuthenticatorResponse responsible for relying party * fix: post rebase fixes * test: get rid of all keyword 2.7 warnings * fix: rebase trailing diff * fix: make rubocop happy * fix: make AttestationObject#deserialize accept relying_party param * refactor: algorithm validation uses relying party configuration * fix: make RP initializer use finders setter to process params correctly * fix: cache store should recieve origin from server * refactor: CR comments on API flexibility * refactor: CR comments * test: add functional comprehensive test for multiple RPs and a default configuration * refactor: Allow #verify_authentication to be used with or without a block * style: fix rubocop Co-authored-by: Braulio Martinez <[email protected]>
Not sure how 2f54c92 passed CI for Ruby 2.4, since lib/webauthn/relying_party.rb uses Hash#slice which was introduced in 2.5. By now 2.4 has been end-of-life for two years and I don't think it's worth any further investigation.
|
@brauliomartinezlm @grzuy 👋 long time no speak. Any concerns with the master branch targeting a 3.0 alpha, now that there's a |
|
What's not clear to me is why was this reverted in the last attempt? Can we ensure we have specs that account for whatever the issue was previously? I'm happy to help test if we can understand that. |
|
Hey @bdewater I'm definitely onboard on doing this. I'll take a look at the PR during the weekend and we can merge it. Thank you for opening this PR! Long time indeed :).
@Brantron there's actually no issue with version 3. We were waiting for a long time for signals that the new API was a good move from the gem users (regardless of being backwards compatible). That never came in the form we expected and it was more of a long process where I think now we have enough proof of adoption of v3. That being said, all testing and being extra careful is highly appreciated given the sensitivity of our beloved gem 🙏 |
|
@bdewater did you have any issues between v3 and all the things that made it to 2-stable for the openssl3 upgrade? |
|
@brauliomartinezlm none 😄 after fixing the merge conflicts, the only test suite failures that I remember needing a closer look were the |
There was a problem hiding this comment.
I'm all in with merging this. Left you a minor comment. I'll cut the release for alpha 2 once you merge it. I'll leave you the honors @bdewater
Thank you sooooo much 🙌
bdewater
force-pushed
the
relying_party-3.0
branch
from
324f7ce
to
d58add5
Compare
|
Thanks for getting this merged in folks. I'm super pumped to start using the new release 🥳 |
|
Just released 3.0.0.alpha2 🎉 . Sorry for the delay 🙏 |
This is a rebase of #296 on top of the current master branch, addressing the concerns from #367 that one would have to pick between either the OpenSSL 3.0 compatibility or support for multiple relying parties.
While I was here I bumped the minimum Ruby to 2.5 for a green build.