Cloud apps can’t access cookies in latest Safari versions using the default browser settings. All third-party apps based on iframes should be affected.
Any ideas on how to work around it?
4 Likes
Hi @nnmatveev - can you provide your Safari version? Also, when you say default browser settings, can you provide more details about the security/privacy settings you’re testing with? Lastly, if you’ve taken time to do some debugging, did you find any noticeable changes in how the cookies are being set by Confluence that are causing this problem? Or… do you believe it’s related to latest Safari default settings?
1 Like
Hi @nnmatveev, this has always been an issue with regard to Safari in iframes. The cookie JavaScript API is your best bet for app iframes.
2 Likes
My Safari version is 11.0.3 (which is quite outdated).
The following browser option (if enabled) affects cookie access for iframes hosted on third-party domains
You can find it in ‘Safari’ → ‘Preferences’ → ‘Privacy’.
Using AP.cookie (suggested by @dmorrow) could partially solve the issue.
@dmorrow We investigated AP.cookie features but unfortunately it is not looking as a feasible solution for us. It is backed by a single cookie for all apps so it could be easily overflowed (a cookie max size should be considered equal to 4093 bytes). The max numbers of cookie is limited by 50 per a domain so we understand the reason why you are sharing a single cookie between all third-party apps.
Could you consider to add something like AP.localStorage? Using it should resolve all mentioned issues.
Hi @nnmatveev can you explain what you’re trying to store? Ideally you’ll only be storing identifiers in the users browser which you can use to access the full record from your server or from the product REST API’s.
Local storage is a possibility now we only support IE11+ but suffers from a similar problem to AP.cookie as all local storage and all cookies will be limited to the domain of the product hosting the add-on.
If the data isn’t user specific for macros, you have macro parameters and macro body for pages you have
content properties: https://developer.atlassian.com/cloud/confluence/rest/#api-content-id-property-post
2 Likes
Local storage is not something you can rely on either. It can also be unavailable based on browser settings.
1 Like
@Maarten Yes, this is why we requested to have something like AP.localStorage and store all the data on Atlassian cloud instance host. We assume that cookies & local storage are always enabled for Atlassian cloud instance host because otherwise a customer can’t use Jira/Confluence itself.
@cwhittington We need to store user public/private key pair and it is quite a space consuming data (both keys together are about 512 bytes). 512 bytes is 1/8 of the total cookie value size and we afraid to consider it as a long-term solution. Our app has a stateless backend and we can only store user data in cookie/local storage or Confluence instance. It is a user-specific private data so the only option for us is to store them via cookie/local storage because Confluence doesn’t provide access to user properties via REST API.
AP.localStorage is also better storage option then User Properties REST API because of access speed.
I hope those public/private key pairs can be regenerated or users can have multiple sets at one time without consequences?
As @Maarten mentioned localStorage also has no guarantee of storage either. However, one could argue that because the max size is larger there is a higher chance of successful storage. If we were to implement local storage we would have to work with the product teams to portion off a certain amount of space for connect add-ons and then give each connect add-on a subset of that space.
Thinking out loud:
Firefox’s limit is 5MB per origin. I assume we could get 500KB of that. We can also assume around 50 connect add-ons being installed per origin (this number needs to be on the high side). This gives you roughly 10KB per add-on which meets your requirements and is about double the max cookie size.
I have updated the existing ticket here: https://ecosystem.atlassian.net/browse/ACJS-483
If you’re worried about storage size and want to use AP.cookie today (it’ll take time to implement a local storage solution) then have a look at the lz-string library. You might be able to half the size which could be more acceptable?
1 Like
@cwhittington Keypair could be regenerated from time to time, but we need to keep it stored locally somewhere anyway because the app redirects users to another host at some point (encryption in our case is involved into OAuth 2.0 authorization process).
Regarding guarantee of storage - since we are storing data on Atlassian instance host (via AP.cookie) it should not be the issue for us. A customer can’t use Confluence/Jira itself when cookies are completely disabled. This issue only appears because recently browser vendors started to block cookies for iframes hosted on third-party hosts and as far as I see it might become a trend. Safari and Firefox have already joined it.
Thank you for the suggestion with ‘lz-string’ library - we will test how it works for our case.