#dev 2021-06-05

2021-06-05 UTC
IWSlackGateway1, Seirdy, IWSlackGateway and gRegor joined the channel
#
@lawik
↩️ Is there a place you'd recommend covering more of this indieweb stuff? Curious to see what others are doing. How are people using mf2 and webmention? Particular tools? Roll their own?
(twitter.com/_/status/1401038292980744196)
KartikPrabhu joined the channel
#
@fluffy
↩️ http://indieweb.org is a great place to start, especially the chat! It's a great community and very welcoming. :) My recommendation if you want to get started is look into mf2 and webmention; those are, IMO, the core of the #indieweb experience.
(twitter.com/_/status/1401052088193282051)
#
@fluffy
↩️ Also for me, the main reason to do mf2 is so that your outgoing webmentions get parsed correctly by peoples' receivers. There's other good reasons to do it as well (like it gives more support for social readers) but that's the big one.
(twitter.com/_/status/1401052454821580800)
#
@fluffy
↩️ Sure thing! My own indieweb stack: I publish my site with Publ (https://publ.plaidweb.site/), receive webmentions using http://webmention.io, display webmentions with webmention.js (https://github.com/PlaidWeb/webmention.js), and send webmentions and WebSub using Pushl (https://github.com/PlaidWeb/Pushl).
(twitter.com/_/status/1401082930932293635)
#
@fluffy
↩️ I also use isso (https://posativ.org/isso/) for "native" comments on my site, and http://brid.gy to receive notifications from social media sites as webmentions. Also http://fed.brid.gy as an ActivityPub bridge, but that's not very useful in my experience.
(twitter.com/_/status/1401083401109606400)
#
@fluffy
↩️ I also use isso (https://posativ.org/isso/) for "native" comments on my site, and http://brid.gy to receive notifications from social media sites as webmentions. Also http://fed.brid.gy as an ActivityPub bridge, but that's not very useful in my experience.
(twitter.com/_/status/1401083401109606400)
hendursa1, gRegor, KartikPrabhu and barnaby joined the channel
#
barnaby
aaronpk et al: I’m working on my indieauth authorization endpoint code, and am wondering about potential account discovery attacks
#
barnaby
if an endpoint supports multiple accounts, and the me parameter of the request to the authorization endpoint isn’t one of them, what should it do?
#
barnaby
returning an error would allow attackers to discover whether a particular user has an account at or is supported by that service
#
barnaby
and I’m wondering if this is a big deal or not
#
barnaby
it’s complicated slightly by the fact that I’m considering offering multuple authentication methods, potentially customisable per user, a la indielogin.com
#
barnaby
so if I want to mitigate account discovery attacks, I’d need to always show all of them
#
sknebel
if I want to check if a URL can be used to log in with indieauth, I can just fetch the page and check if it declares an endpoint
#
sknebel
so usually its not a big concern IMHO
#
barnaby
good point
#
sknebel
now a thing you can log into should IMHO go through the login flow and reject a user it doesn't recognize only after they completed the flow
#
aaronpk
The "me" is really a hint not a requirement especially since the user might enter something that isn't their canonical URL
#
barnaby
hmm okay, so a multi-user auth endpoint would always have to display a username field along with whatever auth method is being used (e.g. password, one-time email code, GPG signing a challenge)
#
aaronpk
If you have usernames
#
barnaby
well the username would usually be the me parameter
#
barnaby
hmm maybe I should just give up on making my library support multi-user endpoints
#
barnaby
to begin with, at least
#
aaronpk
It's definitely harder
#
barnaby
and assume that anyone who wants to support multiple users is going to have specific enough requirements that they’ll write their own indieauth implementation
gRegor joined the channel
#
aaronpk
I think there are some low level aspects of IndieAuth that could be done with a library to help people build multi user endpoints
#
barnaby
for context, I’m working on updating https://github.com/taproot/authentication to work with PSR-7 request and response objects so it’s not tied to a particular framework
#
Loqi
[Taproot] authentication: A library for quickly adding full-blown indieauth/web sign-in support to Silex/Symfony applications.
#
barnaby
so my goal is to make a library which allows people to easily add indieauth client/server functionality to any PHP app using PSR-7
#
barnaby
and to make it easily customisable wrt e.g. storing user information, and supporting different authentication methods
#
aaronpk
That's definitely a challenge!
#
barnaby
well I had a pretty good plan for how to do it, for single-user endpoints!
#
barnaby
but I’m definitely not yet familiar enough with how multi-user endpoints should work to make it work for them
#
barnaby
so I’m trying to figure out how I can structure the single-user implementation in a way which will make it easy to add multi-user support later, without over-complicating the single-user use-case
#
barnaby
eh I’ll just make a single-user version for the moment and worry about multi-user later
#
Zegnat
Would be interesting to document the big differences you are running into between single- and multi-user. E.g. when I am thinking of using a WordPress site as my IndieAuth provider, I do not see any big difference. Either I am already logged in to the WP Admin and I can approve the auth request, or I am not yet logged in to the WP Admin and WP will ask me to login as any of the many potential admin accounts it knows about. There is no
#
Zegnat
difference there between single- and multi-user?
#
barnaby
there’s a difference in the login UX, and therefore customisable authentication backends
#
barnaby
with single user, you can have a single password field, or send an email with a one-time code to a known email-address, or have a textarea with a challenge for them to GPG sign
#
barnaby
with multi-user, you need to additionally have a username field, and be able to tell which authentication methods are available/valid for each user
KartikPrabhu joined the channel
#
Zegnat
yeah, I was just sort of wondering outloud it you even want to see that login UX as part of the IndieAuth flow itself, or make that out of scope and to be handled by surrounding application logic (ie. in the WP example, the WP Admin)
#
barnaby
well I want people (such as myself) to be able to take the library, plug it into their app with a few lines of code and maybe a configuration file, and have it immediately function as an auth endpoint
#
barnaby
e.g. my site doesn’t have its own auth system, it just uses indieauth
KartikPrabhu joined the channel
#
barnaby
okay I think I’m almost there
#
barnaby
any opinions about storing authorization request parameters in redirect URLs rather than session/cookies?
#
barnaby
e.g. if an indieauth client sends an authorization request, and the user isn’t currently logged into their server (e.g. via a cookie), then they’d be redirected to their login page with a redirect URL back to the authorization endpoint, complete with all the original IA authorization request parameters
#
barnaby
that way, the indieauth parts could be stateless
#
barnaby
(and therefore way easier to implement and test)
[kimberlyhirsh] joined the channel
#
barnaby
whatever authentication gets redirected to could in theory change the contents of the redirect URL, and therefore the authorization parameters
#
barnaby
I suppose there’s a phishing danger, as the authenticating app could change the redirect URL
#
barnaby
or, rather the redirect_uri
#
barnaby
I suppose another method would be to encrypt the parameters with a local secret
#
barnaby
it’s more work, but still less stateful than cookies or session storage
#
Zegnat
Yeah, that is more what I was thinking of when I was writing before. That I do not think you should put the actual login part of the auth into a module that handles indieauth specific things.
#
Zegnat
Putting state in the URL is fine in a lot of cases, it is what the state parameter is for in OAuth/IndieAuth :) But you would probably want to sketch it out just to make sure someone cannot use it to trick you into sending out an approve
barnaby joined the channel
#
barnaby
Zegnat: yeah, your example of wanting to redirect to e.g. wordpress auth as part of the process helped clarify how I should be handling thing
#
barnaby
*things
#
barnaby
now I’ve come up with a design which I think will let me do either or, depending on how the library consumer configures it
#
barnaby
and I think that if an authorisation endpoint which my IA code redirects to is insecure or malicious, then that particular user has bigger problems than that endpoint being able to access some IA requiest parameters
#
barnaby
because it can obviously control where it redirects to anyway
#
barnaby
so there’s no additional phishing danger
#
barnaby
cool, so I can write an entirely stateless library! that makes things vastly simpler
#
Zegnat
I think the bigger trick is for your authorisation endpoint to know whether the current browser is already logged in or not. If you can solve that, it is a matter of "if not logged in, go to X first and come back once logged in"
#
Zegnat
Also if you can do that, you do not really need to handle any other state questions. Nothing needs to specifically be passed around. Once login has happened, the login flow can send the user back to the original URL for the IndieAuth flow without needing to send any other information
#
Zegnat
In a PSR-7 based workflow, I would almost expect some middleware to have already checked if a user is logged in or not, but I have not worked with Silex a lot and not sure if there are any examples to go on there.
#
barnaby
well Silex is abandoned now, that’s one of the reasons I’m writing a framework-independent library
#
barnaby
back when I wrote the current taproot/authentication, basing it on the Symfony HTTP and routing classes was the closest I could get
#
barnaby
but since then, PSR-7 showed up, so I can make something which is much more broadly compatible
#
Zegnat
PSR is very nice, yes :)
#
Zegnat
What I have usually seen is that there is an auth middleware (PSR-15) in the chain that checks if the current request is made by a logged in user. And then the user’s data is added as an attribute on the PSR-7 request before it is passed down. One example I could quickly get a result for through Google: https://docs.mezzio.dev/mezzio-authentication/v1/intro/
#
barnaby
yeah, I’ve seen some similar things. dealing with that is outside the scope of my library code though, and is rather something for consuming code to check
#
barnaby
as AFAIK there’s no standardised way of getting user data from a request
#
Zegnat
I was thinking the IndieAuth server part could check an attribute on the request object. Have the user of your lib specify the attribute when your lib is instantiated.
#
Zegnat
(Note that I am biased on PSR-7 as a comaintainer on a PSR-7 lib with a fair amount of downloads.)
#
barnaby
my plan is to just have the consuming code define something like an isRequestAuthenticated function, which my library code calls with the request object
#
barnaby
that way they can use whatever method they want to determine whether the request is authenticated
#
Zegnat
That works too
#
barnaby
and, cool, which PSR-7 library?
#
Loqi
[Nyholm] psr7: A super lightweight PSR-7 implementation
#
barnaby
ah very nice, that’s been my go-to PSR-7 implementation
#
barnaby
very nice work!
#
Zegnat
On a very high level, I would expect the IndieAuith server to be a PSR-15 request handler. So you would have $iaserver->handle($request). And when I create $iaserver I would have passed in an attribute name like "isAuthenticated". Then when the IndieAuth server is handling a ServerRequest it can do $req->getAttribute($this->attributeName) to figure out what the application has set as the current state
#
Zegnat
Does that make sense?
#
barnaby
a request handler, or a middleware?
#
Zegnat
Request handler. The IndieAuth server would be in charge of giving HTTP responses, right?
#
barnaby
some of the functions I expose will be very similar to the Request Handler interface, but I’m not sure it’s a great fit for what I have in mind
#
barnaby
or, hm, maybe it would work
#
Zegnat
But there would be a middleware up the chain that actually checks whether the current browser is logged in or not. And the way that middleware functions (it might highjack and send the user to a login form of some kind) is out-of-scope for the IndieAuth server
#
barnaby
I need to look into it in more detail. I’m not a huge fan of how the Request Handler interface seems to be based around having one class per route
#
barnaby
but that’s based on my very cursory knowledge of it
#
barnaby
e.g. my micropub adapter class exposes functions for handling two different routes, the micropub endpoint and the media endpoint
#
barnaby
so on the surface it looks like a good candidate for being a PSR-15 request handler, but I don’t think it’s such a good fit
#
Zegnat
PSR-15 does not really care about the amount of routes handled by it. That is up to a router to figure out.
#
Zegnat
Here is an example where FastRoute is used to figure out which request handler to run: https://github.com/Zegnat/php-website-starter/blob/develop/public/index.php
#
Zegnat
That repo is now slightly out of date, but was used as an example of how there is no need for a fixed framework when you can string together PSR implementations. See things that are used to turn it into its own site engine in the README: https://github.com/Zegnat/php-website-starter#current-practices
#
Loqi
[Zegnat] php-website-starter: My minimum viable setup for starting a PHP project.
#
Zegnat
I really need to update it, Zend Emitter doesn’t even exist anymore. The rename to Laminas has been a while ago now, haha
#
barnaby
yeah, I see how that can work, but I don’t want to bundle a router with my micropub adapter library. I’d much rather expose a couple of functions which take a request and return a response, and let the consumer fit them into whatever routing they’re using
#
barnaby
I think the Request Handler interface might be a good fit for parts of my IA library, not sure yet though
#
barnaby
definitely good to know about though!
#
barnaby
hmm I suppose one big benefit of bundling your own router inside a Request Handler for an entire pluggable app would be that URL generation is much easier, and encapsulated inside each handler
#
barnaby
that’d definitely be an argument for that approach if you have something with a lot of routes, which needs to be able to generate URLs for its own routes
hendursaga and jeremycherfas joined the channel
#
barnaby
do we have stats anywhere on IA code_verifier support?
#
barnaby
hmm I found another argument for deprecating the old IA flow of redeeming an auth code for a profile at the authorization_endpoint, rather than the token_endpoint
#
barnaby
it would mean that server implementations can broadly apply CSRF protection to the authorization endpoint, where it’s important, and leave it off the token endpoint, where it shouldn’t be used
#
aaronpk
ah excellent point yes
#
aaronpk
that falls under the category of "authorization endpoint is for user interaction and token endpoint is for application requests"
#
barnaby
exactly
#
barnaby
and having a single route which may or may not require csrf protection can be tricky to configure in some frameworks, e.g. Django, where CSRF protection is applied by default but can be opted out of on a route-by-route basis
[fluffy] joined the channel
#
barnaby
Are there any guidelines for when IA access tokens should expire, or whether they should expire at all?
jamietanna joined the channel
#
jamietanna
we're still fleshing that out - and not many folks have expiry - but I've recently moved to 7 day expiring tokens, with refresh tokens as an ability to have effectively limitless access
#
Loqi
jamietanna: barnaby left you a message 1 day, 23 hours ago: thanks for letting me know about the mf ruby CLI! good to know
#
jamietanna
you're welcome!
#
barnaby
okay, good to know
#
Loqi
[EdwardHinkle] #17 Dealing with Expiring Tokens
[KevinMarks] joined the channel
#
@tesseralis
now that I've gotten to play with NextJS for a bit I can go back and honestly say, boy, Gatsby is such an over-engineered mess.
(twitter.com/_/status/1401294359568343045)
#
Loqi
ok, I added "https://twitter.com/tesseralis/status/1401294359568343045?s=20" to the "See Also" section of /gatsby https://indieweb.org/wiki/index.php?diff=76013&oldid=74683
#
@forrestbrazeal
The recent "All the ways to run containers on AWS" threads have left me super confused so I made this flowchart to help. It's probably also wrong. https://pbs.twimg.com/media/E3ASQbXX0AEryZt.jpg
(twitter.com/_/status/1400639759215640577)
#
Zegnat
barnaby: my tokens also expire after 7 days. Though I have no refresh tokens implemented. I think GWG was also looking into making tokens issued by WordPress expire
#
barnaby
okay, cool, looks like 7 days is a sane default value then, especially if/when I implement refresh tokens
#
barnaby
is currently deep in making stateless CSRF protection, hoping to get back to actual indieauth implementation soon
#
sknebel
it makes sense to have an option to change the expiry in the flow though
#
sknebel
e.g. when you want to give a PESOS service, phone app, ... a long-running token
#
barnaby
yeah, definitely. but that implies a whole load of extra token management and querying capabilities which are out of the scope of the library I’m making
#
barnaby
so I’m just making sure that there’s room for consumers to add that functionality themselves if they want
#
barnaby
while providing quick and easy sane defaults
#
barnaby
although wouldn’t refresh tokens remove the need for user-configurable expiry times?
#
barnaby
seems like an additional confusing UX burden
#
sknebel
refresh tokens are somewhat orthagonal to "is this connection supposed to be forever"
#
barnaby
I don’t think I’ve ever seen an OAuth UI which allowed me to configure the token expiry time
#
sknebel
I'd argue for a default of an infinitely valid token (or token + refresh tokens) *if* you have UI to review and revoke tokens
#
aaronpk
usually that decision is made by the oauth provider, but there are plenty of examples of UIs for configuring that in the provider side
#
sknebel
(or some other way of removing access)
#
barnaby
yeah, I’d agree that any complete indieauth server needs to have a UI for reviewing active tokens
#
barnaby
just as twitter, gh etc. have similar UIs
#
barnaby
plenty of opportunities to mine for UI inspiration and conventions
#
barnaby
the fact that my library won’t offer that functionality by default is another reason to default to a one-week expiry time for access tokens
#
Zegnat
I like short-lived and no refresh tokens for most of my IndieAuth use-cases, cf. https://www.oauth.com/oauth2-servers/access-tokens/access-token-lifetime/#short-token-no-refresh
#
barnaby
out if interest, has anyone here built such a UI on their indieauth server?
#
Zegnat
Not me. I set expiry times right in the database if I want to have anything other than my default 7 days
#
barnaby
well I guess storing them in a database and changing them there is a UI of sorts
#
Zegnat
Super user UI, I guess, haha. But I find 7 days plenty, usually. And I can always revoke through https://indieauth.spec.indieweb.org/#token-revocation
wagle, [jacky] and gRegor joined the channel
#
GWG
I support the functionality for expiring tokens, just no UI or such. So, I would need to just add a setting for what the default expiry was and it would just work
#
GWG
I thought about adding refresh tokens after jamietanna did it
#
GWG
But would likely just add UI on the authorize screen
#
GWG
Where you could set it
barnaby joined the channel
#
barnaby
aaronpk: just noticed an errant “discoverinig” at https://www.oauth.com/oauth2-servers/indieauth/
#
barnaby
I’d fix it myself if the source is somewhere accessible (and I knew where it was)
#
barnaby
nice oauth book btw, I’ll definitely be reading through it all at some point
#
aaronpk
since you are building an indieauth server i will happily send you a physical copy too!
#
barnaby
oh that’d be great, very kind of you!
#
GWG
barnaby: Make sure he autographs it.
#
GWG
I made him autograph mine.
#
aaronpk
send me your mailing address somehow and i will ship one out :)
#
barnaby
will do!