ES version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
88% Positive
Analyzed from 953 words in the discussion.
Trending Topics
#com#domain#password#txt#known#verification#ycombinator#google#https#discord
Discussion (24 Comments)Read Original on HackerNews
Let's stop polluting the root of a domain!
[1] https://llmstxt.org/
Why password-reset instead of a more generic link tree?
Why discord domain verification instead of domain-verifications with a dynamic list on entries?
Seems like a waste of time. I would just define my own spec outside of well known for my use case.
That’s on Discord. They’re not in the registry: https://www.iana.org/assignments/well-known-uris/well-known-...
> Why password-reset instead of a more generic link tree?
[edit: answered in more detail in a sibling thread https://news.ycombinator.com/item?id=48596286]
The TXT record itself is already a dynamic list of entries. It's far simpler and easier to iterate through the list and compare the start of each value with your search string until you find "discord domain verification" directly than it would be to do anything else.
Example:
At the very least, it should be "domain-verification-discord", "-google" and so on. Maybe even "-com.discord", "-com.google"? And the first part clearly standardized and registered, instead of one entity using "domain" and another one "site".
The password-reset well-known endpoint is used by password managers to show a "Change password..." button in their interface, which magically links to the password change page described in that well-known file.
Anyway discord domain verification can tell in their onboarding docs to put it anywhere. It being well known does nothing. If there was a root level domain verification, then you might as well put it under that. But otherwise why go through a process?
> I guess the more flexible it is, the harder adoption becomes
Yeah. If there is one account management related URL that password managers care about, it’s the change password page. You don’t really need to change email on your account that often, but it is probably a good idea to rotate your password once in a while. So I guess it’s a good idea to make it as easy as possible to adopt – which means just a single URL redirecting to another.
> If the website implements it.
That’s a good catch, though. I guess right now password managers would still have to make a “preflight” request just to see if /.well-known/change-password is implemented before showing it to the user. (But that can go away if most websites adopt it.)
I did read one before while working with github oidc, and I did find it very useful.
What is it with technical documentations that go deep describing what it is in plenty words but refusing to give a single example? This far from the first case I've ran into either.
Here's one I could find: https://accounts.google.com/.well-known/openid-configuration
But how does one even find this?
In the latter case you just probe, for instance if you’re a password manager and you have a password for site A you hit A/.well-known/change-password and if they returns something you can surface a change password link to your user.
The one you found is for OIDC provider discovery (https://openid.net/specs/openid-connect-discovery-1_0.html#P...) so someone tells you they want to log in via Google, you hit that endpoint, and it lets you setup Google as an oidc provider rather without needing to hard-code providers. Even if you just want to support Google as a provider, you hit that and you get the entire configuration rather than have to hunt down the same information in the docs.