This will be an extremely helpful sample for embed users.
This PR was created by @compulim, but needs to be redone.
I think a token server is not a standard use of WebChat. Generally, when the page hosting WebChat is loaded, the secret should already have been exchanged for a token and that token sent back with the page itself. Having the client retrieve the token should not be our recommended method of hosting WebChat. Having an open server endpoint that can retrieve a valid token by anyone basically enables anyone to host the bot anywhere, with their own UI.
Token server is all @compulim's brain child so I think we'll need to loop him into this discussion. Right now all of our samples use a token server and we don't have a sample for helping users build that token server.
As far as I know he limits which websites can make a call to the token server. All others are blocked. https://github.com/compulim/BotFramework-MockBot/blob/master/src/index.ts#L120 Thoughts?
TrustedOrigins definitely makes hosting the bot from a different ui more difficult. However, it is still overkill for us to recommend WebChat users spin up a token server ... when all they really need is for their existing website to exchange the secret for a token before serving up the page containing WebChat. I understand William's need for a token server in the context of the WebChat samples, and this might be a requirement for some of our users as well (the sample is good, but should not be our standard recommendation). The vast majority of WebChat users will not need this.
Sounds reasonable to me. :) Once William's back we can talk about improving the accessibility of fetching token in Web Chat's samples. LMK if you want to discuss anything else.
@corinagum @EricDahlvang Are there any updates to this thread? A token server feels overkill for my needs but at this stage seems like the only solution i can find.
I casually talked to the service team few days ago. They didn't exactly like the idea of using HTTP referrer header to get the authorization token, on a security standpoint.
Yes, token server feels overkill but it is inevitable until we figure out a good solution.
@Zuitman it will be great if you could file an issue to https://github.com/microsoft/botframework-services and talk about how to simplify the authorization token flow. The issue will gain more visibility across the services team.
@Zuitman I bet you already know how to write a token server. But @corinagum still wants me to give you a bit reference on that. 馃槅
In our MockBot (the bot we use to test Web Chat), you can find the token server implementation here, https://github.com/compulim/BotFramework-MockBot/blob/master/src/index.ts#L134.
This work is more-or-less:
Closing this as a dupe of #1412
Most helpful comment
TrustedOrigins definitely makes hosting the bot from a different ui more difficult. However, it is still overkill for us to recommend WebChat users spin up a token server ... when all they really need is for their existing website to exchange the secret for a token before serving up the page containing WebChat. I understand William's need for a token server in the context of the WebChat samples, and this might be a requirement for some of our users as well (the sample is good, but should not be our standard recommendation). The vast majority of WebChat users will not need this.