How can we handle Callback URL redirection in FD serverless app?

Hi Saif, Raghu,

Thanks a lot for your time. We will check with our team regarding the payload and confirm to you guys on the developer forum on what we plan to do.
One more thing, I wanted to confirm with you. Suppose we manage to get the token in access_token variable, your FD platform itself will re-use the same token until it gets expired and then generate a new one from token url?
If not, any feature on FD for this as well? The thirdparty token is valid for around 1 hour. After that a new one is required to be generated…so can this also be handled in the FD app platform through some configuration?

Yes, @rohan15.

Platform it self will refresh the access_token with the help of referesh token.

Summary for this thread followers

Rohan is trying to implement a OAuth mechanism with a 3rd OAuth service. On the way he discovered that he doesn’t have to implement OAuth exchange himself but freshworks platform provides OAuth 2 capabilities.

  • However, upon following to leverage this feature, Rohan found that platform is not able to fetch access_token sent by 3rd party provider.
  • We got on a call and found out that the payload being sent by the 3rd party has property naming it accessToken instead of access_token as per official standard response structure.

Rohan is trying to find a workaround to solve this problem. One of the options to consider is to use a Middleware that can translate to the standard response structure for our platform begin OAuth cycle.

2 Likes

Hi Saif/Team,

With reference to our last post, the third party is trying to we will provide a new oAuth endpoint with below request/response.

Could you please help to confirm the same today, so that we can ask them to go ahead?

{
“status”: “approved”,
“access_token”: “Cd0Vh5g44IuRqBGdrrOh0”,
“refresh_token”: “muFpsulLCzAB4HyfnYwAIfroN”,
“expires_in”: “2399”,
“scope”: “”,
“token_type”: “BearerToken”
}

Request will be same like before:
POST /oauth/v1/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
grant_type=authorization_code&client_id=SpxYtZAMgUfD1XjTmHmZ1yzZf91xuKp8&client_secret=NyzsTWj5lHXctxwz&code=xhFSO5kM

The structure adheres to RFC standards. This should be fine @rohan15.

Hi Saif/Team,

The third party had deployed the Oauth endpoint with the RFC protocol standards. We tested it and our serverless app is now able to do the Oauth2 authentication and get the access_token for calling the SMS API.
Could you please help to clarify the below 3 points as well:

  1. Yesterday night we had initiated the request and access_token was generated. Today when we hit the request for the first time, we got “Token Expired” from third party. It was only after we deleted the .fdk file , the access_token got replaced. Will we need to delete .fdk folder everytime in FD test environment? When we deploy in FD production , how will this run ? Will it be handled automatically or manual intervention be required? As per the last document shared, the authorization_code from url redirection is for 1 time use only.

  2. Secondly, after token is being substituted, and Third Party API is being called, the SMS is being sent as expected by third party. Third party is returning JSON response body as well , however what we can understand from below logs is that at FD side it’s being treated as an error response because it can’t find “Application/json” (A capital). Any workaround for this at FD side to show it as SUCCESS?

    FDK 3468: (proxy.js) Proxy came back with error as null, body as {“id”:“631021001”,“type”:“TEXT”,“status”:“SUCCESS”,“sentTime”:“2020-05-15T12:55:56+06
    :30”,“content”:
    FDK 3468: (proxy.js) Looking for “Application/json” in application/json,application/xml,text/html,text/xml,application/jsonp,text/plain,application/ja
    vascript,application/vnd.api+json
    error { status: 415,
    headers: {},
    response: ‘Unsupported content type’,
    errorSource: ‘APP’,
    attempts: 1 }
    FDK 3468: (coverage-util.js) Writing coverage.

  3. Do you have any concept in FD serverless app for an external property file that can be updated on runtime? Basically we would like to keep the SMS texts in a property file such that the text can be changed whenever required without redeploying the application.

Hi Saif, Team,

Would like to add 1 more question in addition to the above 3:
Currently this servless app is being invoked onTicket creation event only. If we want this single serverless app to be invoked onTicketCreation, onTicketClose and onTicketUpdate events how would we need to modify our server.js so that it can be invoked on all 3 events. Could you please provide some samples for the same?

Hello @rohan15,

  1. Yes, for the app in production the exchange of token is automatically handled by the platform itself.
  2. Since you functionality of app: sending SMS is being achieved, does this error message obstruct you from the your app running in any way? Meanwhile, I will find out if there’s any thing that we can do on our end.
  3. Did you get a chance to checkout out External events feature? What you are trying to achieve is seems to be a bit close to it.

Hi Saif/Team,

Please find below comments:

  1. Therefore, it means , in TND, we will basically need to delete the .fdk folder everytime the token has expired right, as token referesh didn’t happen here? In production this will be handled automatically.
  2. Yes, please help to check if the error message could be resolved. Functionality is being achieved but it would be great if we could get this marked as SUCCESS in the logs.
  3. Just wanted to confirm, if we want the serverless app to be invoked on both onTicketCreation and onTicketClose, is External events feature the recommended way or can we add this event somehow directly in our server.js? Could you explain briefly how we can add these 2 events-ticket create and ticket close in the same app such that for onticketcreate FUNCTION 1 is called and for onTicetClose FUNCTION2 is called in the same app?
    4.Also could you please suggest regarding the below as well:
    Do you have any concept in FD serverless app for an external property file that can be updated on runtime? Basically we would like to keep the SMS texts in a property file such that the text can be changed whenever required without redeploying the application.

You can do same function declaration and definition out the exports block and make a function call inside the any product event that you want. I hope that should help you solve the problem.

  1. Yes. Incase, the access token expires, the CLI will automatically, try to refresh using refresh tokens. In the production this mechanism is handled automatically.
  2. I will get in touch with some of our platform engineers find help and keep you posted.
  3. In your case, if you want same functionality to be triggered, please follow this method.
  4. External events feature actually gets you a webhook. Where required functionality will get executed which is defined under onExternalEventHandler is triggered. What you can do, is to send a POST req to the generated webhook URL with the message and can leverage iparams functionatlity to set the required message to send SMS.

Thanks Saif/Team.

We will check the above information and try to implement the same.

Could you guys also let us know that in the PAYLOAD for onTicketCreation and OnTicketClose, which parameters do we refer to for getting the ticket id number ,ticket creation date and expected resolution date? Actually, we need to send this information in our SMS.

Hi Team,

Please help to provide the above details regarding ticket details from onTicketCreate and onTicketClose payload. Thanks

Kindly refer to the developer docs for payload reference -> Freshdesk Product Events

Thanks Hemchander for the information.

Hi Saif/Team,

Could you please check with platform engineers today on the below point and let us know the update?
If they could include the header mentioned?

Yes, I’ve checked with the team. Unfortunately, we won’t be able to makes changes on our platform. The solution goes as discussed before to write a middleware or changes within 3rd party response following RFC standards.

Ok Saif, we will need to discuss with our team once regarding this.

Need some more info:

  1. Is there any utility in FD which can convert string text to UTF-16 Hexa String (unicode). We are able to send English texts in SMS but for sending SMS in English and Burmese languages, we need to convert it to unicode. Here ticketid will be passed dyanmically in the SMS. Please suggest if there is any feature we can use.
  2. Also, we would now have to gradually deploy this in FD production. Could you guys please share the related links for:
    a.) Deployment on production.
    b.) Removing and adding another version of the build.
    c.) Authorizing app on production. In testing environment, we were able to find the authorize button on test console. Where would we find this option in production

Hi Team,

In addition to the above queries. Please help with the below:
We deployed the app as a custom app in production. Created a ticket on the portal but SMS was not sent although it was working in production. Status is also shown as internally published. Please let me know where I can find the logs on the FD account portal in production and if anything else is needed to be done to run in production?

Hey @rohan15,

  1. Since this login runs on the server.js, you can use any 3rd party npm package to convert string text to UTF-16(unicode).
  2. Now that you have deployed as a custom app, you can refer to this page on troubleshooting to see the logs.

Hi Saif/Team,

We were able to deploy the app in production and SMS is also going on ticket creation and closure. However, we are observing that once authentication token is getting expired , after say 1 hour, we are getting token expired error while calling the SMS API as it seems the token was not refreshed. Only after we go to custom apps and click on reauthorize, the SMS API is accessible again.

Can you guys please help us to debug this, as we are not seeing any detailed errors in the logs on production. This token refresh should happen automatically as discussed earlier.