authentication problem with Google Drive for Confluence (Official) app
Asked by Cory Dyck:

I recently installed the Google Drive for Confluence (Official) app in our Confluence Cloud instance. I've embeded 2 different google docs into 2 different pages, but when i try to load up the page and edit the document, I am not allowed to do so because I receive a "Signed Out" message. When i sign in through the dialog, a second tab opens for a split second and closes again, and the Confluence Macro posts a "Reconnecting" message indefinitely. After some time, the message will change to tell me to sign in on another tab. However, most of the other tabs open are google doc tabs and I'm already authenticated on each of them.

I've tried to log in via MS Edge browser with the same result. Interestingly, I've logged in via Internet Explorer and it works as expected (even though a message keeps popping up in the sidebar saying that Confluence no longer supports IE - go figure). Any help is greatly appreciated!

![error.PNG](/t5/image/serverpage/image-id/89775i3CBB5BFF76783639/image-size/large?v=v2&px=999 "error.PNG")


Answers:
author: Shannon S
body: Hi Cory,

Welcome to Atlassian Community! It's nice to meet you.

I found a case where another person was having this same error with Cloud and the google Drive for Confluence (Official) add-on. They were able to resolve the issue.

Our engineer had asked them about clearing their cookies and cache in the browser to resolve the issue. They realized they were using an add-on called **Privacy Badger** which was blocking the docs.google.com cookie.

Do you happen to have any settings enabled somewhere that might be blocking the cookie? You mentioned you logged into MS Edge with the same result - what was the other browser you were using that was having the issue? Do other users have the same problem, and are you able to replicate this from your browser in Incognito Mode or with all add-ons disabled?

Thank you for the information!

Regards,

Shannon


author: Cory Dyck
body: Shannon, thanks for taking time to review the question above and provide an answer. I had previously tried clearing cookies and relaunching the browser (Chrome) to no effect. So today, per your suggestion, I compared my Chrome cookie settings to the basic out-of-the-box Chrome settings on another device (the other device was able to view and edit the google doc correctly in the Confluence page). In Chrome Settings -\> Privacy and Security -\> Site Settings -\> Cookies and Site Data, I turned OFF "Block third-party cookies" and "Clear Cookies when you quit Chrome." After relaunching Chrome, the page is viewable and editable as should be expected.

NOTE: Last week when i was working on this, I had created an "Allowed" site at \<myinstance\>.atlassian.net so that the site would be allowed to store cookies on my PC without opening the gate for EVERY site to store cookies. This apparently didn't work.

No other add-ons or extensions had to be disabled to resolve the issue.

In response to your other questions:

* one other user is having the same issue in Safari on a Mac
* Incognito Mode exhibited the same broken behavior - I tested it before adjusting my cookie settings
* I did not have to disable my add-ons, except I gave Adblock Plus a green light on Atlassian.net. This had no effect while in Incognito Mode before adjusting my Cookie settings.

comments: author: Shannon S
body: Hi Cory,

Thank you for following up. There may be other domains that are storing cookies to work with Cloud; in the case of my example the cookie was with Google and not \*atlassian.net.

You can also review the other possible domain and IP ranges that would need to work in order for you to be able to use your Cloud site:

* [Cloud IP Ranges and Domains](https://confluence.atlassian.com/cloud/atlassian-cloud-ip-ranges-and-domains-744721662.html)

Otherwise, other add-ons might need to store their own cookies, which wouldn't be covered by adding \*.atlassian.net.

Since you made those changes, has the other person with the problem tried the same and are they able to edit now?

Shannon


author: Cory Dyck
body: Shannon,

We tried accessing the same pages on a Mac using the Safari browser. And even after making the configuration changes on the browser to Allow Cross-Site Traffic, the user is still unable to view and edit the page correctly. We didn't clear his cookies before relaunching the browser. Perhaps we'll try that tomorrow. (He is comfortable with the extra click required to view the resource in Drive and edit directly there.)

As an aside, I added your "Cloud IP Ranges and Domains" to my allowed sites in Chrome and tried to re-enable the "Block Third Party Cookies," but unfortunately the page became uneditable again. Digging around I discovered that the option to "Block Third Party Cookies" actually prevents cross-site tracking via cookies (perhaps it should be called, Block Cross-Site Tracking instead). The Allowed list of domains does not affect this setting at all. If it is enabled, the Authorization link between Atlassian and Google Docs is broken.

Thanks again for your clear and helpful responses.

Cory


author: Shannon S
body: Hi Cory,

Thank you for letting me know that. Were you able to clear that user's cookies that you mentioned on Tuesday?

In your case, you mentioned that the page is uneditable again after adding those domains to Chrome. This is after it was working on the 16th when you disabled the blocking of 3rd-party cookies, is that right?

The Cloud IP Ranges and Domains page I sent you should be shared with your network administrators. They need to make sure that any of your internal configuration (e.g. firewalls, proxy, etc.) allows any connections to those locations, or you'll run into issues.

You mentioned you didn't have to disable any add-ons; does that mean that there were no add-ons in your browser besides Adblock Plus? Are you able to replicate this problem across several networks, and ensuring you're not behind a firewall or proxy?

In each case of this that I am finding in our support queue, it was caused by something in the user's browser, and wasn't replicable outside of that. All signs point to something internal, but in the past, disabling all add-ons, testing with incognito mode, or clearing browser cache solved the problem. It's very curious in this case that it's not working. If we're not able to narrow this down, I can still try to share your case with support, but if it ends up being something internal causing this, there's only so much we can do from our end.

Do let me know the answers to those last few questions, and I'll look and see what we can find out about this issue.

Thank you!

Shannon


author: Cory Dyck
body: Shannon,

I think I miscommunicated in my last response. The fix, in Chrome, for this problem was to simply turn off "Block Third Party Cookies" in the Chrome privacy settings. Out of curiosity, I tried "Allowing" the IP Range and Domain names you referred WHILE ALSO turning On "Block Third Party Cookies" setting, but unfortunately this caused the problem to reappear. So I simply turned off the "Block Third Party Cookies" setting again and all was well. No more testing is necessary for me. I'm good.

We worked on settings in Safari to resolve this problem for about 20 mins. At that point, my co-worker decided he would simply click an extra time to get to his documents in the browser. It wasn't worth the time we were spending to figure out the issue. If he changes his mind, I'll jump back into it.

At this point, I believe you can consider this question resolved. No further research or suggestions are necessary. Thank you VERY MUCH for your time. I hope I haven't wasted too much of it. :)

Have a great weekend!

Cory


author: Shannon S
body: Hi Cory,

What a relief! Thank you for clarifying that you were able to solve the issue by disabling the *Block Third Party Cookies* setting.

Hope you had a pleasant weekend, and a great rest of your week!

Regards,

Shannon


Tags: cloud