oodaniHmm. Still haven't figured out what's going wrong with Woodwind authentication - it finds my authorisation endpoint https://00dani.me/auth/indie, I approve it and redirect back, and then it fails with the error 'Login error: missing "me" in response'. But if I verify the auth code myself, using HTTPie, the response is clearly {"me": "https://00dani.me/"} and should work totally fine. I tried omitting the Accept header, which is what Woodwind does, and
oodani(I checked the flask-micropub source. Rather than sending an Accept header, it just tries to parse the response as JSON and then as formencoded. Which should work totally fine."
sknebeloodani: might be worth setting up a simple thing to log into that uses flask-micropub to debug? (there is an example I think in the repo, otherwise I think I dig one out tomorrow).
oodaniOoh, that's interesting. kylewm.com, which presumably also uses flask-micropub, fails too - but differently? It gave me a state parameter of None, and then when I redirect back to it it sends me to https://kylewm.com/None and naturally 404s. Seems like it meant to omit the state rather than send me None as a string.
oodaniRemoving the state parameter manually makes it fail the same way as Woodwind: Verify response missing required "me" field {"me": "https://00dani.me/"}
oodaniKinda surprising, honestly? Like I said, my auth endpoint only works for response_type=id. Not sure how tokens.indieauth.com decided the auth was valid.
aaronpkwait what's going on? you shouldnt be interacting with tokens.indieauth.com unless you're doing response_type=code for getting a micropub access token
oodaniFigured out ben.thatmustbe.me, that was a bug on my part. That site's redirect URI already has a query parameter and I was just using uri + '?' + urlencode(params). Works now though.
oodaniI reckon it *shouldn't* have a query parameter, because it points to where on the site to go after authing me, and that info really belongs in the state parameter. But surely someone's gonna be using query params correctly. ;)
oodaniJust about to code my token endpoint: thoughts on revoking access? My tokens are gonna be stateless JWT, so there won't just be a table to remove them from. I could store a list of authorised client IDs. perhaps - remove a client from that list, all their tokens stop working.
aaronpkif all you're trying to do is sign the user in without requesting permission to post for them, then you can use indieauth.com for its second role, which is that use case.
oodaniI'm thinking list of client IDs with an optional "revoked_at" timestamp. Then you can list off the apps you've authorised and know who can be revoked, as well as know which tokens were revoked when you do it.
oodaniIt's a little more space used than just storing the revoked ones, but I think if I've issued enough tokens that that matters I'm really gonna want my site keeping track of them anyway. :P
aaronpki actually switched from JWT to storing tokens in a database with my last site rebuild. I do have to have a legacy bit of code to continue to validate the already issued JWT's but it's not hard to support both old and new tokens
oodaniHmm, I was thinking about the opacity of tokens: does the spec say anything about how *big* a token can be? Lots of databases have field size restrictions.
aaronpkso then the client and the server are fighting for that space, because the client defines the "state" value and the server defines the "code" value
mblaneyoodani, aaronpk I made some changes to unicyclic.com based on your feedback. no more token fallback and I was also adding scope=create and response_type=code even though it was log in only.
oodaniSome IndieAuth servers (like mine) use that to verify the redirect URI and client ID "match". It's on the wiki but apparently not formally specified yet.
oodaniAlthough publishing other kinds of redirect URIs under the same rel would be harmless, I think. Still can't craft malicious redirect URIs, you can just point the IndieAuth server to the wrong place and probably get a 400 because the other endpoints don't know what the heck these parameters are for.
oodaniAha, found it in the "dynamic client registration" spec: it uses an array called redirect_uris, which would make rel="redirect_uri" the most appropriate. And that's what we already use.
aaronpkthat said, if there is a good reason to be more specific that's still something to consider. the registration spec was not intended to be in a document that's also oa website :)
oodaniThe docs said to include it, I figured leaving it out would make it pick a ~reasonably secure~ default or something. But actually it leaves a gaping security hole. Oops?
oodaniHmm, that's weird. My tokens are coming out of PyJWT with apostrophes in them? The auth code is working fine, it's all valid base64 and jwt.io understands it. But the token, which is using the same call exactly, has weird apostrophes in its header and signature. ?
oodani Hmm. Still haven't figured out what's going wrong with Woodwind authentication - it finds my authorisation endpoint https://00dani.me/auth/indie, I approve it and redirect back, and then it fails with the error 'Login error: missing "me" in response'. But if I verify the auth code myself, using HTTPie, the response is clearly 
mblaney hi oodani feel free to try https://unicyclic.com if you're looking for more indieauth sites to test :-)
aaronpk strangely I don't see any indication of a maximum length https://tools.ietf.org/html/rfc6749#section-1.4
petermolnar python3++
[kevinmarks] appengine-- for not having python3 yet
www.boffosocko.com created /ask_me_anything (+2286) "started stub page with some examples" (view diff)
tantek.com edited /ask_me_anything (+36) "/* IndieWeb Examples */ link to chrisaldrich's actual ama page" (view diff)