Workspace Apps X-Slack-User HTTP header
curtisallen opened this issue · comments
Thanks for continuing to refine this client 🤓!
The upcoming Slack Workspace Apps (Still in Beta) will allow some actions to happen on behalf of a user without using the user parameter; an X-Slack-User header will be required instead.
From https://api.slack.com/docs/working-for-users#acting
POST /api/reminders.add
Authorization: Bearer xoxa-123456-abcdefghijklmop
X-Slack-User: WH1MPY
Content-type: application/json; charset=utf-8
{"text":"Pay Popeye back for that burger", "time": "every tuesday"}
This slack module would likely need to expose a way to set this X-Slack-User header.
Not sure how'd we go about doing this as the slack documentation doesn't list X-Slack-User on the Web API methods as of this writing.
Should be pretty easy to add an option which propagates the user parameter to the headers in the various HTTP client implementations. I've been intending to much around in there to change the oauth token to use the Authorization header anyhow.
Would be good to get some official guidance from Slack on this before we do anything drastic. My main goal would be to keep things backwards compatible as much as possible!
cc @beardouglas
Any guidance super appreciated!
@brianleroux @curtisallen 👋 thanks for looping me in. its super-timely as we were just discussing how we might support this in other clients.
i think ideally an additional argument is accepted in the "bag" of arguments that are passed straight through to the API. this would be the easiest for the users of this package. the difference is that this one argument needs a special name because it will be picked out of the rest and serialized as a header instead of in the body (url-encoded or JSON-encoded). that special name is where we need some consideration. i don't think user is a good choice because it already appears in many methods. it has to be something that's unlikely to even show up as an argument in future methods. my proposal, which i feel pretty good about, is actor. i think it makes code that uses this argument very clear about what using the value means. do you agree?
Sure, that could work. Do you think adding new header params could become a more common thing? Could imagine baking a more generic practice if so. Given this is sort of an execution context modifier I could see it being a ctor option too maybe. 🤷♂️
i don't see it becoming more common. but also, never say never.
a peek into how this design came about: we're calling the methods that can access user perspectival data as workspace apps "user data APIs". in these user data APIs, the user whose perspective is being used, whose data is being accessed, is actually more closely related to the authorization than the inputs (arguments). authorization information is currently carried in HTTP headers, and arguments in the GET params and/or POST body. hence, the idea of placing the user ID in the headers.
given that bit of context, i don't think there's a ton of places where more header-encoded inputs makes sense.
sgtm! w this context I'm thinking we make this an opt in from the ctor. while user gets used a lot it is the thing being set/done so I'm feeling its more idiomatic (and less things to explain):
let Slack = require('slack')
let user = 'xxx' // some user id
let token = 'xxx' // some workspace token
let slack = new Slack({user, token})Do you know/could you find out: is X-Slack-User ignored by other methods that don't use it (or do we have to make this a thing we validate/map in on a case by case basis)?
adding user and token on the top level constructor would cause more confusion IMO. I love how the current client has a direct 1:1 mapping with the official slack documentation. It works so well that hardly ever look at the API docs for this module. Adding a ctor breaks this simplicity IMO.
slack.reminders.add({token, text, user, time}) seems better to me.
🆒 glad you like it, that was the way I sorta intended it to be used and was how we built up on top of it. the classy style was by popular request and its been an opportunity to layer up as slack itself adds new things (or changes old things).
but hey: we can do both! we can add user to the ctor and a param to the unbound, stateles and pure methods of yore. agree w @aoberoi is maybe be confusing given user is overloaded; how do you feel about actor as suggested?
thanks, @brianleroux yeah I agree actor makes more sense 💯