#dev 2022-10-23

2022-10-23 UTC
jacky and geoffo joined the channel
#
jacky how would the media endpoint advertise that back to micropub clients? (like would micropub clients use ipfs URLs to download images for clients to use)?
#
vikanezrimaya !tell jacky IPFS nodes have a built-in gateway, might wanna have that exposed. Alternatively, https://ipfs.io/ is a thing
#
Loqi Ok, I'll tell them that when I see them next
#
[snarfed] slyduda true! the client redirect support in webmention.py was for backfeed, eg based on https://github.com/snarfed/bridgy/issues/1322
#
Loqi [slyduda] #1322 No Webmention Support with Indirect Source Link In Post
#
[snarfed] what's the publish use case for client redirects?
#
slyduda[m] oh no i think i understand what is happening correctly now! i wasnt sure how the app backfed and thought that it needed the follow_meta_refresh from the initial publish for some reason. i will do a bit more reading to make sure i understand backfeed workflow can work with a static site well before i ask a follow up!
#
slyduda[m] i guess my biggest question is, do folks run backfeed manually after they publish? i have a CLI that publishes new content. is there an endpoint for backfeed?
[jeremycherfas] joined the channel
#
GWG Still having trouble with my local venues and when to import venues from a remote source.
#
@kevinmarks ↩️ So Webmention but with 2 explicit middlemen rather than enabling that as an option? https://indieweb.org/Webmention (twitter.com/_/status/1584114655047270400)
#
Saphire Wait
#
Saphire So `rel=authorization_endpoint` actually refers to the base URI for the auth stuff?
barnaby joined the channel
#
barnaby Saphire: the authorization endpoint is the URL which the user is redirected to by the client app, where all of the user-facing auth flow happens (logging in to the server, approving app access, choosing which scopes to grant etc)
#
Saphire AH
#
barnaby the token endpoint is an JSON API endpoint which the client app interacts with to exchange an auth code for an access token
#
Saphire Nevermind, the wiki flip-flops between showing a path with last segment being "auth" and showing a rel with none of that
#
Saphire So I was getting worried "/auth" is silently added
#
barnaby and the issuer URI is required to be a prefix for the meta data URI
#
barnaby nope, no URLs are hard-coded anywhere, discovery is used for everything
#
Saphire Whew
#
barnaby the wiki has some helpful tips on but I would recommend referring mostly to the spec for implementing an indieauth server, it’s much clearer and more up-to-date
#
barnaby https://indieauth.spec.indieweb.org/
#
barnaby oh and it’s worth mentioning that the client app only has to know about the authorization endpoint, although the server might redirect to various different URLs during the user-facing consent process
#
barnaby so the URL shown in, say, consent screen screenshots doesn’t need to be the same as the authorization endpoint
#
Saphire nodnod
jjuran, gRegorLove_, gRegor, [schmarty], jacky and mro joined the channel
#
Saphire Oh also
#
Saphire Is the authorization endpoint dual duty? :<
#
Saphire "If the client only needs to know the user who logged in and does not need to make requests to resource servers with an access token, the client exchanges the authorization code for the user's profile URL at the authorization endpoint."
#
GWG Not exactly
#
barnaby unfortunately yes, for the moment. I know we discussed deprecating that feature a while back, but for the moment it’s part of the spec
#
Saphire Well okay, GET and POST can be easily separated out, but... still
#
barnaby although I don’t have a good overview of which clients make use of it. Maybe the indieweb wiki does?
#
Saphire Makes it a requirement for you to properly split them out and such
#
Saphire barnaby: now that's a good question..
#
Saphire ...would be nice if we had some kind of public test suite and results of "does this client actually check for this"
#
Saphire BTW what do you do if the rel and header are duplicated, or worse conflict?
#
barnaby well there’s http://indieauth.rocks/
#
Saphire ...ironically HTTP with no redirect
#
barnaby that’s easy to answer at least: you take the first valid one, searching Link headers first, then <link> elements
#
Saphire > Testing your Server - Coming Soon...
#
barnaby https://indieauth.spec.indieweb.org/#discovery-by-clients-p-2
#
Saphire barnaby: guess you can log a warning or something if there are multiple
#
Saphire IMHO I would just straight up refuse to process something with conflicting ones tho
#
Saphire ...though you could argue that you need that due to some outdated clients, hm
#
Saphire Or just quirky ones that do not check on or the other
#
aaronpk You could always treat the authorization endpoint as an API only, and when it receives a GET from the user's browser it could redirect to a different URL that actually serves up the HTML
#
aaronpk I've definitely seen some large OAuth providers that do essentially that too
#
barnaby the only reason I can think of to completely reject sites with conflicting links would be concerns about fake links being injected into the site somewhere (e.g. in a 3rd party comment on a post which wasn’t properly sanitised), but taking the first available value and searching headers first is almost always going to mitigate that
#
barnaby (TIL that you can get paragraph-specific fragment links by clicking on paragraphs in the indieauth spec, very nice)
jacky joined the channel
#
jacky checking in for messages
#
Loqi jacky: vikanezrimaya left you a message 11 hours, 50 minutes ago: IPFS nodes have a built-in gateway, might wanna have that exposed. Alternatively, https://ipfs.io/ is a thing
#
jacky hm okay lol
#
jacky oh sure yeah, I'm talking more if a micropub media endpoint, when queried for a resource or a list of them, if a client came across a IPFS-centric URL and the client didn't know to check schemes or understood how to use it, it'd be a interesting case
#
jacky using the gateway _is_ a good fallback, for sure
#
jacky but tbh, I'd prob end up self-hosting that if I'm going to adapt IPFS into a stack
#
@hallam ↩️ I will add in a reference to WebMention. I suspect it came at the wrong time Spec was 2017, work was a bit earlier but Facebook hadn’t really abused our trust like they did in 2016. (twitter.com/_/status/1584198651651313664)
#
@hallam ↩️ Webmention plus cryptography plus one middleman expressed in a format suited for append only list. As with RSS, Webmention notifications can be converted by a gateway. But they obviously aren’t going to be end-to-end encrypted. (twitter.com/_/status/1584198066655363073)
mro joined the channel
#
barnaby hmm currently the taproot/indieauth test suite checks for cache-control: no-cache headers on user-facing responses. Not sure where I got that idea, but on review it looks like no-store would be better, as we never want these pages cached
geoffo, mro and petermolnar joined the channel; petermolnar left the channel
#
barnaby released another minor taproot/indieauth version, with corrected cache management headers, removed dependencies and allowed the latest version of php-mf2 https://github.com/Taproot/indieauth#v031
#
Loqi [Taproot] indieauth: A PSR-7-compatible PHP IndieAuth Server Implementation
#
GWG Morning all
#
barnaby fewerdependencies++
#
Loqi fewerdependencies has 1 karma over the last year
#
vikanezrimaya barnaby: huh, maybe I should check if Kittybox emits those headers properly, I think I didn't bother to implement it
#
barnaby vikanezrimaya: yeah they’re a bit hidden as they’re not mentioned in the indieauth spec itself, you have to look in the security considerations sections of the OAuth 2 spec(s) to find them
#
barnaby the Cache-Control and Pragma headers are actually required by OAuth2 on all of the responses which return JSON data
#
vikanezrimaya I do remember reading that, but since I was more oriented to make things at least work, I didn't bother
#
barnaby the X-Frame-Options and/or CSP headers to prevent auth screens from being embedded are definitely worth it. A lot of protection for very little effort
#
vikanezrimaya Thank you, I will definitely consider adding that!!!
#
barnaby this page is a much easier to read summary of auth page security concerns than the OAuth 2 spec https://www.oauth.com/oauth2-servers/authorization/security-considerations/
#
Zegnat Which pages are you most concerned with getting cached? I think almost all of them in the usual indieauth flow are actually cacheable? 🤔
sp1ff joined the channel
#
barnaby the OAuth 2 spec requires that the token exchange and error responses are not cached, and the consent form is a dynamic page with CSRF protection etc, so why should they be cached?
#
capjamesg [tantek] Would you be in support of 0 BSD for IndieWeb Utils? If so, would you mind expressing that you give permission to relicense the project as 0 BSD? https://github.com/capjamesg/indieweb-utils/issues/73
#
Loqi [capjamesg] #73 Transition license to CC0
gRegorLove_, petermolnar, gRegorLove__, geoffo, gxt and jacky joined the channel
#
Zegnat Token exchange would hopefully not get cached either way, those are POST requests. Theoretically the consent screen could be cached, and could save on e.g. rerunning metadata discovery. But true that you would not be able to do that if you have a CSRF field.
#
Zegnat Error responses are often actually fine to be cached, unless you expect that the same request later would no longer return an error response. Which I think for OAuth is extremely unlikely.
#
Zegnat It probably does not hurt at all to send a no-store for all endpoints, I was just trying to talk through if that was actually the correct way to go :)
#
barnaby with the token exchange and error responses, the OAuth 2 spec requires no-store headers, so I’m happy going with that
#
Zegnat Oh interesting, I do not remember that. But could very well be the case!
#
barnaby Zegnat: the token exchange response ehaders are mentioned here https://www.rfc-editor.org/rfc/rfc6749#section-5.1
#
barnaby *headers
#
barnaby and an example error response is given in the next section, also with no-store headers
#
Zegnat Ah, yeah, the trick there is that you want it to be there if there is any sensitive data in there like tokens. Makes sense.
jacky, asdf1 and gRegorLove_ joined the channel
#
IWDiscordGateway <slyduda> snarfed: sorry to bug you, after doing a bit of research i think i have the necessary background to understand next steps, but i am having an issue finding what information to use for the post_id and the source for the discover endpoint. for the post_id i am assuming i can use the id that is returned by the silo, for the source, i am unsure of what value to use. i have tried multiple values but cannot figure it out. i h
geoffo, jacky, [tw2113_Slack_] and jeeyoon joined the channel
#
[snarfed] slyduda sure! I don't think you have to do any of that, I think just adding follow_meta_refresh=True to the discover call on https://github.com/snarfed/bridgy/blob/e83a8f13a61bd46910eb0d80e74472f24e74d8e1/tasks.py#L595 should be enough