We use cookie to identify user coming from particular Confluence instance as we need to know individual users (not only instance). Here is how workflow works:
- User authorizes third party service eg. Github using oauth2 flow
- Save authorization code in the add-on server
- Use cookie to identify subsequent requests
This works fine. However, requests from some users does not contain cookies which means they have to follow step 1 and 2 all the time. We are not able to reproduce it ourselves but it happens when users use our add-on.
Are there any limitations in Connect iframe or iframe in general that we are not aware of?
How do you handling accessing third party services on behalf of user in general?
My guess is that you’re running into browsers’ third party cookie limitation (since you’re in an iframe). Your best bet is to store the configuration either in the user properties in jira, AP.cookies OR use the accountId of the current user and store it in your db.
Thank you Daniel. Using AP.cooies is interesting idea, will look into that.
@chhantyal I’d ask the customer that’s being affected to provide browser information, including any types of security policies/configs they’re setting that are not defaults. Additionally, I’d ask them to try out a different web browser to see if they’re encountering the same issues.
If you want to reproduce this issue on your own machine and are using Chrome.
Open: Settings -> Privacy and security tab -> Site Settings -> Cookies and site data
Turn On “Block third-party cookies”
Some of your customers might have that enabled via policy across their whole organisation.
It’s a good idea to test your apps with this setting on, another issue it can surface is that accessing browser local storage will throw an exception that you’ll need to handle.