blocked 3rd party cookies
I use Kaltura to record lectures and post them to my course at the U of Utah on Canvas. This semester, Firefox will not allow me to open "my media" where the Kaltura recordings are posted on Canvas. I get the following message: It seems your browser is blocking 3rd party session cookies which are required for the Kaltura application. To resolve this issue, please update your settings to allow 3rd party cookies.
I copied the Kaltura web address 670542.kaf.kaltura.com that I can see in Chrome and pasted it into a Chrome browser and it goes to my recordings in Canvas when I use Chrome. The same site doesn't work in Firefox. How do I unblock Kaltura third party sessions? Thank you.
Bob McKnight U of Utah Instructor
Ŋuɖoɖo si wotia
I followed every instruction for enabling 3rd party instructions about 5 dozen times (only a slight exaggeration) and despite 3rd party cookies being enabled or having NOTHING blocked Kaltura still wouldn't load on my school's canvas interface.
Going to about:config and changing network.cookie.sameSite.laxByDefault (a setting mentioned by jscher2000 above, though his suggestion to try to figure out the hosts is seemingly impossible) to false fixed the issue.
I don't know what is going on behind the scenes but none of the recommendations literally anywhere about enabling 3rd party cookies or turning off enhanced tracking protection fixed it. It's apparently a deeper issue than that if we're having to go into about:config to fix it.
This is going to cause a lot of students and professors an immense amount of frustration. I know it caused me at least an hour of torture.
Xle ŋuɖoɖo sia le goya me 👍 3All Replies (8)
Hi, Jefferson Scher- I am late to the conversation, but I can confirm, I just tried this "back door" workaround and it resolved an issue with an older system we are using for procurement where I work. Thank you so much!
However, I recall that we were hit with the same issue with the Chrome release 80 and above released in Feb 2020. There was a very similar "back door" fix that was supported until August of 2021 and it is no longer available. Our organization heavily weighed whether or not to recommend the back door fix and we chose to not do it, specifically for the reason the moderators cited above: "The moderators would like us to remind you that changes made through this back door aren't fully supported and aren't guaranteed to continue working in the future." The Chrome back door workaround is no longer available, and for the product we are using we have been recommending our campus use Firefox instead! Now, Firefox has the same issue!
Please, if you have any influence with Mozilla at all, please try to get them to provide a long-term, supported workaround. Many universities such as ours are using older systems that cannot keep up with all of the browser technology changes and requirements. For example, EDGE has the ability to run in Internet Explorer Mode, which is helpful since IE seems to be the only browser that works with our product consistently any more, and IE it is no longer supported by Microsoft. We don't know how much longer EDGE will support running in IE mode, but at least we have an option at the moment.
We understand the browser providers are trying to implement best practices for security. However, our 3rd party procurement provider assured us that the product already has security built in to prevent any issues with cross-site cookie handling that this browser "fix" in Firefox 96.0.1 is supposed to address. From our perspective, it didn't fix anything, rather, it broke our ability to use Firefox as a browser with our procurement system. We are already getting many reports from our campus users who are having trouble using Firefox now.
We really hope Firefox works with us better than Chrome, which basically did nothing to help us mitigate the issue.
Hi Morriv, which workaround did you try?
(A) Revert the SameSite behavior to Firefox 95 behavior by setting network.cookie.sameSite.laxByDefault to false
(B) Exempt one or more specific servers by adding the server host name(s) to network.cookie.sameSite.laxByDefault.disabledHosts
If you only tried (A) so far, I hope you could take 10 minutes to try (B).
Here is the scenario as I understand it.
The problem typically arises when a form (like a login form or sometimes a hidden form) is submitted from site1 to site2. Firefox 96 no longer sends site2 its cookies with this cross-site POST because they are not marked with "SameSite=None; Secure". So site2 does not provide the expected services.
If that sounds like what is happening, could you try this:
(1) In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button accepting the risk.
More info on about:config: Configuration Editor for Firefox. The moderators would like us to remind you that changes made through this back door aren't fully supported and aren't guaranteed to continue working in the future.
(2) In the search box in the page, type or paste laxByDefault and pause while the list is filtered
Firefox should display a general policy and a preference to store exceptions:
- network.cookie.sameSite.laxByDefault
- network.cookie.sameSite.laxByDefault.disabledHosts
(3) Reset the network.cookie.sameSite.laxByDefault preference to true by either double-clicking it or clicking the Reset button at the right end of the row
(4) Double-click the network.cookie.sameSite.laxByDefault.disabledHosts preference to display an editing field, and enter the host name of the "receiving" server (site2 in the above example). Then press Enter or click the blue check mark button to save the change.
As an example, let's say the address of the site2 server is https://www.example.org/somefolder/somepage.html.
In the preference, enter example.org as your host that is exempt from the policy. (If there already is a host name listed in this preference, separate them with a comma.)
Any improvement on the next visit?
EDITED TO ADD MORE INFORMATON: Sorry! I missed the recommendation to try to specify the server for site 2. Unfortunately, we are using Ariba PunchOut Catalogs and we have about 65 of them. It sounds as if we would need to add all 65. I could try with one to see how that works. I will do that and get back to you.
Orginally, here are the steps I used: Here is how to roll back the "lax by default" change to how it worked in Firefox 95: (A) In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button accepting the risk.
More info on about:config: Configuration Editor for Firefox. The moderators would like us to remind you that changes made through this back door aren't fully supported and aren't guaranteed to continue working in the future.
(B) In the search box in the page, type or paste laxByDefault and pause while the list is filtered
Firefox should list two matching preferences:
network.cookie.sameSite.laxByDefault network.cookie.sameSite.laxByDefault.disabledHosts (C) Double-click the network.cookie.sameSite.laxByDefault preference to switch the value from true to false
morriv trɔe
morriv said
EDITED TO ADD MORE INFORMATON: Sorry! I missed the recommendation to try to specify the server for site 2. Unfortunately, we are using Ariba PunchOut Catalogs and we have about 65 of them. It sounds as if we would need to add all 65. I could try with one to see how that works. I will do that and get back to you.
Are they all on a common domain, for example, site1.example.com, site2.example.com, site3.example.com? In that case, an exception for example.com might cover all of them. But if they are all different domains, I guess it wouldn't be very practical.
Hi, Jefferson- I am having no luck trying to specify the server names. I am probably not using the correct format. I tried using what I thought is the URL for the punchout sites. Then I tried using what I thought is our host name for the application from which we are trying to punch out and I am still encountering a Token Expired error when I try to pull items from the supplier shopping cart back into the local application. Sorry!
morriv trɔe
I am still having no luck with either fix. I tried setting network.cookie.sameSite.laxByDefault to false. Same error.
I reset that to true. I have now tried setting network.cookie.sameSite.laxByDefault.disabledHosts with the following hosts: psu.instructure.com, psu.mediaspace.kaltura.com, instructure.com, kaltura.com
I'm not sure if these are the correct hosts, but seemed reasonable to try. No dice, same error.
I really don't want to change my default browser, but right now my workaround is to open Edge anytime I need to do anything involving Kaltura & Canvas.
debbiegaydos said
I am still having no luck with either fix. I tried setting network.cookie.sameSite.laxByDefault to false. Same error.
Sorry to hear about this problem. That really should work if the problem is caused by that change. Please keep it set to false for further testing.
Any difference if you test in a private window (Windows: Ctrl+Shift+P, Mac: Command+Shift+P)?
jscher2000 said
Sorry to hear about this problem. That really should work if the problem is caused by that change. Please keep it set to false for further testing. Any difference if you test in a private window (Windows: Ctrl+Shift+P, Mac: Command+Shift+P)?
OH MY GOD..... this did the trick!! I opened private window and set laxByDefault to false, and BAM it worked. I went back to my original window and refreshed, and it worked there too. I completely closed and re-opened Firefox and went back in to Canvas and it still worked! THANK YOU!! I don't understand WHY that fixed the issue vs. doing the same thing in a non-private window, but I'm so happy to have this resolved. This still feels like a work-around and not a real "fix", but I'm just happy to have it resolved for now.
Did I mention.... THANK YOU!