302 on Article Attachments w/ SSO


  • Bryan - Community Manager
    Comment actions Permalink

    Hi C. Taf. This seems unusual. First off, apologies if I missed something here; these are my observations...

    An article's attachment and the authentication needed should be paired with getting its article. IOW, if you get a redirect on an attachment, you should get a redirect on the article itself. Both of which indicate there is no session cookie/authentication information available in the browser that matches the needed credentials and thus redirects you to the login page. Do you happen to be caching URL information and accessing it later? Where the authentication may not be what's expected?

    A few additional points:

    • For typical API calls (say done via AJAX), the prefix should be your_subdomain.zendesk.com (not your custom domain)
    • Redirects are typical of browser API calls. iirc in your other post, you mention using an API token to call these APIs on a backend service, so I'm not clear on this point 
    • If you're populating a custom web page with links picked up from a backend service that's harvesting restricted help center information, this is not supported. Links to restricted assets require either a session cookie for the asset's Zendesk account instance (created when you login) or an API call with an expected Authorization header (OAuth for Help Center calls — I recall you mentioning that wasn't a possibility, however)

    Because this involves a custom solution (versus accessing HC content via a standard HC theme) and data specific to your account, please contact Zendesk Customer Support and plan on Granting Zendesk temporary access to your account. I think this will be the best next step.

  • C. Taf
    Comment actions Permalink

    Thanks for your response Bryan. However, I don't believe we're doing anything particularly unusual, and based off of other discussions, this seems to be a common issue for other API users.

    To start by better describing our use case:

    We are using a server (and API key) to make use of the search API end-point. From within our broader app, users can click a help button, search for content, and receive results in app rather than separately logging into Zendesk and being divorced from the core context. 

    As part of the response from the search API (which is functioning with no issues), we receive a number of responses, inclusive of the article body. We are rendering the article body directly within a modal within the app, and on the whole this is a seamless experience for the end-user. 

    However, the issue that my original post describes is that images within the body (ie article attachments in zendesk parlance) are broken as the img src points to the domain-mapped url. 

    I have tried every conceivable alternative for fetching the images that are present in the body tags, however, under any scenario, the img src are simply unable to retrieve the content unless the user has a valid cookie. 

    It would seem to me that the images in the body of an article (or search) response need to point at the content_url of an attachment rather than the simple url. Again this issue seems to be fairly widespread for anyone relying on the articles and/or search endpoint with 'Require sign-in' and an SSO implementation. Any thoughts welcome.

  • Bryan - Community Manager
    Comment actions Permalink

    I appreciate the use case details C. — I can only say this is not a supported use case. Help Center was originally designed and optimized for Zendesk's Help Center/Guide product.

    Content is restricted in the context it's being accessed. Because articles are text based, that text information can be gathered with the elevated server-side credentials and then pushed out as text. Image URLs, however, maintain their authorization context when accessed.

    If you did the same thing with images as article text, you could gather the image on the server side, store it in an accessible location relative to the client side, then access that location from the client side. That's the only workaround that I can think of here. Much of this behavior revolves around restricted content and security — if the content is restricted in Help Center, it has to be restricted no matter where the API to get it is called from.

    I'm definitely open to hearing from others on how they may have solved similar needs.


Please sign in to leave a comment.

Powered by Zendesk