Sending deep linking request to Canvas in the "Assignment Selection" placement redirects to login page

[ChrisVouga]

Background:

I'm developing a LTI 1.3 app. I'm doing testing in a local instance of Canvas thats running with docker (http://canvas.docker/).

Expected Behavior:

When sending deep linking response back to canvas it succeeds. The "working in submission type placement - low.mov" attachment shows the expected behavior but it's the app running inside of the "Submission Type Selection" placement and not the desired "Assignment Selection" placement.

Actual Behavior:

Sending deep linking response back to redirects to login page. See attached videos "quiz maker low.mov" and "orchard - low.mov".  I tried with two different apps but get the same result.

Theory:

I suspect there are some settings I need to enable in the admin settings. See "assignment placement settings.png". These settings might be relevant? IDK

Data:

Here are some of values associated with the deep linking request & response.

Use https://jwt.io/ to decode the "data" and "JWT" fields.

Request

• Method
  • POST
• URL (Deep Linking Return URL)
  • http://canvas.docker/courses/1/deep_linking_response

• Query String Parameters
  • "data"
    • eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJub25jZSI6IjMyMTQ5NDAyLWJjY2QtNDdiMC05MTVjLTIwNTU3Y2EzYzZmYSIsIm1vZGFsIjp0cnVlLCJwbGFjZW1lbnQiOiJhc3NpZ25tZW50X3NlbGVjdGlvbiJ9.XAr2lUDLCNvMl5YajjKcuTEWhDZ22J6wzwXro3obfrI
• Form Data Body
  • "JWT"
    • eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Imx0aV8xXzNfcHVibGljX2tleSJ9.eyJodHRwczpcL1wvcHVybC5pbXNnbG9iYWwub3JnXC9zcGVjXC9sdGktZGxcL2NsYWltXC9kYXRhIjpudWxsLCJodHRwczpcL1wvcHVybC5pbXNnbG9iYWwub3JnXC9zcGVjXC9sdGktZGxcL2NsYWltXC9tc2ciOiIxIGl0ZW0ocykgcHJvdmlkZWQiLCJodHRwczpcL1wvcHVybC5pbXNnbG9iYWwub3JnXC9zcGVjXC9sdGktZGxcL2NsYWltXC9sb2ciOiIxIGl0ZW0ocykgcHJvdmlkZWQiLCJodHRwczpcL1wvcHVybC5pbXNnbG9iYWwub3JnXC9zcGVjXC9sdGktZGxcL2NsYWltXC9jb250ZW50X2l0ZW1zIjpbeyJ1cmwiOiJodHRwczpcL1wvb3JjaGFyZC5uZ3Jvay5pb1wvbHRpXC92MXAzXC9jb250ZW50XC9sYXVuY2giLCJjdXN0b20iOnsiZW50aXR5X3R5cGUiOiJub2RlIiwiZW50aXR5X2lkIjoiNTU0In0sInR5cGUiOiJsdGlSZXNvdXJjZUxpbmsifV0sImlzcyI6IjEwMDAwMDAwMDAwMDA1IiwiYXVkIjoiaHR0cHM6XC9cL2NhbnZhcy5pbnN0cnVjdHVyZS5jb20iLCJodHRwczpcL1wvcHVybC5pbXNnbG9iYWwub3JnXC9zcGVjXC9sdGlcL2NsYWltXC92ZXJzaW9uIjoiMS4zLjAiLCJodHRwczpcL1wvcHVybC5pbXNnbG9iYWwub3JnXC9zcGVjXC9sdGlcL2NsYWltXC9tZXNzYWdlX3R5cGUiOiJMdGlEZWVwTGlua2luZ1Jlc3BvbnNlIiwiaHR0cHM6XC9cL3B1cmwuaW1zZ2xvYmFsLm9yZ1wvc3BlY1wvbHRpXC9jbGFpbVwvZGVwbG95bWVudF9pZCI6IjI1OmI4MjIyOWM2ZTEwYmNiODdiZWIxZjFiMjg3ZmFlZTU2MGRkYzMxMDkiLCJub25jZSI6ImUzY2IzNmQ5LTcyZTctNDk1My1hNmRiLTZhN2ZmYWE3NmFhZSIsImp0aSI6ImFjZDA4MDcxLTA1MjAtNGYwMi04YzRiLTRhN2FjZGQ5MjdjZiIsImlhdCI6MTY3NjU5NTU3OSwibmJmIjoxNjc2NTk1NTc5LCJleHAiOjE2NzY1OTYxNzl9.XoGlc2KL-NmyyMVVpDaOAimDu-S-Qkh9_XBCY_MpJ-SwEJWIF9B0DMYGyRa4UK4_HhCeCfQGnrSOPX947hQWboGYs3pH4Z4aYJC6f_5zacLP2LkVi44c04geYdnLLDX2seFqQneCHLJDfjbt-E43-WhYE3ZNVW1GPaBIJ_UO_Yg

Response

• Status Code
  • 302 Found (this is expected to be 200)
• Initiator (it's a tab in Chrome Dev Tools. It shows that the request redirects to the login page)
  • Request Initiator Chain
  • http://canvas.docker/courses/1/deep_linking_response
    • http://canvas.docker/login
      • http://canvas.docker/login/canvas

[ChrisVouga · Accepted solution]

Yes I did. My solution is to launch the tool from a canvas instance that is being served over https and not http.

My theory is that the problem was caused by the browser blocking Canvas's cookies because it's being served over http and the cookies weren't configured for http.

We have a canvas instance served at https://canvas-dev.asu.edu. When I launch it there I don't have any problems. I only get this problem in my local instance which is served at http://canvas.docker.

The attached video shows our tool working. The only thing different is that it's being launched from https://canvas-dev.asu.edu and not http://canvas.docker.  http://canvas.docker was the url used in videos attached in the problem post.

[116086425434479]

Did you happen to make any progress on this? I'm running into the same problem. The only thing I've been able to try is adding data from the query params into the jwt payload message as https://purl.imsglobal.org/spec/lti-dl/claim/data' but that made no difference. I've also tried playing around with the aud/iss to see if there was some issue there, but changing those for me will return an actual error response. I've verified the jwks route I'm using is accessible and using tls so not sure where to go from here.

[ChrisVouga · Accepted solution]

Yes I did. My solution is to launch the tool from a canvas instance that is being served over https and not http.

My theory is that the problem was caused by the browser blocking Canvas's cookies because it's being served over http and the cookies weren't configured for http.

We have a canvas instance served at https://canvas-dev.asu.edu. When I launch it there I don't have any problems. I only get this problem in my local instance which is served at http://canvas.docker.

The attached video shows our tool working. The only thing different is that it's being launched from https://canvas-dev.asu.edu and not http://canvas.docker.  http://canvas.docker was the url used in videos attached in the problem post.

[116086425434479]

I tried manually editing the cookies while the modal was open and it worked if I edit the cookie values to be secure and set SameSite=None before selecting the resource.

[100097381603302 · Accepted solution]

For anyone got problem like me. It is because my config doesn't have `config/session_store.yml` file.

Just run 

` cp config/session_store.example.yml config/session_store.yml `

then uncomment secure