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

metadata: Make unmarshalMDSBLOB public/exported #247

Open
iaburton opened this issue Jun 17, 2024 · 3 comments
Open

metadata: Make unmarshalMDSBLOB public/exported #247

iaburton opened this issue Jun 17, 2024 · 3 comments
Labels
status/needs-triage Issues that need to be triaged. type/feature-request Feature Requests

Comments

@iaburton
Copy link

iaburton commented Jun 17, 2024

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 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

  1. For development, caching the blob locally instead of reading it remotely each time would save on network traffic.
  2. 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.
  3. 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

@iaburton iaburton added status/needs-triage Issues that need to be triaged. type/feature-request Feature Requests labels Jun 17, 2024
@james-d-elliott
Copy link
Member

Take a look at #239 which may satisfy some or all of this. We're reworking it to be more useful long term.

@iaburton
Copy link
Author

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.

@james-d-elliott
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status/needs-triage Issues that need to be triaged. type/feature-request Feature Requests
Projects
None yet
Development

No branches or pull requests

2 participants