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
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."
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?
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.
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.
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?
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
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.
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
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.
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
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.)
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.
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.
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.
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.
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.
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