Tim Ogilvy

Looks like the app scaffolds have been updated too... very helpful!

https://github.com/zendesk/app_scaffolds

Is the only way to keep up to date with this stuff to dig around, or am I missing an obvious thread somewhere?

Ok so the same principle will work for testing as it does for development.

Probably not ideal, but here's my react hook for now to get a client mock in during testing. I'm sure there's a better way using mocks in jest.conf.json, but I haven't been able to make it work yet.

import ZafDevClient from '../ZafDevClient/ZafDevClient';

let zafClient;

export const useZafClient = () => {
  if (!zafClient) {
    // eslint-disable-next-line no-undef
    zafClient = process.env.NODE_ENV === 'test' ? ZafDevClient : ZAFClient.init();
  }
  return zafClient;
};

Ok, by using https://www.npmjs.com/package/dotenv-webpack I've been able to inject secrets into my local development shim for the ZAFClient...  which should allow me hopefully to hit my dev api server from the iFrame... that will be the next test.

I'm pretty much preserving this processes as a comment blog at this point.  If someone wants to tell me I'm crazy and there's an easier way, I'd love to hear it!

I'm looking at the documentation for testing with secure settings here: 

https://developer.zendesk.com/documentation/apps/app-developer-guide/using-the-apps-framework/#testing-an-app-with-secure-settings-locally 

It's a bit cryptic, unclear if that will use the proxy and inject secure settings or not.

Ok...  I'm using a react hook to access the ZAFClient as a singleton, to avoid inadvertently creating new instances of it.   I can use process.env.NODE_ENV to switch between the two, which means I can start to make a mockery of it.

The hook also helps with eslint rules - the global only has to be ignored once.

This is my useZafClient hook so far:

import ZafDevClient from '../ZafDevClient/ZafDevClient';

// singleton storage variable within webpacked hook closure
let zafClient;

export const useZafClient = () => {
  if (!zafClient) {
    // eslint-disable-next-line no-undef
    zafClient = process.env.NODE_ENV === 'development' ? ZafDevClient : ZAFClient.init();
  }
  return zafClient;
};

So far I've figured out that by passing in the localhost URL and a guid, the `ZAFClient.init()` method will return true, but that doesn't really help me with figuring out how to polyfill or mock it for local testing.

This 'works' to get past the init failing.

http://localhost:4567/sidebar.html?app_guid=f278bc69-6098-aab88a5ec49f&origin=http://localhost:4567

Hello,

I'm trying to implement best practices with my ZAF sidebar app and bumping into some problems.

1. I'm using secrets that get injected by the ZAF Proxy
2. When compiling in dev mode for bug tracking my application is too big to upload to the Zendesk Sandbox to test
3. Uploading a compiled application for every minor change is an untenable development lifecycle
4. I need to be able to use Jest to run automated continuous integration testing on my app
5. Sinatra from Zendesk Apps Tools prompts for secrets but does not inject a working ZAFClient into local dev
6. ZCLI doesn't seem to have enough maturity to address these issues yet and is confusing to integrate into an app built using ZAT, React, Webpack and Zengarden.

I've left comments on the GitHub repositories also, I'm very happy to develop and implement something, but I'd like to understand how to get involved and contribute meaningfully.

The ideal outcome will provide the opportunity to mock a ZAFClient for local development, where I can mock the proxy using whatever code I need, taking full responsibility for the security of that on local dev.

WebPack would compile with the mock on dev/localhost, and a similar or different Mock using dummy data would apply to Jest testing. 

This will allow local development of the app, rather than 'guess testing' and trying to debug by beautifying compiled and minified code in the browser developer tools, which is clunky at best.

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

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.

Hi, I'm having similar issues, but nobody has responded to my post or tickets yet, and it has been over a week.

https://develop.zendesk.com/hc/en-us/community/posts/4408239110810-Secure-settings-not-all-being-injected-via-api-proxy?page=1#community_comment_4408242180890