Proxy error: UnprocessableEntity, Failed to get installation and oauth information for app | Community
Skip to main content

Proxy error: UnprocessableEntity, Failed to get installation and oauth information for app

  • January 20, 2022
  • 48 replies
  • 0 views

Show first post

48 replies

Greg29
  • November 19, 2024

Hi Rocky! It's difficult to say exactly what problems you may be experiencing based on the code that you shared. I initially thought it may be due to the secure settings that you're using, but I don't think that's the case. Are you able to successfully send this to your service or even something like pastebin from a tool like Postman? It will help narrow down whether the issue is with the code or with the apps framework. Please share any other troubleshooting that you've done.


  • March 6, 2025

Hi - Is there a solution for the Proxy error: UnprocessableEntity, Failed to get installation and oauth information for app.  I have an app that when installed, works initially but then returns this error. If I reinstall the app it works again.  The app is authenticated correctly via Oauth in the App settings.  I have "parameters": [{"name": "token","type": “oauth”}] set in the manifest and the correct OAuth block.  Within my request I am using Authorization:"Bearer {{setting.token}}" as per the docs. I am wondering if it occurs once the authorisation token has expired and isn't being refreshed. I am using Auth0 as the OAuth provider.


Greg29
  • March 7, 2025

Hi Andy! My first guess would be an issue with the refresh if it's missing certain values on the initial token response. Take a look at this note and let me know if either of those are missing.


  • March 10, 2025

From the OAuth Docs and sample request, I get the following response which looks to be as expected { "access_token":"e…w", "refresh_token":"GEb…XbL", "id_token":"eyJ…EoQ", "token_type":"Bearer", "expires_in":86400 }


Greg29
  • March 10, 2025
Would you mind sharing the relevant parts of your manifest, while obfuscating any secrets and also the code block where you make the request?

  • March 11, 2025
{
  "_warning": "AUTOMATICALLY GENERATED FROM $/src/manifest.json - DO NOT MODIFY THIS FILE DIRECTLY",
  "name": "...",
  "author": {
    "name": "...",
    "email": "...",
    "url": "..."
  },
  "defaultLocale": "en",
  "private": true,
  "location": {
    "support": {
      "ticket_sidebar": {
        "url": "assets/index.html",
        "flexible": true
      }
    }
  },
  "parameters": [
    {
      "name": "token",
      "type": "oauth"
    }
  ],
  "oauth": {
    "client_id": "0...K",
    "client_secret": "r...f",
    "authorize_uri": "https:....eu.auth0.com/oauth/authorize",
    "access_token_uri": "https:....eu.auth0.com/oauth/token",
    "scope": "openid profile email",
    "secure": "true"
  },
  "version": "1.0",
  "frameworkVersion": "2.0"
}

 const fetchData = async () => {
    try {
      setLoading(true);
      const data = await client.request(buildRequest(url));
      setData(data);
      setError(null);
    } catch (error) {
      setError(error);
    } finally {
      setLoading(false);
    }
  }
  
  const buildRequest = (url) => ({
  url: `${import.meta.env.VITE_API_URL}/api/${url}`,
  type: "GET",
  headers: {
    Authorization: `Bearer ${import.meta.env.VITE_JWT_TOKEN}`,
  },
  contentType: "application/json",
  secure: import.meta.env.VITE_SECURE_OAUTH === 'true',
});

Greg29
  • March 11, 2025
Thanks for that Andy! I'm not seeing where you're using the OAuth token in this request...the Auth headers are referencing a JWT, not the OAuth token that you defined. So I think the issue here is that your JWT is expiring and the OAuth token is never being used. Could you update the request to use "Bearer {{setting.token}}" instead? 
 
Also, not sure if this will matter, but I don't believe you need to specify the oauth object as secure itself, you just need to set that in the request. Let me know if this resolves it all for you.

  • March 12, 2025

Hi, I will remove the secure prop - to support local dev the ${import.meta.env.VITE_JWT_TOKEN} is compiled to Bearer {{setting.token}} when in prod and is substituted with an actual token locally.  As I say, the app works fine the first time it is installed (so the token is correctly substituted for at least some of the time).


  • March 13, 2025

Just as a follow up - this is a chunk of the minified code showing the placeholder being inserted.

{Authorization:"Bearer {{setting.token}}"},contentType:"application/json",secure:!0}),g=(s,t)=>{const[a,r]=x.useState(!0),[l,c]=x.useState(null),[n,i]=x.useState(null);x.useEffect(()=>{d()},[s]);const d=async()=>{try{r(!0);const o=await t.request(v(s));i(o),c(null)}catch(o){o.status===401?c("Please ask a Zendesk administrator to re-authenticate with Auth0"):

  • March 13, 2025

I have tried setting the secure property to false within the Oauth property - as expected this fails with invalid token as the substitution is not made.


Hi Andy,
 
I'm Chris from our Developer Support team, stepping in to assist while Greg is unavailable.  I took a look at the details you shared and as a next step I'd like to review some logging of a request attempt.  To help with this, can you reproduce the proxy error again and let me know the timestamp of the attempt?
 
Best,
 
Chris Kennedy | Developer Advocate

  • March 24, 2025

Hi - I have successfully authenticated using the bearer token at 2025-03-24T11:12:00, I will wait until the token expires and let you know the timestamp when I get the failure message. Kind regards Andy


  • March 24, 2025

Hi, at 2025-03-24T15:54:22 the API returned Proxy error: {:code=>"UnprocessableEntity", :status=>"422", :title=>"Unprocessable Entity", :message=>"Failed to get installation and oauth information for app."} when hitting https://problemsharedengineeringhelp.zendesk.com/proxy/v2/apps/secure
 


  • March 25, 2025

I was able to authenticate upon initial load/install of the app but I don't have any way to see logs when it goes for refresh token.
This worked successfully 5 hours ago. and when i came back to it I am getting this error. so I am assuming the refresh token failed, the expires_in key is in the response from the token endpoint.  
Please see link below

https://app.ninjarmm.com/apidocs-beta/authorization/flows/authorization-code-flow
 
ZAF client Support App Function:

async function getDevices() {

  if (!token) {

    console.log("Failed to obtain access token");

    return;

  }

  try {

    return await client.request({

      url: "https://app.ninjarmm.com/api/v2/devices-detailed",

      type: "GET",

      headers: { Authorization: "Bearer {{setting.token}}" },

      secure: true,

    });

  } catch (error) {

    console.error("Error fetching devices:", error);

  }

}

Manifest portion regarding oauth:
  "parameters": [

    {

      "name": "token",

      "type": "oauth"

    }

  ],

  "oauth": {

    "response_type": "code",

    "client_id": "************************",

    "client_secret": "**********************************",

    "authorize_uri": "https://app.ninjarmm.com/ws/oauth/authorize",

    "scope": "control monitoring management",

    "access_token_uri": "https://app.ninjarmm.com/ws/oauth/token"

  },


Hello,
 
Thanks for the info.  In our logs I can see that our OAuth connection service fails to refresh because it did not receive a refresh token from NinjaOne on the initial authorization.  To allow a refresh token to be returned, can you please include an offline_access scope in the app's manifest?  NinjaOne's docs note that this scope is required for them to return a refresh token.
 
Best,
 
Chris Kennedy | Developer Advocate

  • March 27, 2025

Hi Chris, Can you check the logs for our issue - we are using OAuth. Regards Andy


  • March 27, 2025

I will take a look at the docs and see if the offline_access is also required for Auth0


  • March 27, 2025

That was it, dont know how i missed that, thank you 


Hello,
 
No problem.  I'm glad to hear it's working for you!
 
Best,
 
Chris Kennedy | Developer Advocate

  • March 28, 2025

Hi  Chris,  Can I confirm that you are able to look at the logs to help us pinpoint our issue.  The issue that Parth Patel raised is different to ours.  I can confirm that we have tried all of the steps that Jerry has posted above.  We have also added the additional scope of offline_access.  Our integration is Auth0.  Again, it is working as expected once the app is installed, but we see the  422 error at a point where we think the token way not refresh (although I cant confirm unless someone can look at the logs).  Again, an example timestamp would be 2025-03-24T15:54:22.  We also saw the issue again this morning.  Reinstalling the app fixes the issue temporarily.


Hi Andrew,
 
Sorry for the confusion.  I created a ticket work with you one-on-one.  I have a reply with next steps there.
 
 

  • April 16, 2025

Hi, 

We are having same issues with an app being developed for one of our customers. 

If I bypass the secure setting/proxy and manually enter an access token for the app then the requests go through and we get data.

However, when we try to go via the secure proxy we get the same error with 

{:code=>\"UnprocessableEntity\", :status=>\"422\", :title=>\"Unprocessable Entity\", :message=>\"Failed to get installation and oauth information for app.\"}

In the app settings we have successfully logged in and it is showing a green check marker next to the Oauth login.

Everything in manifest.json also looks correct

"parameters": [
    {
      "name": "baseUrl",
      "type": "text",
      "secure": false,
      "required": true
    },
    {
      "name": "token",
      "type": "oauth"
    }
  ],
  "oauth": {
    "client_id": "Z****",
    "client_secret": "5*****",
    "authorize_uri": "https://***/identity/connect/authorize",
    "access_token_uri": "https://***/identity/connect/token",
    "scope": "***"
  },

And when checking Network in the browsers Developer Tools I can see that it is correctly including Bearer {{setting.token}} for Authorization.

Would appreciate some assistance in checking logs as I can't really see anything wrong in the app itself for this.


Hi Nicklas,
 
It looks like your OAuth provider is not providing a refresh token on successful authorization.  Can you please refer to their documentation for more info on how to ensure it sends a refresh token along with the access token?