#dev 2017-12-05

2017-12-05 UTC
#
aaronparecki.com edited /h-x-app (+11) "/* Aaron Parecki */" (view diff)
leg, tbbrown and gRegorLove_ joined the channel
#
aaronparecki.com edited /obtaining-an-access-token (-34) "/* Response */ remove unneeded IndieAuth header" (view diff)
#
aaronpk progress: https://indieauth.net/spec/#discovery
KartikPrabhu joined the channel
#
tantek I'm happy to report that the few bots and such IPs that I blocked resulted in 1/6th the bandwidth usage for my site in November as compared to October
#
aaronpk whoaaa
#
tantek while "number of visits" increased almost 10%
#
tantek so y'all might want to look at blocking evil bots
#
tantek if that's something you can control on your web servers
#
tantek 6x is no joke
#
tantek aaronpk - in particular for anything elastic, it could save a bunch of $
#
tantek I'm guessing indieweb could be getting hit
#
tantek (if I'm getting hit)
#
aaronpk well thankfully i'm nowhere near the bandwidth limits on my account
#
aaronpk alright, https://indieauth.net/spec/#authentication has a new diagram and updated bullet point list
[miklb] and renem joined the channel
#
aaronpk I have this vague recollection of a discussion about dropping the "me" from the initial redirect, since client's shouldn't be trusting variables in query strings. but I can't find that discussion, and two of the indieauth pages were not updated to reflect that.
#
aaronparecki.com edited /authorization-endpoint (-25) "/* See Also */ redundant" (view diff)
#
aaronpk ah I found where I removed it from relying on that in quill https://github.com/aaronpk/Quill/commit/e590c95c9f21fab9ebf2ba2efd83cca79585cfca
#
aaronpk and here's the issue for it https://github.com/aaronpk/Quill/issues/79
#
Loqi [aaronpk] #79 Don't rely on `me` in the callback URL
#
aaronpk which conveniently links to issues on a bunch of other projects
#
aaronparecki.com edited /obtaining-an-access-token (-77) "/* Response */ do not send `me` back to callback URL as it is unsafe https://github.com/aaronpk/Quill/issues/79" (view diff)
#
aaronparecki.com edited /authorization-endpoint (-202) "/* Redirect to web application */ do not send `me` back to callback URL as it is unsafe https://github.com/aaronpk/Quill/issues/79" (view diff)
#
aaronparecki.com edited /authorization-endpoint (-98) "/* Auth code verification */" (view diff)
tbbrown joined the channel
#
aaronpk authentication section is complete
#
aaronpk https://indieauth.net/spec/#authentication
#
aaronpk would appreciate a review!
tantek, KartikPrabhu and oodani joined the channel
#
Zegnat I will be reading it carefully on my upcoming train ride to uni this morning. Looking good on glance, aaronpk!
#
Zegnat !tell aaronpk "3.2 Client Identifier" disallows ports for clients, how will this work with e.g. shpub where the Micropub client locally runs a server?
#
Loqi Ok, I'll tell them that when I see them next
tantek, cweiske, jjuran and [kevinmarks] joined the channel
#
Zegnat !tell aaronpk "Discovery by Clients" says: “For the Authorization workflow […] the client needs to find the user's authorization_endpoint, token_endpoint and micropub endpoint”. I get using Micropub as example, but the it is listed here almost makes it sounds like the micropub endpoint is a MUST for the authz flow. Is there a better way to phrase t
#
Zegnat his maybe?
#
Loqi Ok, I'll tell them that when I see them next
#
cweiske .
#
vanderven.se martijn edited /h-x-app (+330) "/* IndieWeb Examples */ Split between publishers and consumers, start listing consumers with 00dani." (view diff)
#
Zegnat With IndieAuth referencing h-app, might be time to start documenting consuming cases.
#
Zegnat cweiske, any thoughts on IndieAuth not allowing client URLs with port numbers? Would this be problematic for shpub? https://indieauth.net/spec/#client-identifier
#
cweiske yes, this would break it
#
cweiske because shpub runs in userspace and thus cannot use port numbers < 1024
#
cweiske the only solution would be if non-redirect verification would be supported by *all* indieauth servers (aka pin code entry)
#
cweiske AFAIK none of the indieauth servers today support that
#
Zegnat I guess you could fix it by having a publicly hosted home page for shpub and define only the redirect_uri with a port, since that is allowed. But then the publicly hosted page needs to whitelist all possible ports on 127.0.0.1 or something…
#
cweiske oh wait
#
cweiske I was under the impression that the client URL would be the redirect URL
#
cweiske 15: public static $client_id = 'http://cweiske.de/shpub.htm';
#
Zegnat It doesn’t look like the limits for client_id are applied to the redirect_uri as the spec currently stands.
#
cweiske client id is the homepage, which is fine without a port number
#
cweiske oh. I just see that that rendered spec has anchors for each elements just as my blog posts
#
Zegnat Yeah, then that home page just needs to whitelist all the possible userspace redirect_uri values: https://indieauth.net/spec/#redirect-url
#
Zegnat Else only redirect_uri values on cweiske.de SHOULD be accepted
#
cweiske 127.0.0.1 would not be enough. If you're on a server via ssh, the IP address that you connected to is used as redirect URI :)
#
cweiske so the whole IPv4 and IPv6 address space would have to be whitelisted
#
Zegnat Ah, yep.
#
cweiske that would be a stress test for the microformats parser
#
Zegnat I guess alternatively you would have to put the expected IP address in a query of the client_id and dynamically whitelist that specific one.
#
Zegnat Feels a bit clunky, but not the show stopper I thought it was on first read.
tantek, jeremycherfas and renem joined the channel
#
aaronpk good morning, catching up now
#
Loqi aaronpk: Zegnat left you a message 6 hours, 15 minutes ago: "3.2 Client Identifier" disallows ports for clients, how will this work with e.g. shpub where the Micropub client locally runs a server?
#
Loqi aaronpk: Zegnat left you a message 5 hours, 25 minutes ago: "Discovery by Clients" says: “For the Authorization workflow […] the client needs to find the user's authorization_endpoint, token_endpoint and micropub endpoint”. I get using Micropub as example, but the it is listed here almost makes it sounds like the micropub endpoint is a MUST for the authz flow. Is there a better way to phrase t
#
Zegnat Disregard the first !tell, was reading that wrong, and discussed it with cweiske :) But you’ll catch up to that.
#
aaronpk I see
#
aaronpk yes, those restrictions don't apply to the redirect_uri intentionally
#
Zegnat Was interrupted with school stuff though, still need to pull my thoughts together on the Authentication flow. Maybe have some more thoughts / questions in about an hour when I get home.
#
aaronpk interesting, this document suggests that wildcard matching of redirect URIs is a thing, although I don't think I've seen that elsewhere before https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00
#
aaronpk the core spec says "if only part of the redirection URI has been registered" at one point
#
aaronpk aha
#
aaronpk https://tools.ietf.org/html/rfc8252#section-7.3
#
aaronpk "The authorization server MUST allow any port to be specified at the time of the request for loopback IP redirect URIs"
#
aaronpk they mention loopback IPs specifically
#
Zegnat In layman’s terms (as an authorization endpoint) if an application has 127.0.0.1 listed as a redirect_uri, I can (SHOULD/MUST) accept it with any port?
#
aaronpk yep
KartikPrabhu joined the channel
#
cweiske that will break for shpub ssh setups, because the redirect IP will not be a loopback
#
cweiske but the public IP of the server
#
aaronpk o.O true
#
aaronpk ok back to the original problem this is trying to solve... https://tools.ietf.org/html/rfc6749#section-10.15
#
aaronpk the point of redirect url registration is to prevent an attacker from setting the redirect URL to something under their control to steal the auth code
#
aaronpk as well as avoid being an "open redirector"
#
aaronpk should we say that port variation on the redirect URL is always allowed?
#
cweiske wouldn't help either
#
cweiske but I guess shpub is a special snowflake
#
aaronpk I guess the remote shpub example is the outlier here. any other native app will have similar requirements other than that
#
cweiske yep
#
Zegnat Yeah, not sure how special it is compared to other native apps. They all need a way to get the redirect somehow.
#
cweiske yes, but not on non-local IPs
#
aaronpk the other way to solve this is to allow port numbers in client_id
#
aaronpk then the remote shpub could serve its own home page that registers its redirect_uri
#
Zegnat If local shpub knows its own IP and port, it could theoretically already set client_id to shpub.com/?port=1111&ip=127.0.0.1 and have shpub.com serve a dynamic redirect_uri value.
#
cweiske parameters are not allowed there
#
aaronpk query params are allowed in the client ID
#
Zegnat “MAY contain a query string component”
#
Zegnat (Had to double check.)
#
aaronpk I think dropping the port restriction on client_id is the simplest
#
Zegnat I can’t immediately think of a security issue with that.
#
Zegnat Apart maybe from https being send to http by a middleman?
#
Zegnat Not sure how connection libs like curl handle that
eli_oat joined the channel
#
aaronpk that provides shpub with two options. for local use, it would have to use a public URL client_id with a query string component to specify the local port of the redirect URI. for remote use, it could use the remote IP as the client_id
#
aaronpk s/remote IP/remote address
#
cweiske this distinction is needed because the auth server would not have access to a client_ip of 127.0.0.1
#
aaronpk yes thanks for clarifying
#
aaronpk oh yeah, one more option. since what we're trying to do here is prevent specific attacks involving tricky redirect URLs, if the scheme/domain/port of the client_id match the redirect_uri then there wouldn't be any surprises. so I *think* we can bypass the redirect_uri lookup altogether if those match
#
Zegnat I agree, path isn't so important in that case.
#
aaronpk yea you can't steal an auth code by changing just the path of an otherwise legitimate redirect URL
#
Zegnat If you don't end up allowing different ports, maybe reference the OAuth document on allowing variable ports for loopback. I think that is worth calling out.
#
aaronpk alright updated draft https://indieauth.net/spec/#client-identifier
#
aaronparecki.com edited /nanopub (+54) "see also" (view diff)
#
aaronparecki.com edited /Micropub/Servers (+110) "/* CMS Software */ +nanopub" (view diff)
#
cweiske.de edited /nanopub (+22) (view diff)
#
aaronparecki.com edited /static_site (+349) "add links to micropub endpoints" (view diff)
#
cweiske.de edited /commentpara.de (+22) (view diff)
[keithjgrant] joined the channel
#
Zegnat Sounds better to me, aaronpk :)
Loqi_ and tantek joined the channel
#
eddiehinkle.com edited /h-x-app (+389) "+ indigenous as publisher" (view diff)
[miklb] joined the channel
#
aaronparecki.com edited /token-endpoint (+2) "/* Verifying an Access Token */ full URLs" (view diff)
#
aaronpk .bot domains appear to be $75
#
aaronpk except for certain whitelisted words that are $750
#
aaronpk or weather.bot which is $7500
#
tantek.com edited /Trello (+671) "simplify and expand dfn, compare to Pinterest, public examples, card share UI with screenshot" (view diff)
#
aaronpk two-letter domains seem to fall into the $750 tier
#
tantek.com edited /Trello (+7) "TOC" (view diff)
#
aaronpk one-letter $7500
#
aaronpk I think $75 is over my budget for a new domain
#
tantek.com edited /citation (+175) "/* User Interface */ Trello example" (view diff)
#
aaronparecki.com edited /token-endpoint (+18) "/* Verifying an Access Token */ update example scope" (view diff)
#
tantek yeah I'd say so - especially an annual fee!
[manton] joined the channel
#
[manton] With this kind of variable pricing, would be nice if the lowest price is less than $75. .blog has this same approach, where some words are $$$$, but at least they start at something like $20.
#
tantek.com edited /Trello (+983) "expand Card share UI, note its a citation UI, provide example blockquote inline to demonstrate" (view diff)
#
aaronpk yeah, they're definitely targeting a specific customer with .bot
#
[manton] Yeah, with .bot I guess I can see it... It'll be interesting to see if it takes off.
John____, renem and j12t joined the channel
#
tantek specific customer? good self-identifying bots?
#
aaronpk haha yes
#
Loqi aaronpk: lol
#
tantek like a bot status symbol?
#
tantek does the domain require that script are Three Laws compliant?
#
aaronpk alright I think it's done
#
aaronpk https://indieauth.net/spec/
#
Loqi [Aaron Parecki] IndieAuth
#
tantek wow
#
aaronpk I think that captures all the information that's currently spread out across a bunch of wiki pages
#
tantek that's huge
#
Zegnat Good stuff. Reviewing to see if there are any selfauth updates to do.
#
Zegnat Probably should get redirect_uri support in there. Not sure if I want to do the h-app parsing.
#
aaronpk hm maybe a security consideration paragraph about displaying the client_id and redirect_uri if you aren't going to be fetching the client_id
#
Zegnat I think we might already be displaying those? Or at least client_id. But would need to check.
#
Zegnat If someone wants to rewrite selfauth into v2 with separate dependencies and pull in an mf2 parser etc, I would not be against it. But that’s not something that is currently in my planning.
[miklb] and tantek joined the channel
#
aaronpk https://indieauth.net/spec/#preventing-phishing-and-redirect-attacks
sebsel and veganstraightedg joined the channel; sebsel left the channel
#
dgold1 I have no idea where the '1' came from
#
aaronpk dgold1: re: your h-card question, here's what most consumers will do when looking up the author of your posts: https://indieweb.org/authorship#How_to_determine
#
dgold1 so a fully-featured h-card should be on a separate _author_ page?
#
aaronpk can be, not should be
#
dgold1 i think I've been having a conceptual anti-pattern in wanting a shorter h-card & a full-featured one
#
aaronpk that's fine tho
#
aaronpk if they're on the same page it's even more straightforward for consumers
#
aaronpk the consumer will match up the url property in the two h-cards
#
dgold1 it seems to be throwing odd errors to some people's webmentions, tho
#
dgold1 in that oft-times when I send a webmention, the fine-grained data isn't available
#
dgold1 so, for example, no face in a face-pile, just a blank image
#
sknebel ah, because your author property is an h-card and not just an URL
#
sknebel https://sturdy-backbone.glitch.me/test?url=https%3A%2F%2Fascraeus.org%2Fmicro%2F1512162656%2F
#
aaronpk ooh good catch "if it has an h-card, use it"
#
sknebel I know why I made this thing, because I went way to oftne "oh, right, didn't see X" :)
#
aaronpk looking at https://ascraeus.org/micro/1512162656/ I don't see any picture visibly
#
Loqi [Daniel Goldsmith] Oh wow. Just wow. The quantity of quality available on this site. Such an incredible resource, such an incredible artist. http://www.neilyoungarchives.com
#
aaronpk or even your name
#
dgold1 ^^ don't post when emotional and/or have beer taken
#
aaronpk so there isn't any reason to have an embedded h-card in the h-entry anyway
#
sknebel is in hidden markup though
#
sknebel !mf https://ascraeus.org/micro/1512162656/
#
Kaja https://php.microformats.io/?url=https%3A%2F%2Fascraeus.org%2Fmicro%2F1512162656%2F
#
Loqi [Daniel Goldsmith] Oh wow. Just wow. The quantity of quality available on this site. Such an incredible resource, such an incredible artist. http://www.neilyoungarchives.com
#
aaronpk right, but since it's not visible, easy change to change it to just the URL
#
sknebel right
#
dgold1 so strip the h-card from the posts, leaving the page's markup?
#
aaronpk do <a href="/" class="u-author"></a> instead of your whole <span> h-card
#
dgold1 will do, thank you so much guys
#
sknebel aaronpk: https://indieauth.net/spec/#preventing-phishing-and-redirect-attacks looks good btw. Something I've considered in the past was keeping track of known client_ids and their redirect URLs and show them differently, not sure if that's worth suggesting in the spec tho
#
aaronpk known client ids?
#
dgold1 next up is why the hell are my 'reading' posts spewing \n\n\n\t\t\t all over the place... :slightly-smiling-face:
#
aaronpk like if you've authorized that app already?
#
sknebel yes
#
aaronpk I like that idea, but it doesn't seem specific to indieauth (it applies to oauth 2.0 just as much)
#
www.svenknebel.de edited /CardDAV (+198) "link one server" (view diff)
#
www.svenknebel.de edited /CalDAV (+2460) "merge content from /caldav" (view diff)
#
www.svenknebel.de edited /caldav () "(-2533) redirect to canonical" (view diff)
#
www.svenknebel.de edited /next-hwc (+0) "/next 12-13" (view diff)
#
aaronpk sknebel: Zegnat: anyone want to implement token revocation? I added it to my site's token endpoint in like 3 minutes https://indieauth.net/spec/#token-revocation
#
sknebel Zegnat had been asking about that, I wouldn't be surprised if his new token endpoint already has it in some form
#
sknebel (hm, apparently I switched my page back to tokens.indieauth.com a while back and I have no idea *why* I did that....)
sgreger joined the channel
#
Zegnat I didn't do the action parameter, but yes, I already have revocation code ready to go.
#
Zegnat My token endpoint isn't published yet though.
#
Zegnat adds issue for adding action param
[eddie] joined the channel
#
www.boffosocko.com edited /Indieweb_for_Journalism (-66) "emojicon" (view diff)
#
sknebel ^^^ now the text overlaps the icon there, seems like the template doesn't quite work?
snarfed joined the channel
#
snarfed dgold1: re "i think I've been having a conceptual anti-pattern in wanting a shorter h-card & a full-featured one," you've seen https://indieweb.org/h-card#Issues ?
#
www.boffosocko.com created /obituary (+1644) "definition and stub page" (view diff)
#
www.boffosocko.com edited /longevity (+670) "section on printed books for longevity; obituary see also" (view diff)
#
aaronparecki.com edited /Category:IndieAuth (+35) "add link to spec" (view diff)
gRegorLove and snarfed joined the channel
#
gregorlove.com edited /Posts_about_the_IndieWeb (+145) "merging links from /news, heading, minor formatting" (view diff)
#
aaronpk snarfed: am I missing something or is the granary jsonfeed not including the post title? https://granary.io/url?input=html&output=jsonfeed&reader=false&url=http%3A%2F%2Faaronparecki.com%2Farticles
[jelyman] joined the channel
#
gregorlove.com edited /tagboard (+32) "update URLs" (view diff)
#
gregorlove.com edited /Posts_about_the_IndieWeb (+435) "/* See Also */ merge links from /news, standardized capitalization" (view diff)
#
gregorlove.com edited /news () "(-1275) r" (view diff)
#
gRegorLove Heh, editing the homepage when I click preview I get: ERR_BLOCKED_BY_XSS_AUDITOR
#
gRegorLove "Chrome detected unusual code on this page and blocked it to protect your personal information (for example, passwords, phone numbers, and credit cards).
#
gRegorLove "
#
gRegorLove Weird. Maybe doesn't like the <style>?
#
sknebel yeah, because of the raw html being embedded
#
gregorlove.com edited /to-do (-175) "completed "Merge News into Posts About"" (view diff)
#
snarfed aaronpk: ugh, AS1 title vs displayName. thanks for the report. will fix.
#
gregorlove.com edited /tagboard (-11) "rm /news" (view diff)
#
gregorlove.com edited /press (+20) "s/news/Posts about the IndieWeb/" (view diff)
#
gregorlove.com edited /presentations (+9) "s/news/Posts about the IndieWeb/" (view diff)
#
gregorlove.com edited /📰 (+20) "fix double redirect" (view diff)
#
gregorlove.com edited /happening (+20) "fix double redirect" (view diff)
#
aaronparecki.com edited /presentations (+181) "/* 2017 */" (view diff)
#
gRegorLove I think this was part of IWC 2014 homepage redesign session? Not sure what to do with it: https://indieweb.org/wiki/about/
#
gRegorLove oops, -meta
#
aaronparecki.com edited /podcasts_about_the_indieweb (+156) "/* Active Podcasts */" (view diff)
chrisaldrich joined the channel
#
chrisaldrich sknebel, which browser are you using that you saw the overlap issue? I changed it because there was an overlap issue before, but it looks fine in chrome & ff for me.
#
aaronparecki.com edited /wiki (-1) "/* Suggestions */" (view diff)
#
gregorlove.com moved /wiki/about/ to /wiki/2014-about "archiving as part of /wiki/2014-redesign"
#
sknebel chrisaldrich: FF and Chrome, I guess it might be because emoji are different between OSes? (Win10 here right now)
#
gregorlove.com edited /wiki/2014-about (+132) "note part of /wiki/2014-redesign" (view diff)
#
gregorlove.com edited /wiki/2014-redesign (+38) "see also" (view diff)
#
gregorlove.com moved /wiki/2014-redesign to /2014/wiki-redesign
#
aaronpk I hope the git copy is keeping up wth all these moves and deletes haha
#
Loqi awesome
#
gregorlove.com moved /wiki/2014-about to /2014/wiki-about
#
gregorlove.com edited /wiki/about/ (+0) "r" (view diff)
#
gRegorLove Hah
#
gRegorLove ok, all done
eli_oat1, eli_oat and tbbrown joined the channel
#
Zegnat aaronpk, is response_type now a required param for IndieAuth? No longer assumed to be id when lacking?
#
aaronpk Oh yeah did we assume "id" if missing? I'll update the draft if so
#
Zegnat I think we did? Will need to double check with the wiki.
#
Zegnat response_type - “Optional. Defaults to id.” - https://indieweb.org/authorization-endpoint
#
aaronpk Ah cool, missed that
#
Zegnat I have nothing against making it explicit, but wanted to double check
#
aaronpk which is funny cause i was copying from that page
#
Zegnat Need many eyes, and all that jazz :) I am pretty full up with uni at the moment, but hope to have time to give it another solid look later this week.
tantek, [horsemansyospos and [mrkrndvs] joined the channel