The resource doesn't exist with signed=true location

Answered

6 Comments

  • Bryan Flynn
    Comment actions Permalink

    Hello Taylor,

    Because you have a "server side" app, it's your own server (a test server in this case) that returns the displayed assets. You'll want to check how your server is responding to the POST call that the Zendesk Apps framework makes to your server. My guess is that your server is not handling the POST call correctly. When "signed:false" or signed:true is deleted, a GET is made. With signed:true, a POST call is made.

    Also check out this article for more details: Securing your Zendesk App Framework (ZAF) App

    Hope this helps!

    0
  • Dan Clark
    Comment actions Permalink

    Hi Bryan - I'm seeing the same issue here.

    The below seems to disregard the signed setting and just perform a GET request like it's not there

    "ticket_sidebar": { "signed": true, "url": "http://127.0.0.1:8000/" }


    The below returns 'resource does not exist' and I can't see a POST to my location URL in dev tools

      "signedUrls": true,
    "location": {
    "support": {
    "ticket_sidebar": "http://127.0.0.1:8000/"
    }
    },

    Note I have the manifest.json location URL pointing at my localhost at the moment as I'm developing.

    If I POST to my location URL in postman, I get the response I'm expecting i.e. not 'resource does not exist'

    Same issue using another URL which I know is fine to post to - https://jsonplaceholder.typicode.com/posts

    I do see a GET request to the below URL with returns a 404 only when signedUrls is present and true

    https://<domain>.zendesk.com/apps/installations/0/iframe_redirect?location=ticket_sidebar&product=support&origin=<domain>.zendesk.com&app_guid=<guid> 


    Any ideas?

    Thanks,
    Dan

    0
  • Dan Clark
    Comment actions Permalink

    UPDATE - I packaged and installed the app and now it works. Therefore, it appears that this functionality doesn't work when zat=true, which is going to make developing quite difficult!

    Anything I'm missing here?

    Thanks,

    Dan

    0
  • Bryan Flynn
    Comment actions Permalink

    Thanks for that additional information Taylor.

    Yes, the app needs to be uploaded. Since part of the signedURL feature is that a public/private encryption key is created and installed with the app and stored securely on Zendesk servers. This encryption key is used to sign the JWT that is passed to your remote server.

    This signedURL demo gives an example of the steps: https://gist.github.com/bryan-flynn-zd/d22d96c4a43fe717b9cba236dfcbe225#file-steps_demo_signed_urls-md

    Keep in mind, however, that a signedURL app is simply a manifest file. All the code that's being served to the client's browser is coming from the remote server specified in the manifest. The app itself doesn't have any code directly associated with it (this is true with all "server side" apps, unlike "client side" apps which maintain their own HTML/CSS/JS assets). This means once it's installed, you don't have to change it again. You only have to modify the code that the remote server specified in the manifest returns (IOW, that code is outside of Zendesk's scope and doesn't require 'zat server' to be served up).

    1
  • Dan Clark
    Comment actions Permalink

    Hi Bryan,

    Thanks for the explanation - I understand that what's coming through to the iframe for a server side app will entirely depend on the code on the remote server (as if it were an entirely separate site, which it is). The difficulty I referred to was in implementing the JWT auth as it's impossible to test the code on my remote site works (in terms of what it's doing with the JWT it gets from Zendesk) without deploying it / setting it live - not an ideal flow. As you mentioned, once that side of things is covered then it's simple to test changes locally.

    I hope the above makes sense. It's something I'll probably be able to work around if needed, but having some equivalent functionality when developing the site locally (or even just a more helpful error message!) would be very useful.

    Thanks,

    Dan

    0
  • Bryan Flynn
    Comment actions Permalink

    Agreed -- having a more sophisticated develop->test->deploy workflow would be a good thing. Right now, people work around these limitations in a few different ways:

    - Creating a test/trial account and using that as a temporary workaround. This isn't great, however, as the trial account expires fairly soon.

    - If on the Enterprise plan (or have the add-on), creating a sandbox test instance and using that for testing purposes -- see https://support.zendesk.com/hc/en-us/articles/360002112828-Testing-changes-with-the-Premium-Sandbox-Enterprise-add-on-

    - If a more permanent test instance is needed outside of the production instance or sandbox instance, a "sponsored" developer/test account can be requested here: https://developer.zendesk.com/apps/docs/publish/sponsored_account

    This last option, while possibly better long term, can require a number of weeks for the request to be processed (i.e. anyone who has urgent needs should consider other options).

    Anyway, thank you for the clarifications and details Dan. Best of luck on your effort!

    0

Post is closed for comments.

Powered by Zendesk