LTI XBlock and SameSite

Question for anyone using Django to serve LTI apps for courses, and thereby using the LTI xblock : have you seen the notice in Chrome about cookies and the SameSite header? If you have the Chrome dev console open when you load an page that contains an LTI xblock pulling in an external Django app you’ll see something like :

A cookie associated with a cross-site resource at was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at and .

If you’ve configured Django’s SESSION_COOKIE_SAMESITE = None, Django doesn’t write SameSite=None , it just doesn’t write anything at all. However, by the looks of this recent pull request in the Django repo, Django is being updated to explicitly write the “None” setting:

Just curious if anyone has thoughts on whether we can assume LTI applications served by Django (with this update) will continue running ok in iframes on or other Open edX-based sites.

Thanks for your thoughts.

– Daniel

Thanks for posting this @DanielMcQ !

Am also concerned about this issue for our clients that use Cross-domain CSRF cookies

I assume Django will backport this to 1.11 since it’s still supported? But we’ll need to upgrade the minor version at least, and get that into ironwood.

Oh… could this be the cause of my problem with LTI while testing Juniper?
And also why it does not work anymore on a recent single server instance of Ironwood I just installed?

I remember seeing your post @DanielMcQ a few weeks / months back. I have a lead to investigate further what is going on…

I found my problem. It wasn’t related to that. An ALB/ELB/AWS/SSL/NGINX combination was the culprit. Changes I made in our production systems and test systems but not on our single server systems using only the vanilla open-release/ironwood.master and open-release/juniper.alpha1.

@DanielMcQ I ran into this issue and posted here.

This SameSite cookie is effecting LTI Consumer content from rendering in an external LMSs (e.g. Canvas, Blackboard) from pulling in LTI content from our Open edX instance (LTI Provider). It throws an HTTP 403 response because the anonymous user is not authenticated because the csrftoken is not being sent in the HTTP request to

@DanielMcQ I seemed to get LTI Consumer through Canvas pulling content from our Open edX Provider by doing the following.

I haven’t received any error about not being logged into my edX account from Canvas and the SESSION_COOKIE_NAME doesn’t display the message since Secure=True and SameSite=None for that cookie.

The cookie didn’t specify a SameSite attribute when it was stored and defaulted to “SameSite=Lax” and broke the same rules specified in the SameSiteLax value. The cookie had to have been set with “SameSite=None” to enable third-party usage.

  1. Installed middleware to update SameSite=None for cookies set by Open edX platform. Following directions from the latest release here on how to install the middleware component.
    Install django-cookies-samesite:
pip install django-cookies-samesite

Add the middleware to the top of MIDDLEWARE_CLASSES:

  1. Updated /edx/app/edxapp/{cms,lms}.env.json files to include the following changes.
  1. Updated /edx/app/edxapp/edx-platform/lms/envs/ file to include the additional changes.
# Setup for django-cookies-samesite

The django-cookies-samesite middleware has a setting if you need to set specific cookies like so, however, I just forced all cookies to set SameSite=None with the force all setting.

SESSION_COOKIE_SAMESITE_KEYS = {'sessionid', 'hideCaptions', 'hide_captions'}

There are additionally places within the edx-platform repo where additional cookies are being set. A code update would need to include the following changes of the secure parameter for this SameSite change to work over LTI.

response.set_cookie( ... , secure=request.is_secure() )

This article kind of gives a better idea of what’s happening with the SameSite cookie change from Chrome and other browsers that are adopting this update.

cc: @jill

Thanks for posting this @Zachary_Trabookis!

I followed these steps on my Juniper sandbox which is an LTI provider. (Note: had to modify lms.envs.production to add the additional settings instead of lms.envs.private, since it’s not a devstack.)

EDIT Please disregard the notes below. These issues were resolved by creating a brand new session.

I didn’t use SESSION_COOKIE_SAMESITE_KEYS, just SESSION_COOKIE_SAMESITE_FORCE_ALL and thought that would be enough, but the sessionid cookie doesn’t get marked SameSite: None. All the others did though:

Name Secure SameSite
csrftoken None
edx-jwt-cookie-header-payload None
edx-jwt-cookie-signature None
edx-user-info None
edxloggedin None
experiments_is_enterprise None

However, when using LTI to access the provider sandbox, only one cookie was marked SameSite: None, and the rest were not. LTI is using OAuth to authenticate, so maybe there’s something different there with how cookies get created?

Name Secure SameSite

CC @DanielMcQ @sambapete

I haven’t dug into the code to see why the this might be.

EDIT Replacing SESSION_COOKIE_SAMESITE_FORCE_ALL with this setting didn’t make a difference to the sessionid or csrftoken cookies:

SESSION_COOKIE_SAMESITE_KEYS = ['JSESSIONID', 'csrftoken', 'edx-jwt-cookie-header-payload', 'edx-jwt-cookie-signature', 'edx-user-info', 'edxloggedin', 'experiments_is_enterprise', 'sessionid']

@jill We’re using anonymous authentication with LTI Provider. I couldn’t figure out edX authentication with LTI. I added the middleware at the end of the list then moved it to the beginning. Restarted edX services and then it started working from Canvas.

We’re also not using Site Configuration to set the SESSION_COOKIE_NAME but default configuration.

This is where the session cookie gets updated by site configuration.

@jill Do you think the cookies get set everytime you make an LTI provider request? Wonder if you should try a private browser or clear cookies for your Juniper Open EdX site before making another request.

Good call @Zachary_Trabookis, that fixed it. Will update my previous post to reflect this.

1 Like

@jill @DanielMcQ Here is a fix for LTI Provider calls for the SameSite cookie issue for the Hawthorn. I’m sure this could be applied similarly for releases after this release.

Let me know if you see anything wrong.

1 Like

Thanks for that @Zachary_Trabookis! I cherry-picked your commit into my PR, and fixed a couple of places that are different in master.

See edx-platform#23671 – there’s a sandbox linked there so anyone is welcome to try it out.

1 Like

FYI @DanielMcQ @Zachary_Trabookis edX have merged our PR to master, so this fix will be available in Juniper: edx-platform#23671. :tada:!

@DanielMcQ if this resolves the issue you raised, could you mark this post Solved?

1 Like

@jill @Zachary_Trabookis you guys are amazing. My issue was more generic, as I experienced the issue within a simple Django site I created to act as an LTI provider of content to an Open edX LTI consumer… but I think I can use the same fix you came up with for my situation. So I’ll mark as solved!!


@jill @DanielMcQ Thanks for helping me and everyone else in the community benefit from this update.

@jill @DanielMcQ I noticed that recently when I stood up another devstack_docker environment (e.g. master or open-release/juniper.master) while using Chrome that I’m not able to get past the http://localhost:18000/login screen without commenting out this django_cookies_samesite.middleware.CookiesSameSite and reloading the LMS. I think it’s because Chrome is blocking these cookies below (see graphic too). When I remove the middleware it works just fine for devstack_docker.

Blocked EdX Cookies
Getting this error message with following cookies:

  • csrftoken
  • enterprise_customer_uuid
  • sessionid
  • experiments_is_enterprise

The error message says:

This Set-Cookie was blocked because it had the “SameSite=None” attribute but did not have the “Secure” attribute, which is required in order to use “SameSite=None”.

Here are two options that we could use with devstack_docker to continue to allow login from the http://localhost:18000/login page.

  1. We could remove this middleware in devstack_docker.
  2. So it appears that when were not on a secure site (e.g. devstack_docker, localhost) then we need to set this SameSite cookies to something other than SameSite=None since that requires a secure connection. My recommendation is to set it to Lax since after reading over this post it appears to be the default that browsers go to and is more open to sending the EdX cookies in a request from a third-party site. Anyway let me know what you think. When I set this value it seems to let me login on devstack_docker. I couldn’t login after provisioning a new devstack_docker environment and I remember that we added this recently.
    # ./edx-platform/lms/env/
    # django-session-cookie middleware

1 Like

@jill @DanielMcQ Committed these updates to make devstack_docker LMS login work again since SameSite=Lax cookie attribute works without having secure site.

Fixes for several releases waiting to be merged.




@jill @DanielMcQ Committed these updates to make production LMS login work again since SameSite=Lax cookie attribute works without having secure site. I was getting the following error.

==> /edx/var/log/supervisor/lms-stderr.log <==
[2020-09-24 18:44:19 +0000] [29859] [INFO] POST /user_api/v1/account/login_session/
2020-09-24 18:44:19,956 WARNING 29859 [] [user None] - Forbidden 
(CSRF cookie not set.): /user_api/v1/account/login_session/

Fixes for several releases waiting to be merged. This is for the edx/configuration repo. I noticed this error when I deployed this to a AWS staging environment and couldn’t login to the LMS or CMS.