Programatically establish a user session
HI all,
I'm a bit stumped on this one. My goal is to use the help centre articles api to display an article inline/embedded in our existing web site and I'm very close to having this working. What I have so far is:
- jwt SSO setup and working.
- secure GET of a specific article using OAUTH2 tokens
- displaying the body of the article on our site
The only thing I'm struggling with is display of images. IF the user has already signed into zendesk, it works fine. If they have not, then I'm getting a 404 back when requesting the image. No problem, I thought, it'll be because I'm missing some cookies. So I ensured our web app and our zendesk were running on the same domain and then I programictially called POST `[zendesk]/access/jwt`, intercepted the response headers, extracted the value of `_zendesk_shared_session` and set it on our app via a response from our auth service. The cookie is now being sent along with the request for the image.......still 404.
I believe the reason for this is that POST `[zendesk]/access/jwt`, whilst responding with the session cookie I need is NOT establishing a server side session - as proven by calling `[zendesk]/api/v2/sessions` - which does not list anything with my programatic method, but does if I log in manually. I am assuming that after zendesk processes the request to POST `[Zendesk]access/jwt` another redirect is performed which then DOES establish the server side session.
So, my question: is there anyway I can mimic the manual auth flow in order to create the server side session that then corresponds to the session identified by the `_zendesk_shared_session` cookie.
Or is there another approach for me to seamlessly (not require the user to login twice, even if with the same credentials), that will allow me to display an image hosted on my zendesk help centre within/embedded in my web app?
Any help would be much appreciated!
-
Hey Sam,
I think you're spot on for what the issue is. Would you be able to try calling the '/api/v2/users/me' endpoint after completing the jwt process? Can you confirm that it's not showing 'anonomyous'? I just want to rule out any JWT issues. In the meantime I will be doing some testing to figure out what the best method to accomplish this is.
Thanks for your patience!
-
HI Eric Nelson, many thanks for getting back to me. I can confirm that the response frm '/api/v2/users/me' is not showing as 'anonomyous', the response I get is:
{
"user": {
"id": <REDACTED>,
"url": "<REDACTED>/api/v2/users/392459029837.json",
"name": "Sam Shiles",
"email": "sam@<REDACTED>",
"created_at": "2022-02-17T21:55:21Z",
"updated_at": "2022-05-18T07:22:48Z",
"time_zone": "Europe/London",
"iana_time_zone": "Europe/London",
"phone": null,
"shared_phone_number": null,
"photo": null,
"locale_id": 1,
"locale": "en-US",
"organization_id": <REDACTED>,
"role": "admin",
"verified": true,
"authenticity_token": "<REDACTED>",
"external_id": null,
"tags": [],
"alias": null,
"active": true,
"shared": false,
"shared_agent": false,
"last_login_at": "2022-05-18T07:22:48Z",
"two_factor_auth_enabled": null,
"signature": null,
"details": null,
"notes": null,
"role_type": 4,
"custom_role_id": 4434476582801,
"moderator": true,
"ticket_restriction": null,
"only_private_comments": false,
"restricted_agent": false,
"suspended": false,
"default_group_id": 4434476625553,
"report_csv": true,
"user_fields": {}
}
} -
Hey Sam,
Mind if I pull this into a ticket so you can share some code snippets?
Thanks!
-
Sure thing!
-
Thanks Sam! I've created a ticket on your behalf. Look forward to working with you via that.
-
Although ours was a completely different use case, we were also stuck at the same point - needing to automatically log in a user to Zendesk and grab their “_zendesk_shared_session” cookie.
We wanted to track changes to ticket subject lines if the subjects were changed by the end-user via email. Zendesk only makes original emails retrievable from the interface (via “Show original” button) so we couldn’t utilize any API calls to get this information.
We managed to retrieve the original emails programmatically (using Make/Integromat) by sending a GET request to the URL of the “Show original” button.
https://cdn.creativeautomation.io/ss/2022/20221015090628865_1613x978.png
While this worked fine with an active cookie, we needed a way to update the cookie automatically instead of manually retrieving it from our browsers every few days.
Long story short - Apify was able to solve this problem for us by creating an actor that does the following:
- Access the “SSO bypass” form and trigger sending an email with an access token
URL: https://{subdomain}.zendesk.com/access/sso_bypass
https://cdn.creativeautomation.io/ss/2022/20221015092012292_624x408.png
The actor only needed the following input to run:
https://cdn.creativeautomation.io/ss/2022/20221015091853095_727x298.png
- Use the access link from the email to log in to Zendesk and get the cookie
https://cdn.creativeautomation.io/ss/2022/20221015091756043_1025x272.png
To fully automate this workflow, we used Make to run the Apify actor, as well as retrieve and parse the received access tokens and cookies. Final result:
https://cdn.creativeautomation.io/ss/2022/20221015092859576_1916x261.png
Hope this helps!
Iniciar sesión para dejar un comentario.
6 Comentarios