#GWGThe way that the WordPress Indieauth system was set up, you can set the website URL to any arbitrary site, then use Indieauth to get a token, and Micropub will match it against the address you set in your profile. I'm wondering how secure that is. If it is a potential security issue.
#GWGIf you are a Micropub server, and you previously received a token, since the token doesn't come with a URL, how do you know which token endpoint to verify it against?
#petermolnarI'm trying to figure out if it's possible to build an index from python, but it looks like I'd need to run node which I really wish to avoid
#ZegnatBut is there a reason you need to use the user's token endpoint? Isn't it just for letting the user login (authentication)?
#cweiskepetermolnar, that looks like each client has to download the whole search index with his browser to do searching
#cweiskeFor web applications with all their data already sitting in the client, it makes sense to be able to search that data on the client too. It saves adding extra, compacted services on the server. A local search index will be quicker, there is no network overhead, and will remain available and useable even without a network connection."
#GWGZegnat: I'm trying to follow the specification. It says you are supposed to discover the endpoints. I think clarity is needed there in the text
#ZegnatWhat part of the spec are you trying to follow? Authorization (which uses a token endpoint) is for the user to authorize an application to do things with their profile URL. If you instead need an access token for the WP site (not for the userβs URL) you should be using a token endpoint for the WP site - and that will always be the same one.
#GWG"For the Authorization workflow, the client needs to find the user's authorization_endpoint and token_endpoint" - Why find it if you won't be using it?
#ZegnatThatβs for Authorization though. Donβt you need Authentication?
#LoqiSink is an experimental site by Martijn van der Ven that allows anyone with an IndieAuth enabled URL to post to it using any Micropub client https://indieweb.org/Sink
#ZegnatSink lets anyone authenticate with an external personal URL, but it is also its own authentication endpoint and token endpoint so it does authorization for all users when they want to use a Micropub client.
#GWGI am trying to make WordPress a full Indieauth client. Basically, implement everything
#ZegnatBut a client that tries to get some authorization from a user should also have a reason for that authorization. I donβt really follow what WordPress needs to be authorized to do.
#GWGRight now, I taught WordPress to accept an Indieauth token as an authentication method, so I could use that to access the WordPress REST API, which opens up a lot of things.
#GWGI also upgraded [pfefferle]'s original authentication code to use the method outlined in the specification
#Zegnatcweiske: yes, anyone can post but you need to authenticate first. A bit like if the wiki would have a Micropub endpoint.
#[pfefferle]GWG but how have you done it without the discovery part?
#GWGBut the question is, for the code that verifies tokens, the specification doesn't explain how if you get a token, you figure out where it come from?
#aaronpkGWG: i'm a little confused. I think maybe you're doing something that doesn't make sense
#ZegnatA token issued by a token endpoint on example.com only carries authorizations for example.com, GWG. So if you are letting the userβs token endpoint generate a token, that token does not apply to the WordPress site at all. The WordPress site needs to issue its own tokens for use with its own endpoints. And thatβs how you will always know where the t
#Zegnatoken came from, namely: your own token endpoint.
#[pfefferle]so you have to check the endpoints, to authenticate
#ZegnatNo, you must discover if you want authorization to do things with the userβs URL. But you donβt want to do things there, so you should not have to implement authorization.
#ZegnatBasically: only discover a token-endpoint if you are also discovering a micropub-endpoint.
#aaronpkwe really need to separate the idea of the wordpress plugin logging the user into wordpress itself vs issuing tokens to be used by external micropub clients
#ZegnatIf WordPress is the Micropub endpoint, then WordPress should be choosing the token endpoint. A Micropub client would be implementing *authorization* discovery to find a Micropub-endpoint and token-endpoint on the WordPress site. This client will never visit a userβs page to find their own specific token-endpoint. The userβs chosen token-endpoint is
#Zegnat completely irrelevant for posting to a WordPress site.
#[pfefferle]so he can login to the wiki or to wordpress without using indieauth.com
#ZegnatGWG you should only go and discover a token endpoint on the userβs URL if you are also discovering an API endpoint (e.g. Micropub) at that same URL.
#aaronpkthis timing is funny because i'm on an IETF call about a new "Distributed OAuth" spec right now
#aaronpkfor logging in to wordpress, you don't need to discover anything because there isn't anything to discover. the plugin is really just using indieauth.com (soon indielogin.com) to handle RelMeAuth
#aaronpkletting the user configure which login service to use would be a plugin setting
#aaronpkalso there is no token endpoint involved in that flow at all
#ZegnatI found this very confusing at first too. I thought it obvious that a token endpoint goes hand in hand with an authorisation endpoint. In reality it goes hand in hand with API endpoints like Micropub. (At least that new way of thinking made it more clear to me.)
#[pfefferle]yes, but GWG and I wanted to rewrite it, to also support indieauth
#aaronpkwhat i'm saying is I don't think it makes sense to support IndieAuth authentication for logging in to wordpress
#ZegnatThatβs still just logging in, that is authentication, and the authentication flow does not use token endpoints, [pfefferle] :)
#aaronpkwhat's your expectation of the end-user flow of how people will actually end up using IndieAuth for logging in to wordpress?
#sknebelaaronpk: I think it would make sense for multi-user scenarios?
#GWGaaronpk: I reimplemented logging into WordPress with it because that was already in the plugin. I really am focusing on the other piece.
#ZegnatOh, sorry, you mean a different multi-user scenario. *face-palm(
#GWGaaronpk: Good point, but it has over 200 installs
#aaronpkif you want to let people log in to their site with IndieAuth then you still don't ever touch a token endpoint
#ZegnatThe WP case gets interesting when you have people with multiple WP blogs. If their main blog implements an IndieAuth authorisation endpoint they can use that to log in to the other blogs that work with IndieAuth authentication.
#ZegnatBut I would almost say those are 2 separate plugins.
#aaronpkthey are functionally completely different things, but I can see why 2 plugins would be confusing, since they'd both be called IndieAuth
#aaronpkyou could call them "IndieAuth Login" and "IndieAuth Server" but i'm not sure that's actually a good idea still
#cweiskethe wp case is always interesting if you have a central auth server and don't want passwords for each website
#aaronpkin any case if someone wants the WP indieauth server part, you would want a setting to let them disable the indieauth login for logging in to wordpress
#ZegnatAnd you could be stacking the two plugins, theoretically. WP needs to be a Server to support Micropub, but within there you could still use Login through IndieAuth, to get the Sink case.
#aaronpkI can definitely see a scenario where someone doesn't want to add the URL login box to wordrpess but still wants the built-in indieauth server
#ZegnatThe IndieAuth Server WP should hand-off to whatever is set as the sites preferred login screen. That login screen may or may not also be IndieAuth.
#Zegnatthinks this should be going into an Etherpad or something
#aaronpkyes i'm just saying that the plugin shouldn't always enable the web sign-in box on wordpress
#aaronpkneeds to be something the user can turn off
#Zegnatalso thinks this must have made GWGβs head spin
#aaronpkGWG [pfefferle]: another thing: if you're enabling full IndieAuth logins, that also doesn't necessarily mean you should hard-code indieauth.com for RelMeAuth as well.
#ZegnatI think indielogin.com was a hard-coded fallback?
#aaronpkanyway the main point is: for logging in to wordpress, the plugin should be a normal IndieAuth client, which discovers the user's authorization endpoint and checks the code there, no access tokens involved. when you go to add the indieauth server part to the plugin, then the plugin will be issuing its own tokens.
#GWGaaronpk: Maybe I should just bump up in priority writing my own server
#GWGTrying to use any arbitrary one is what is adding to the issue
#aaronpki'd say sort out the new login flow first, since it's going to be completely separate code from the server
#GWGBy the way, I already added a setting to turn off the login and keep the token authentication. I don't really want the login functionality, but some people do
#aaronpkwell since I have my own token endpoint, if I were to log in to one of your multi-user sites, there's nothing in what you described that would let this plugin check tokens against my endpoint
#GWGaaronpk: I haven't tried with Quill because Micropub has its own token verification code. But I intend to submit a PR to snarfed that would allow my code to optionally preempt his if installed so I can do that
#GWGaaronpk: I'll buy you a beverage on the weekend
#[pfefferle]as aaronpk said, I think we should implement token authorisation independent from authentication
#[pfefferle]and the authentication should be optional