• Kaela Chandrasekaran

  • October 04, 2021 04:56

  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,}"
  
  

• Andriy Pelykh

  • October 05, 2021 15:10

  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.
  
  
  
  
  

• Tim Ogilvy

  • October 07, 2021 03:18

  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.

• Chris Sos

  • October 07, 2021 03:32

  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).

  • Local usage - I'm sure you're aware, but secure settings aren't populated if you're just using the local server command (unless you're specifying an installation ID to attach to).

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

  Cheers,

  Chris

• Tim Ogilvy

  • October 07, 2021 03:58

  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

   

• Chris Sos

  • October 07, 2021 04:37

  Zendesk Product Manager

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

  Cheers,

  Chris

Please sign in to leave a comment.