@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)
@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)
barnabyif 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?
barnabyit’s complicated slightly by the fact that I’m considering offering multuple authentication methods, potentially customisable per user, a la indielogin.com
barnabyhmm 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)
barnabyand assume that anyone who wants to support multiple users is going to have specific enough requirements that they’ll write their own indieauth implementation
barnabyso 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
ZegnatWould 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
barnabywith 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
barnabywith multi-user, you need to additionally have a username field, and be able to tell which authentication methods are available/valid for each user
Zegnatyeah, 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)
barnabywell 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
barnabye.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
ZegnatYeah, 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.
ZegnatPutting 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
barnabyand 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
ZegnatI 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"
ZegnatAlso 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
ZegnatIn 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.
ZegnatWhat 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/
barnabyyeah, 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
ZegnatI 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.
barnabymy plan is to just have the consuming code define something like an isRequestAuthenticated function, which my library code calls with the request object
ZegnatOn 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
ZegnatBut 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
barnabyI 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
ZegnatThat 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
barnabyyeah, 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
barnabyhmm 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
barnabythat’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
barnabyhmm 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
barnabyit 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
barnabyand 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
jamietannawe'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
Zegnatbarnaby: 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
barnabyyeah, 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
GWGI 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