Can not initialize a Power-Up in chrome when third party cookies are blocked

Trello
1

Hi again its me :wave: ,

This time with another pondering question :blush:

I’m not able to run a trello powerup under chrome Version 84.0.4147.89 (also has been reported on Safari 13+)

I get the following exception:

Uncaught (in promise) DOMException: Failed to read the 'localStorage' property from 'Window': Access is denied for this document.
    at new Pn (https://p.trellocdn.com/power-up.min.js:1:126215)
    at Rn.init (https://p.trellocdn.com/power-up.min.js:1:127994)
    at Un.initialize (https://p.trellocdn.com/power-up.min.js:1:132217)
    at initTrello (webpack:///./src/index.js?:9:31)

From using the following code:

window.TrelloPowerUp.initialize(
  {
    
  },
  {
    appKey: '...',
    appName: '...',
  },
)

Here is full output log from my workstation:

2020-09-11_12-24
2020-09-11_12-241909×437 151 KB

As far as I understand the issue is connected to the fact that in Chrome/Mac the seemingly default for some users is ‘Block 3rd party cookies’ setting been ON and it does produce the above exception.

update: seems this is a bug in chrome (?) and others have experienced it too see Client throws exception on third disabled third party cookies and Chrome, when running in iFrame · Issue #138 · launchdarkly/js-client-sdk · GitHub

When changing that setting to ‘block 3rd party cookies in incognito’ it all works as expected.

Asking users to play with chrome settings is a way to mitigate the issue (still I doubt about its user friendliness :slight_smile: )

Do you have similar problems and do you know of any workaround to make trello powerup play nicely for those users having this setting (misaligned ?) ?

2

Yes, it appears that default Incognito settings in Chrome cause Power-Ups to fail to work as expected.

We’ll certainly explore what is within our power to handle this, but our general response to users reporting problems related to this is likely going to be something like, “Unfortunately, Power-Ups require that 3rd party cookies not be blocked. If you’d like Power-Ups to work as expected, please consider updating your browser’s settings accordingly.”

1 Like
3

That being said, this is only happening, as you mentioned, because you’re initializing with the appKey bit so that you can use the REST API helper.

We should fix this and fallback accordingly, but that work hasn’t been prioritized.

If you wanted to workaround this you could reimplement some of what the REST API helper does for you (ask user to authorize, store the token) and then fallback accordingly if localStorage is not available.

4

Hey there,

Another Boris chimes in on this :wink:

When I saw this REST API facility being introduced I was very excited and consequently very disappointed when I encountered the problem that was reported by original poster.

In fact, blocking the 3rd party cookies is the new reality of the web and it is here to stay.
Trello JWT is a great step towards not using cookies and we all should use that.

WRT to the REST API. In its current incarnation it is just not usable for anything, because it only works in extremely narrow and ever shrinking circumstances.

However, it does not have to be that way. It can be magnificently usable:

  • Trello does not need localStorage to store the token. It is possible to store it in a cookie on Trello domain encrypted using a the same keys Trello uses to sign JWT tokens and make all of it transparent for powerup developers.

  • Even if localStorage is enabled, the user would need to re-authorize on every browser. This looks strange to the user.

A facility to give REST API a token that A powerup had stored before would solve both problems.

Cheers,
Boris Kobilkovsky
Smart Fields powerup

5

Has anyone found a good way around this? As far as I am understanding, this means that the powerup REST API can’t be used if a user is running Chrome with default settings. Is that correct?