Can't get through login using fido2 version 3.0.1

Question

Can't get through login using fido2 version 3.0.1

DevOnBike opened this issue 7 months ago · 3 comments

Hi

currently I am using packages in following version

so when I run demo version from github (code downloaded from this repo) i can perfectly go through demo:
http://localhost:4729/custom#heroFoot

but when I get same code and replace references in demo project with nuget packages i can't through sign in process.
why ? because google browser requires me to use usb key instead windows hello.
why ? because models between demo version in repo and in nugets are different
why ? don't know but it is even hard to anyhing about it because models are marked as sealed for some reason, this is big no no for me, just check IFido2->GetAssertionOptions class AuthenticationExtensionsClientInputs

so from my analisis this class in nuget is missing DevicePubKey property:
https://github.com/passwordless-lib/fido2-net-lib/blob/master/Src/Fido2.Models/Objects/AuthenticationExtensionsClientInputs.cs#L48

so i think that making class sealed when name is stating clearly it is an extensions smells for me like s**t.

Can u do something about it ?

Answer 1 · 2024-02-26T13:50:26.000Z

Hey @DevOnBike, I'm going to entertain your ask for help, but first let me inform you that this is a free library maintained by me and others in our free time. Calling our free work that you are benefiting from s**t is very entitled of you.

If you want help figuring out why things are not working for you, you need to share a lot more of your context, like what version of a nuget package you are using in your project, and what version of the demo you are using. As you might be able to tell from looking at tags/releases, this main branch contains many changes from when 3.0.1 was realsed.

We seal these classes by default because it gives consumers a performance boost and there are very little reason for a consumer to extend/change these classes that are consumed by the library/specification it self.

so i think that making class sealed when name is stating clearly it is an extensions smells for me like s**t.
Can u do something about it ?

Just because the name contains extension doesn't mean you should be able to extend the class. Unless there are meaningful reasons, we won't change it from sealed.

Answer 2 · 2024-02-26T22:59:15.000Z

Hey @DevOnBike, I'm going to entertain your ask for help, but first let me inform you that this is a free library maintained by me and others in our free time. Calling our free work that you are benefiting from s**t is very entitled of you.

I think u didn't read carefouly what I have written, i didn't mention that this library is a s^t, probably oposit but I have spent so much time figuring out what is wrong that this literally drives me crazy.

If you want help figuring out why things are not working for you, you need to share a lot more of your context, like what version of a nuget package you are using in your project, and what version of the demo you are using. As you might be able to tell from looking at tags/releases, this main branch contains many changes from when 3.0.1 was realsed.

version of nuget i have provided in a issue title,
demo: https://github.com/passwordless-lib/fido2-net-lib/tree/master/Demo

We seal these classes by default because it gives consumers a performance boost and there are very little reason for a consumer to extend/change these classes that are consumed by the library/specification it self.

I think using sealing classes as a performance boost is negligible as u probably degrading performance in other places of code like verification logic by throwing exceptions, not disposing disposables with using construct and even working with wrong way with x509certificate2 which can lead users on Windows with eventually disk full of trash certs.

so i think that making class sealed when name is stating clearly it is an extensions smells for me like s**t.
Can u do something about it ?

Just because the name contains extension doesn't mean you should be able to extend the class. Unless there are meaningful reasons, we won't change it from sealed.

naming class as an extension means clearly that purpose of this structure is to enable some point of extensibility to users, when thay need this, sealing extensible class makes little sense as I found out that it needs extension comparing demo to nuget package. So efectively your stubborn approch will lead to delaying use of your library in current shape and let people wait for new improved version or they will fork your code and fix themselves or better they will switch to other libraries that are available in nuget repo. up 2 u of course, but if u share your code to public, always be prepared for some comments. I think it is overall great work of yours but for my version of demo code and nuget it needs some fixes. Just try to run demo with references switched to given version of nuget lib and u will for sure find out that code will not compile.

Answer 3 · 2024-02-27T09:40:07.000Z

not disposing disposables with using construct and even working with wrong way with x509certificate2 which can lead users on Windows with eventually disk full of trash certs

I'd welcome additional issues & PR's to make this better.

If you wish to pair up the Demo with a specific nuget package version, I suggest you align them using the git tags. Master does not align with 3.0.1.

Here is what the demo looks like for 3.0.1: https://github.com/passwordless-lib/fido2-net-lib/tree/v3.0.1/Demo

I would point out that you're probably better off using the beta packages on nuget and aligning on the corresponding beta tag in github.

I think that will sort of out your issues, good luck!

naming class as an extension means clearly that purpose of this structure is to enable some point of extensibility to users, when thay need this, sealing extensible class makes little sense as I found out that it needs extension comparing demo to nuget package

We align with the naming in the W3C specification, where the name "extension" is used because these are extensions of the specification, which may or may not be implemented by clients. There behaviour is still defined in the spec and should reasonably not be extended by developers consuming this library, unless there is a very specific reason to allow it.