Tim Hurd

Caroline Kello I haven't seen any updates from you or your team about that process of providing a workaround for posting to the endpoint through a form you suggested. Is that something you guys are going to do or not? I am sure a lot of the devs following this thread would be very interested in that solution you proposed to me.

Thanks for following up.

HI Caroline,

I am glad you got on the thread and are attempting to provide some solutions. I think there are two lines of thinking here in this thread since the deprecation announcement of the GET method process. I just want to make sure you are aware of it.

There is the one group asking about your run of the mill JWT generation and posting. Your updates appear to address that group. Which is fine.

However there is another group of us who know the process of generating JWT and have systems working fine with it. What we are interested in exploring is an alternate solution to having to submit a POST through some form via JavaScript. (Which the examples you have shown in a previous post suggest). 

Right now our servers authenticate the user and then once passed, have the user redirect via a 301 redirect GET response (or similar) to have the user's browser redirect back to Zendesk. Having to redirect the user to some page with a form on it, embed the JWT data and then submit via JS is just cumbersome. I hope you and your team are exploring alternative solutions to having to do this. I am not sure why we have to host a page just to implement this redirect method and why introduce JS into something that probably doesn't need to be in the flow to begin with.

I know you guys want to achieve keeping the value out of logs and browser history, but we can also set the expiry time on a token to be short (which is good practice) so even if seen, they shouldn't be valid unless used within the expiry time window.

I think many of us are just not sure why the added complexity.

Marco, you are not wrong. 

What I can see from the examples on github is that they expect us to redirect to some page we create with a form that will then issue a POST request through an automated JavaScript submit. As far as I know this is a bit of a hack.

Javier DM  May I suggest you visit with your devs and talk to them about redirects through the HTTP status 307 and have them update the documents to talk about this. I think this might be a cleaner solution than using a form. However, the one drawback to this of course is that I think most browsers will pop up a dialog to confirm that they wish to resubmit their post to the new URL (I haven't confirmed this). Logging in this way could be a pain seeing the dialog every time. 

Just to let you know, I am not a huge fan of this change and I think the hacky solution of needing a form submitted through JavaScript is not very good in my opinion.