Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

So You Want to Define a Well-Known URI

mnot.net

Post reply on HN
Print view View original

21–30 of 105 posts

Re: So You Want to Define a Well-Known URI

#21

Post by notpushkin »

jvuygbbkuurx wrote: post #7
reddalo wrote: post #4

Earlier quoted context omitted.

Your own spec wouldn't be used by anyone else. 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.

If the website implements it. What about email preferences? Removing account links? There are many use-cases you might want to redirect a user to, but having to make their own well known for it seems dumb instead of using a more generic one. I guess the more flexible it is, the harder adoption becomes as the usage within a spec might diverge, or it grows outside of the spec and becomes unofficial. So maybe password-r…

It’s just easier for everybody to implement. Password manager opens https:///.well-known/change-password in the user’s browser, it gets redirected to the actual page where password change form is located. You could make the password manager look it up in a link tree and then open a correct page, yes, but...

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

Re: So You Want to Define a Well-Known URI

#22

Post by echoangle »

asdfasdfadsfs wrote: post #15
timwis wrote: post #6

Earlier quoted context omitted.

I agree. I was hoping for a few positive examples, but didn't see any. The only one I know of is the OIDC discovery endpoint.

I would say acme-challenge is one of the most used ones. How else would one get SSL certificates today

DNS TXT challenge for example. Also better because you can get wildcard certs.

Re: So You Want to Define a Well-Known URI

#23

Post by wseqyrku »

sandblast wrote: post #11

No, in fact I don't. But this post wouldn't be of any help anyway. It feels like it's about nothing, there is no substance, just stating some obvious facts. Without examples that lead to some real recommendations, this whole expertise claimed by the author is of no use.

The point of the post was that you need to add robots.txt (or similar) because it's a thing, and also tell us where they are.

Re: So You Want to Define a Well-Known URI

#24

Post by masklinn »

notpushkin wrote: post #21
jvuygbbkuurx wrote: post #7

Earlier quoted context omitted.

If the website implements it. What about email preferences? Removing account links? There are many use-cases you might want to redirect a user to, but having to make their own well known for it seems dumb instead of using a more generic one. I guess the more flexible it is, the harder adoption becomes as the usage within a spec might diverge, or it grows outside of the spec and becomes unofficial. So maybe password-r…

It’s just easier for everybody to implement. Password manager opens https:// /.well-known/change-password in the user’s browser, it gets redirected to the actual page where password change form is located. You could make the password manager look it up in a link tree and then open a correct page, yes, but... > I guess the more flexible it is, the harder adoption becomes Yeah. If there is one account management relate…

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

It’s not really a catch? Like robots.txt it’s just something you probe if you have the capabilities to use it. You can just cache the info afterwards.

Re: So You Want to Define a Well-Known URI

#26

Post by eschatology »

masklinn wrote: post #16
eschatology wrote: post #12

Earlier quoted context omitted.

Not one of them links to the actual well-known resource, only pdf specifications. And several I picked randomly leads to dead ends. Here's one I could find: https://accounts.google.com/.well-known/openid-configuration But how does one even find this?

well-known is for programmatic access, it either namespaces something you’re told to look for (e.g. various types of domain markers) or it lets you discover a feature / endpoint. 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…

Thank you, that it is part of OIDC provider discovery spec explains a lot.

That said, I still find it very bizzare that it's so hard to find a tangible example to see how it is in practice.

The rfc has none. Another spec including the use of it has none. In the end only completed service provider/implementers show it.

Before programmatic access happens, it needs to be written by a human. Yet the whole thing feels so human-unfriendly.

Perhaps I am biased robots.txt sets a high bar on how easy it is to find and work with?

Re: So You Want to Define a Well-Known URI

#28

Post by networked »

rickette wrote: post #13
reddalo wrote: post #3

I wish people would follow this, instead of coming up with new standards in the root namespace. "llms.txt" [1] comes to mind, for example. Let's stop polluting the root of a domain! [1] https://llmstxt.org/

LLMs.txt is also nonsense since it isn't adopted by any of the major AI players.

Google has recently added `llms.txt` to Chrome's Lighthouse check for agentic browsing (https://searchengineland.com/google-llms-txt-chrome-lighthou...), so adoption may be coming. Admittedly, I put more faith in
that I copied from Gwern.net. This convention is discoverable (just read the HTML) and naturally adapts to any website size and structure.

I have created an `llms.txt` for my website anyhow. I use a fixed LLM prompt to generate it from the internal links in `index.md`.

Re: So You Want to Define a Well-Known URI

#29

Post by russellbeattie »

philipwhiuk wrote: post #25

I'm not sure I like ` https://domain.com/.well-known/robots.txt ` any better frankly

Whoever decided it would be a good idea for ".well-known" to be a "hidden" directory is a complete fool. All it does is provide the opportunity for confusion, misconfiguration, skipped backups, missed git check-ins, forgotten updates and more. Literally the only people a folder like that is hidden from is the whoever is managing the web server.

Sure, if everyone knows what they're doing, it's not a problem. But we all know how long that assumption lasts.

Re: So You Want to Define a Well-Known URI

#30

Post by masklinn »

eschatology wrote: post #26
masklinn wrote: post #16

Earlier quoted context omitted.

well-known is for programmatic access, it either namespaces something you’re told to look for (e.g. various types of domain markers) or it lets you discover a feature / endpoint. 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…

Thank you, that it is part of OIDC provider discovery spec explains a lot. That said, I still find it very bizzare that it's so hard to find a tangible example to see how it is in practice. The rfc has none. Another spec including the use of it has none. In the end only completed service provider/implementers show it. Before programmatic access happens, it needs to be written by a human. Yet the whole thing feels so…

What RFC? The oidc discovery spec has an example, and for change-password it’s just a redirect. RFC 8615 is about the existence and management of the .well-know namespace, so examples don’t really make sense.
Post reply on HN