#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)
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
#
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
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
#
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
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
"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?
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
#
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.
#
aaronparecki.com
edited /nanopub (+54) "see also"
(view diff)
#
aaronparecki.com
edited /Micropub/Servers (+110) "/* CMS Software */ +nanopub"
(view diff)
#
aaronparecki.com
edited /static_site (+349) "add links to micropub endpoints"
(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
#
Loqi
[Aaron Parecki] IndieAuth
#
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
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
#
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
#
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
#
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?
#
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
#
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
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 /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)
#
sknebel
chrisaldrich: FF and Chrome, I guess it might be because emoji are different between OSes? (Win10 here right now)
#
aaronpk
I hope the git copy is keeping up wth all these moves and deletes haha
#
Loqi
awesome
#
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