Like many LTI tool providers, we are scrambling to address the errors caused by Safari blocking 3rd party cookies by default. I have taken a few different runs at this, but about 90% of the way through I realize I no longer have access to some vital piece of info.
In my latest attempt, I was hoping to catch launch validation failures and display a button prompting the user to repeat the launch in a new window. The flow of this process would look like this:
1. User clicks tool link in Canvas, generating a POST to the tool's OIDC login endpoint.
2. Tool redirects user back to the Canvas authorization endpoint (/api/lti/authorize_redirect).
3. Canvas redirects user to /api/lti/authorize.
4. Canvas generates a POST to the tool's launch endpoint, containing the authenticity_token, id_token and state.
5. Tool validates launch data, and on-failure a "launch in new window" button is displayed.
I have everything up to the last step dialed in, but that's where the process breaks down. Its easy enough to view the source of the form Canvas generates when the tool is configured to launch in a new window. But that form includes login_hint, client_id, and lti_message_hint all of which are (at best) encoded into the id_token param that was just rejected as being part of an invalid launch.
I guess what I am looking for is a Canvas endpoint that I can contact and say "generate a new window launch form for /courses/123/modules/items/456" and then I can display that info to the user. Does such a thing exist? Is there some other preferred way to address this cookie issue?
In case it matters, the only reason that our tool needs a cookie is because that is how the underlying IMS provided PHP component (https://github.com/IMSGlobal/lti-1-3-php-library) validates "state" passed between the TC and the TP. There is no native need for a cookie in our tool itself, its only required for validation.
