Add mechanism to allow bot to authenticate and to get tokens on user's behalf #192
Conversation
| - The API is now available on your machine at `localhost:8080` | ||
| - The Admin server is now available on your machine at `localhost:8000` | ||
| - **Note** to get the Discord bot auth to work, you need to send a curl request | ||
| after the service is initialized: `curl -XPOST http://localhost:8080/_configure -d '{"DiscordBotCredentials": {"Username": "<username>", "Password": "<password>"}}'` |
There was a problem hiding this comment.
Do you need both username and password? We won't have multiple bots with different purposes?
There was a problem hiding this comment.
Probably not. I was just following Basic auth standard. I don't think it matters much either way
| @@ -417,6 +461,88 @@ func getOAuth2Config(ctx context.Context, r *http.Request) (*oauth2.Config, erro | |||
| }, nil | |||
| } | |||
|
|
|||
| func handleGetTokenForDiscordUser(w ResponseWriter, r Request) error { | |||
There was a problem hiding this comment.
Is this just a convenience function for superusers, or?
There was a problem hiding this comment.
This is what allows the bot to make requests on behalf of a user. Here's the flow
- Bot gets command from user
- Bot gets bot-token from Diplicity (using basic auth)
- Bot gets user-token from Diplicity (using this endpoint - bot is a super user)
- Bot makes subsequent requests on behalf of user by using user-token
There was a problem hiding this comment.
I think you use 3 steps (bot authenticates to become superuser, bot gets user token as superuser, bot acts as user) where you could use 2 steps (bot gets user token by using bot authentication, bot acts as user).
I mean, do other superusers need this 'act as user' power? Not so far, I think.
Also, I hope you cash the first 2 steps (or first step in my case) for a few minutes in the bot service, so you don't have to make 2 requests for every operation.
There was a problem hiding this comment.
Yeah, I think you're right. But maybe this is a little cleaner. Now the bot has a superuser token that it can use for other things in the future if needed. For example, when it's responding to an async event like the game ending for example, we might want it to then do something, but it doesn't have a user ID to get a token for, so it's nice that it can just operate as a user in its own right. For example, suppose we wanted the bot to delete a game when the game ends (unlikely).
There was a problem hiding this comment.
I will cache the responses later for sure. But for now I'm just fetching them again each time. Should be a straight forward optimization later.
There was a problem hiding this comment.
Note that the superuser access isn't something that's generally used, and it shouldn't be a part of business-as-usual. Currently it's only used when I find strange bugs in the database and need to create a new endpoint that fixes that, that should never be called by mistake or by anyone else.
|
Looks good in general, I think. |
No description provided.