I am facing the 400 “Error while substituting the templates”. I’ve checked other similar threads, but I guess that my case is a bit different.
The issue occurs on the custom iparams page of one of our marketplace apps, which uses platform’s OAuth feature.
For some reason we can reproduce this issue on some Freshdesk accounts (new marketplace), while everything is fine on other ones (old and new marketplaces).
Steps to reproduce:
- Click the “Buy app” button
- Pop-up window appears, log into the account and give required permissions
- Right after the pop-up window disappears and the access token is supposed to be collected by the app, the app gets initialized and tries to make requests using that collected access token. However, these requests fail for some reason and the error is " Error while substituting the templates " (code 400).
This happens in Chrome Stable 90.0.4430.212 (64-bit), in both regular and incognito modes.
I’ve tried to clean the cache/forget the website as suggested in a similar thread, but it didn’t help and the issue is still present.
I am using the very same 3rd party account during all installation attempts.
I am aware of the recent security updates.
The latest update states the following:
Your apps can continue referring to secure installation parameters as part of the “headers” property and the request URL
However, the collected OAuth access token is used in the request URL. We can’t use any other tool (e.g.
fetch) for sending these requests, because we are limited by the platform OAuth feature in terms of obtaining the collected access token (we can use this template only -
<%= access_token %>).
Also, the app contains only 1 single secure iparam - Freshdesk API key, which is only used in headers.
Could you please help us with this?
Hope you are doing well.
Owing to security issues as updated in announcement : Security updates to the platform - 19 May 2021 - Announcements - Freshworks Developer Community , we have removed support for
access_token template substitution in body / URL of the request call. You can still access the
access_token in headers.
Thank you for the response.
However, the referenced article (mentioned in my original post, too) does not say a word regarding the
access_token or OAuth, and based on what I can see, it seems to be relevant only to secure iparams. Once again, it states:
> “Your apps can continue referring to secure installation parameters as part of the “headers” property and the request URL.”
The 3rd party API used by our app is expecting the
access_token only in the URL - the headers approach is simply unavailable.
If the support for
access_token has really been removed, then it is a real disaster - the already published marketplace app with customer base is broken due to the broken platform OAuth.
Firstly, apologies for breaking this for your customers @ilya.belyavskiy. The security issue underlying this change was serious enough for us to roll this out without sufficient warning and take the hit.
We do have a way to keep apps like yours that use a middleware and leverage the Request Method to pass secrets to the middleware to keep running in the interim while the apps are updated to meet the new restrictions. Please write to us at firstname.lastname@example.org or DM @Raviraj or @Saif here on the forum to share details of the affected apps and we can get them working again.
I have also updated the announcement based on your feedback - we did indeed miss a couple of important details. Apologies for not being thorough on that front either.
I look forward to supporting you with an updated, more secure version of your app as well. Our Developer Advocates and App Review Teams will be on standby to help you with that.
Thank you @satwik!
We’ve forwarded the support ticket to email@example.com. I hope together we’ll manage to find the solution soon.
This should be resolved for your Instagram app now @ilya.belyavskiy. Please do confirm the same when you get a chance.
@satwik I’ve just installed the app on one of our accounts and everything seems to be fine now.
Huge thanks to the Marketplace team!
Thanks for confirming @ilya.belyavskiy. Apologies once again for the poor customer experience your users must have experienced in the meantime.