You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the endpoint where the bot listens is public, so anyone could communicate with the bot. It would be nice if only authenticated users could access the bot from the website.
In addition, the same security token can be passed to the bot as the one provide by the website when the user logs in.
In that case, on the bot side, the access token would have to be validated to check if the user has authenticated.
If no check is performed, any user can schedule appointments for other users simply by knowing the user ID (this is known as user impersonation).
The text was updated successfully, but these errors were encountered:
The solution was easier than I thought. There is no need to pass any security token to the bot.
The only thing to do is to link the user ID in the Direct Line token, that way, Direct Line can perform an additional validation, as described in the documentation:
Direct Line can perform additional security validation of the user ID and name, inhibiting tampering of these values by malicious clients.
This means that Direct Line will use the user ID attached to the token, regardless of whether a malicious user tries to alter it.
However, there is a problem, the person ID (the identification of a user's personal information) field is still manipulable. Any malicious user can modify this field. So the proposed solution is to embed the person ID together with the user ID in the Direct Line token.
Example:
{
"user": {
"id": "dl_{userID}-{personID}",
}
}
{userID} and {personID} must be replaced by their respective IDs. Then, on the bot side, can add a code that is in charge of performing a split to obtain the IDs.
If this process is not performed, a malicious user may provide their own person ID and attempt to schedule an appointment for another user without their consent.
Currently the endpoint where the bot listens is public, so anyone could communicate with the bot. It would be nice if only authenticated users could access the bot from the website.
In addition, the same security token can be passed to the bot as the one provide by the website when the user logs in.
In that case, on the bot side, the access token would have to be validated to check if the user has authenticated.
If no check is performed, any user can schedule appointments for other users simply by knowing the user ID (this is known as user impersonation).
The text was updated successfully, but these errors were encountered: