@CharlieRoseMari↩️ I don't have anything off the top of my head. I've been thinking about posting an article describing my ideas, and I guess I was using this thread to gauge interest, so I'll send you a webmention. :D (twitter.com/_/status/1384683210819338242)
Loqi, IWSlackGateway, aaronpk, [tantek], doosboox3 and samwilson joined the channel
jamietanna[m]Has anyone thought about making personal access tokens in their IndieAuth server? Ie so we can test stuff locally without needing an OAuth2 flow? (not that that's a bad thing, but personal tokens simplify speed-to-test)
[grantcodes]@jamietanna I have one hardcoded token that doesn't expire which I use for automated things that I don't want to break. Might be bad security wise, but makes life easier 🤷
jamietanna[m]grantcodes that's interesting. For my automated stuff I've gone for refresh tokens (also cause I wanted to implement it) but was thinking of PATs so I could do one-off things. Currently I'm using tokens-pls.herokuapp.com to get me a token, but would prefer something easier to get up and running with
@Cambridgeport90↩️ Mostly solving community and IndieWeb/Fediverse problems; creating clients for more of the newer WC3 standards (webmention, activityPub, Micropub, and so on), of which we don't have enough. (twitter.com/_/status/1384843380564271104)
[tantek]For those that use Signal for their indie comms or anyone wondering who cracks the crackers, you may find this entertaining: https://signal.org/blog/cellebrite-vulnerabilities/ (also, not advising placement of any such random files on your website which might be cached by browsers on mobile devices which then might be extracted / parsed by a Cellebrite device)
Loqibarnabywalters: [tantek] left you a message on 2018-12-19 at 3:00am UTC: your reply-contexts have subtly broken reply-to markup. E.g. https://waterpigs.co.uk/notes/4V2DjG/ which uses <div class="note-reply-context p-in-reply-to h-cite"><a class="u-url" rel="in-reply-to" href="… when it should be <div class="note-reply-context u-in-reply-to h-cite"><a class="u-url" href="…
barnabywaltersaaronpk: I suppose the missing half is the server part? my site works as both a client and server, so I have to get both parts up and running again
barnabywaltersaaronpk: do you remember exactly what IndieAuth\Client::verifyIndieAuthCode did, and whether there’s a replacement for it in the latest version of the PHP indieauth-client?
barnabywaltersthat’s what I thought at first, but exchangeAuthorizationCode makes a POST request to the token endpoint, and I was using verifyIndieAuthCode in the code for my token endpoint
aaronpkbut generally yes the indieauth client library isn't meant to be used when building a token endpoint, even if some of the functions are useful for that
barnabywaltersas the me parameter is no longer sent to the token endpoint, so it’s not possible to statelessly rediscover the authorization endpoint from the token endpoint to get the code verified
aaronpkother way around, you probably _should_ implement your own token endpoint so that you already know where the authorization codes were issued from
aaronpkremoving the "me" parameter from the token endpoint request means shared token endpoints need some other way to know how to validate the authorization code. it has no effect on single-user token endpoints since those would only ever be checking authorization codes from the one authorization endpoint
barnabywaltersI previously had my own token endpoint, which was receiving a me parameter along with a code (previously state) parameter, which it use to discover the auth endpoint associated with the me parameter, and would then call what is now exchangeAuthorizationCode in order to verify the code
barnabywaltershmm okay, so in my token endpoint implementation, I can just assume that the me parameter is always going to be the hostname of the site it’s on, because that endpoint will only ever be used by me
aaronpkyeah for logging in to your own site it makes more sense to keep that local. indieauth is useful when you want to log in to micropub apps so they can post to your site, or log in to other peoples' sites
barnabywalterswell originally I wanted to implement the full indieauth flow, partly to test it and partly so that other people could log into my site and see private content
aaronpkso if you're asking people to log in to your site, then that article i wrote details those steps, and there's no token endpoints involved at all
barnabywaltersbut realistically I don’t have any private content, and nobody uses my micropub clients, so I think I can safely turn off indieauth on my site
barnabywaltersunder what circumstances does one need to implement a token endpoint then? when you want external micropub clients to be able to post to your site?
barnabywaltersso it’s actually quite common that the token endpoint and the authorization endpoint would be on different servers and unable to share data? or is the current assumption that every personal site which supports micropub should have implement its own authorization endpoint too?
aaronpkin other words, it's unlikely that the token endpoint and authorization endpoint would be separated, and even less likely that the token endpoint would not be tied to a specific authorization endpoint
aaronpkmake both endpoints yourself, or you outsource both (indieauth.com + tokens.indieauth.com) or you outsource authorization to indieauth.com and build your own token endpoint