You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was looking at adding bits of the metadata package to my service for showing names & descriptions of registered authenticators (via aaguid). As far as I know the correct way for doing this is with the FIDO MDS service which is usable via the metadata package with the ProductionMDSURL const and the PopulateMetadata function.
However the options to the latter are few, it uses a hardcoded http.Client followed by a io.Readall (which is generally something I'd recommend against).
It looks like there is a private function that could be exposed to allow more uses cases, that function being unmarshalMDSBLOB for use cases I've listed below.
PS: I don't mind submitting a MR for this as it's a relatively easy change. Or perhaps there is another reason this functionality wasn't already exposed in the metadata package? I searched existing/previous issues and didn't see anything on this.
Thank you!
Use Case
For development, caching the blob locally instead of reading it remotely each time would save on network traffic.
The ParseMetadata function loads the data into a global variable in an unsafe way (mostly concurrency issues). Perhaps the client would like to parse/load some or all of the data into state stored elsewhere.
unmarshalMDSBLOB doesn't appear to use the http.Client it is being passed. Plus if it were exposed the blob could be retrieved using a custom http.Client or other method (before being passed to the unmarhal function).
Documentation
No response
The text was updated successfully, but these errors were encountered:
Ah, you're correct, that looks like it would take care of this and then-some. Apologizes as I completely missed taking a look at the PRs before making this. Thanks for the info and quick reply.
No worries at all. I just didn't have time to confirm it matched all your needs until the weekend.
The general idea is to offload the elements that are just an implementation detail and give implementers the control over the domain logic since I can't account for every environment. With that design I think the implementer can accomplish everything they need to do to perform any form of decoding, caching, or locking they desire.
Description
Hello!
I was looking at adding bits of the metadata package to my service for showing names & descriptions of registered authenticators (via aaguid). As far as I know the correct way for doing this is with the FIDO MDS service which is usable via the metadata package with the
ProductionMDSURL
const and thePopulateMetadata
function.However the options to the latter are few, it uses a hardcoded http.Client followed by a
io.Readall
(which is generally something I'd recommend against).It looks like there is a private function that could be exposed to allow more uses cases, that function being unmarshalMDSBLOB for use cases I've listed below.
PS: I don't mind submitting a MR for this as it's a relatively easy change. Or perhaps there is another reason this functionality wasn't already exposed in the metadata package? I searched existing/previous issues and didn't see anything on this.
Thank you!
Use Case
ParseMetadata
function loads the data into a global variable in an unsafe way (mostly concurrency issues). Perhaps the client would like to parse/load some or all of the data into state stored elsewhere.unmarshalMDSBLOB
doesn't appear to use the http.Client it is being passed. Plus if it were exposed the blob could be retrieved using a custom http.Client or other method (before being passed to the unmarhal function).Documentation
No response
The text was updated successfully, but these errors were encountered: