Added client_id to micropubDocument

[EdwardHinkle]

Added a variable that carries the client_id through from the token authorization step to the micropubDocument.

[EdwardHinkle]

I've verified that the client_id passthrough works. This code is currently running on production of https://eddiehinkle.com and successfully marking my checkin posts as having the client_id of https://ownyourswarm.p3k.io in my output file.

[EdwardHinkle]

I see the test wants to force all variables to be const or let. I don't know enough about the nuances between const, let and var to know if the way that I'm using micropubClientId could be changed to a let. From what I understand, it would cause an error.

Basically the issue is capturing the variable on line 243 and then using it on line 349 which are in completely different functions and blocks. So I'll leave the thinking through of the no-var test and the implementation up to you all.

[voxpelli]

On the issue of var, let and const the answer would be let – it allows the assigning of the value later on just like var does (but be improved in such ways as to disallow multiple declarations of same variable within same scope)

Regarding the PR in itself though: I'm afraid it doesn't work assigning the value as you do.

The reason it doesn't work is the asynchronous nature of Node.js. Multiple incoming requests can be processed at once and a subsequent requests can thus have it's validateToken() be executed prior to the first request making use of the value that it had assigned when it executed validateToken().

The correct way to pass the value would be to have validateToken() return it and then pass it upwards through matchAnyTokenReference() so that it becomes available to the middleware that extracted the token from the request object:

node-micropub-express/index.js

Line 310 in 699da7d

.then(valid => {

There the currently boolean valid could then instead be an object containing any relevant metadata fetched and that could be assigned to the req object through some kind of relevant property (maybe req.micropubExpressTokenProperties or something) and that property could later be accessed in the place where you are now inspecting the global variable and thus you would get a request specific value rather than a global value.

On the topic of the client_id itself – I'm a bit outdated on where that actually comes from. Do you have a link to the wiki where the client_id is specified? (Don't have time right now to look into it further unfortunately 😕)

[EdwardHinkle]

Ohhh, I see what you're talking about in regards to the multiple requests and losing the value. When I have some time, I'll look through adapting this to work correctly. My current solution will work for me in the short term as I'm only using micropub with OwnYourSwarm and Teacup so the likelihood of them happening near the same time is almost none. However, I do plan on expanding my micropub support fairly quickly so I'll need to fix that glitch on my site as well before that kicks my site.

As far as client_id, it comes from the micropub application and is sent to the auth endpoint and token endpoints. The purpose is to identify to the user (through the applications) which micropub application is accessing their site. So for example, this would be https://ownyourgram.com, https://teacup.p3k.io and https://quill.p3k.io. Of course there are plenty more :) This is what helps IndieAuth show the Application Name and Icon to the user when going through the authorization flow. Aaron Parecki currently also uses it on his site to show the "Using" at the bottom of a post like this one: https://aaronparecki.com/2017/04/25/26/

That is my eventual goal as well, to be able to show what application I used to make the post that a user is looking at.

There is more about it here: https://indieweb.org/obtaining-an-access-token#Token_Endpoint