Secure settings not all being injected via api proxy

6 Comments

  • Kaela Chandrasekaran

    I have a similar error - my setting is in a value of custom header but it looks blank when reaching the remote server. I have confirmed that the remote server does not echo back the value. Is there an issue with using a secure setting like this:

    "cors": true,
    "url":metadataSettings.baseUrl
    "method":"POST",
    "headers": {
    "Accept":"application/json",
    "abc-app-key":"{{setting.appkey}}",
    "Content-Type":"application/json"
    },
    "secure":true,
    "data":"{'appTypeID':4,}"

    1
  • Dev

    Hello everyone,

    Kaela, could you check the network tab for info about the request? If I'm not wrong, "cors": true would make a direct call to API instead of using Zendesk Proxy. That means you won't be able to use secure parameters for it because it would end up as a "{{setting.appkey}}" on your server.

    Tim, I'm don't know what's wrong with your case, it would need to play with/debug secure values. Once, I faced the issue, that Zendesk Proxy replaced values that match the secure parameter with empty values. For example, my request body looked like { email: 'test@test_domain.com'} and I had a secure parameter with value test_domain. In end up in the { email: 'test@.com'} on the server. Maybe it's something similar, or there're other sanitisers that aren't documented.




    0
  • Tim Ogilvy

    Thanks Andriy,

    If there are undocumented sanitisers on the Zendesk end, I would classify them as insanitisers because they are undocumented, and they are driving me insane :D

    An undocumented sanitiser on a free text entry field is what I would classify as a bug, not an undocumented feature.   Especially if it returns a 200 OK rather than a 400 range error indicating that the content is not viable.

    I've provided Zendesk with additional screenshots showing that emails and hex-hashes pass through the proxy untouched if added to the request in the form data, but when they are saved as secret content through the app setup, they are not included.

    I'm 100% convinced at this point that somebody on the Zendesk Dev team has updated the code that saves App Secrets with some additional boilerplate sanitiser code without realising the consequences of their actions, but let's wait and see.

    0
  • Chris Sos
    Zendesk Product Manager

    Hi Tim,

    Thanks for the detail in this post. There isn't any specific sanitisation going on with settings that isn't documented (as long as it's valid we'll accept it).

    Some things may be at play here include:

    • Caching - there is a 60 second cache on secure settings retrieval. This means if the setting is immediately updated it may not update on requests until some time afterwards. This cache exists for stability and we're investigating making this experience better (namely busting the cache when a settings update occurs).

    I'm looking over the examples and additional detail you've provided in the ticket.

    Cheers,

    Chris

    0
  • Tim Ogilvy

    Hi Chris,

    Thanks for this info, really appreciate you looking into this.  

    There's some additional info and screenshots on this ticket if you have access to it:
    https://support.zendesk.com/hc/en-us/requests/7000315 

    I'm definitely running on a fully uploaded app, and short text strings (I've just been using the phonetic alphabet) are mostly making it through into the proxy injection.  Anything else seems to go missing.

    I'm not sure if the API architecture for Zendesk is global, or instance by instance - is it possible our Zendesk instance alone has acquired a unique quirk, or would it be consistent with all others?

    I've had a go at doing the same thing with the app in sandbox also, and the same thing happens. 

    You can see that the password entry field type worked for the password, and username, but not for the client secret.   Additionally, where I've included alphanumeric and email strings in the form data, they have passed through the proxy without issue.

    Things we know for sure:

    • The proxy is successfully injecting small strings in secret mode
    • The proxy is successfully injecting some small strings which were entered in password mode
    • The settings form is successfully saving some short text, long text, and password type data, but may or may not be saving others
    • Somewhere between saving the app settings, and the final output, some fields are going missing.
    • This is not caused by caching, as this was a fresh installation of the app in the sandbox.

    Hope this helps,

    Tim

     

    0
  • Chris Sos
    Zendesk Product Manager

    That does help! Let me dig into this a bit further. I'm looking over the ticket as well :)

    Cheers,

    Chris

    0

Please sign in to leave a comment.

Powered by Zendesk