There is an implementation of Oauth in call URL actions. To be truely useful we really need database wide authorizations that we can refer to in the individual call URL actions. Until then, using HTTP-headers and refering to matching database variables is the only practical solution for any non trivial application.
ID 1463
Category TeamDesk
Author Robert Gustavsson
Date Created 8/18/2021 4:05:49 AM
Date Updated 12/3/2021 9:16:02 AM
Status Under Consideration
Score 40
Promoted By
Johannes Rossouw
Jacques du Plessis
Patricio Bustos
Robert Gustavsson
Comments
Robert Gustavsson 11/22/2021 6:52:36 AM
The new implementation of global OAuth does not seem to support a "state" parameter, which is a parameter required by our invoicing system:
Specifying constant state parameter directly in authorization URL was the workaround.
Now we are adding randomly generated state parameter to an authorization URL if it is not already specified there.
Robert Gustavsson 12/3/2021 8:34:01 AM
Is that added already? Im getting a "The remote server returned an error: (400) Bad Request" reponse when trying to save the autorization. Maybe it's "state" related, maybe not (can't see any logs).
Kirill Bondar Staff 12/3/2021 9:16:02 AM
No, it obtains authorization code, where state is required, but fails to exchange it to access_token. This seems specific to particular provider's OAuth implementation, we'll take a look.
