my pb is simple, we want to send a Patch type request to assign a value in a field, in an open source crm that accepts requests with an oauth 2.0 via a berear token.
This token is generated via a get type method, with the Oauth user and Oauth password in the header, in the crm response there is the bearer token.
Currently, we manage to send data via the crm to iTop with a specific extension (core/update, core/create, etc...) And it works.
In the other direction it is less obvious.
So we tried with the webhook call generics, but we are limited in the lack of documentation on this subject.
Does anyone have concrete examples of the type: Prepare payload callback &
Process response callback - Playload (with call value)
Is it possible to launch a webhook call generic of method GET type and save the token in the database?
And then reuse it in a call generics webhook of type PATCH method by generating the header of this method with the token? (we created an extension to add a field with the id token of type txt in the sql of the webhook call generics)
A big thank you in advance for your examples or for your answers.... X_x @glajarige@jbostoen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I only made a concept of a custom REST action quite some time ago, before Combodo published their webhooks feature. So far I'm unfamiliar with it.
My guess is that an extenion would need to be developed which extends the webhook to do this first call, store this token (if necessary? or simply re-use it), and do the next request.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@jbostoen Yes, because the token expire on 3600 seconds. You need first webhook for take & store it, before any requests and after you need make webcall with the token bearer on the header. ...
I make one module for add value field in webhook call, but idon't know afterwards how to save it in this same field with the Process response callback.
And after put in the same field but in a other webhook call id., for after call him in the structure of header.
Last edit: Franck 2022-03-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Either you store both the token and the expiration date; or you use the token till you have an error and request a new one which you then store again; or request a new token each time (no need to store for a longer period)
But I think a custom webhook is your best shot for this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A ticket is created -> Triggering of the webhook call name "call token" (recovery of the token and injection into the Token field (this part is missing an example of a callback response webhook))
-> A second trigger is launched when the token value is entered and launches a webhook call "send data" with the token in the header which has a fixed field in the webhook "call token" launched previously.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hm, you would be able to do this with an "object update" trigger on the class where you'd store this info in.
But then you still need to get the original info from the object that initially triggered your webhook.
I'd go for an approach where you only have one webhook, which takes care of this entire process (even if it takes a bit longer). An extended or custom webhook is probably best, where you indeed store the token and handle it one of the two ways (request new one upon error; and/or when expired - compared to the stored timestamp)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With the OAuth authentication, you need to make 2 calls to the third party app:
- A first one to get the token as you explained
- A second one to do the actual call
The webhooks are by design supposed to do only 1 call, so they won't work as is with the OAuth mechanism.
As Jeffrey, I think the best solution would be for you to extend the WebhookAction class with your own to take care of the token creation/renewal process internally before making the actual call. We don't have examples about OAuth, but you can check how the other webhook actions extends the generic one, it will give you an hint.
Cheers,
Guillaume
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello to the whole community,
my pb is simple, we want to send a Patch type request to assign a value in a field, in an open source crm that accepts requests with an oauth 2.0 via a berear token.
This token is generated via a get type method, with the Oauth user and Oauth password in the header, in the crm response there is the bearer token.
Currently, we manage to send data via the crm to iTop with a specific extension (core/update, core/create, etc...) And it works.
In the other direction it is less obvious.
So we tried with the webhook call generics, but we are limited in the lack of documentation on this subject.
Does anyone have concrete examples of the type: Prepare payload callback &
Process response callback - Playload (with call value)
Is it possible to launch a webhook call generic of method GET type and save the token in the database?
And then reuse it in a call generics webhook of type PATCH method by generating the header of this method with the token? (we created an extension to add a field with the id token of type txt in the sql of the webhook call generics)
A big thank you in advance for your examples or for your answers.... X_x @glajarige @jbostoen
I only made a concept of a custom REST action quite some time ago, before Combodo published their webhooks feature. So far I'm unfamiliar with it.
My guess is that an extenion would need to be developed which extends the webhook to do this first call, store this token (if necessary? or simply re-use it), and do the next request.
@jbostoen Yes, because the token expire on 3600 seconds. You need first webhook for take & store it, before any requests and after you need make webcall with the token bearer on the header. ...
I make one module for add value field in webhook call, but idon't know afterwards how to save it in this same field with the Process response callback.
And after put in the same field but in a other webhook call id., for after call him in the structure of header.
Last edit: Franck 2022-03-01
Are there a lot of notifications?
Either you store both the token and the expiration date; or you use the token till you have an error and request a new one which you then store again; or request a new token each time (no need to store for a longer period)
But I think a custom webhook is your best shot for this.
I thought of this step by step:
A ticket is created -> Triggering of the webhook call name "call token" (recovery of the token and injection into the Token field (this part is missing an example of a callback response webhook))
-> A second trigger is launched when the token value is entered and launches a webhook call "send data" with the token in the header which has a fixed field in the webhook "call token" launched previously.
Hm, you would be able to do this with an "object update" trigger on the class where you'd store this info in.
But then you still need to get the original info from the object that initially triggered your webhook.
I'd go for an approach where you only have one webhook, which takes care of this entire process (even if it takes a bit longer). An extended or custom webhook is probably best, where you indeed store the token and handle it one of the two ways (request new one upon error; and/or when expired - compared to the stored timestamp)
Hello Franck,
With the OAuth authentication, you need to make 2 calls to the third party app:
- A first one to get the token as you explained
- A second one to do the actual call
The webhooks are by design supposed to do only 1 call, so they won't work as is with the OAuth mechanism.
As Jeffrey, I think the best solution would be for you to extend the WebhookAction class with your own to take care of the token creation/renewal process internally before making the actual call. We don't have examples about OAuth, but you can check how the other webhook actions extends the generic one, it will give you an hint.
Cheers,
Guillaume