Sign in to Google Drive from new versions of Chrome disfunctional

[klapauciusisgreat]

When I try to sign in with Google drive, I can. However:

1. Chrome wants to prevent me, claiming the website is "unsafe", so need to go through 'advanced' and explicitly tell Chrome to ignore.

2. After signing in, I end up on the homepage that now looks identical to when I was not signed in (e.g., shows sample, and sign in). When I now try to sign in again, the click on Google drive does nothing.

I have not looked deeper, but I checked with Chrome and Safari on MacOS (using the demo site at organice.200ok.ch)

I'm probably do something super stupid, but I'm stuck :) If this is a known problem, many thanks in advance for telling me.

[klapauciusisgreat]

Actually, I was testing with the Chrome canary version, which gave me (among others) this warning:

[Report Only] Refused to create a worker from 'https://organice.200ok.ch/service-worker.js' because it violates the following Content Security Policy directive: "worker-src 'none'".

Sign in actually works on the main Chrome branch. Safari, OTOH, also did not work for me.

I'm not sure if I should close it, or if someone wants to look at this to prevent this from becoming a real bug as new chrome versions get rolled out.

[munen]

Thank you for reporting this @klapauciusisgreat

I do confirm that logging in to Google Drive doesn't work in newer versions of Chrome. It also doesn't work in Mobile Safari. It used to, though. Curious how Google is keeping users out when two of their products try to connect without informing the API admins.

I'm personally using Dropbox on a daily basis with organice, so I wouldn't have caught this until somebody spoke up. Thank you for doing so and providing debug information! 🙏

I'll look into this as soon as I can. In the meantime, I recommend to use another browser. I tested access to Google Drive sucessfully from Firefox on the same machine where Chrome didn't connect. In case the same problem exists on Android/Chrome, using Firefox in the interim should also work. According to another ticket, I just heard that this combination is working.

Sorry for the inconvenience and thanks again for helping out!

[munen]

Update: Turns out I cannot reproduce this bug. I ran into another bug with the Google Drive integration for which I created a new issue #109

But I'm also not running on Chrome Canary, I'm using Chromium from Debian testing (76.0.3809.100 (Developer Build)). And I can't test using Chrome Canary, because Google requires me to run a non-free operating whilst my dev boxes don't run Windows or macOS:

Since I cannot reproduce this bug on my machine, I'm tagging this issue with help wanted. It would be great if any Chrome and Google Drive users want to step up and take over this issue. I'll gladly support with code reviews and merging a fix in!

[munen]

@klapauciusisgreat Could you possibly take over this issue?

[klapauciusisgreat]

I'd love to look into it but it's not likely I'll get this in 2019 (just to set expectations). However, I might have time to debug and shed more light into what is happening and why. I could get signing into Google drive work on my android phone somehow in Firefox and Chrome, and I think I succeeded once on my iphone using Chrome.

But subsequent tries to go the webapp failed in the same way - I seem to be half signed in (which is why trying to sign in does nothing, but I still don't see the file picker).

I am running organice fine now OK on the default Chrome on MacOS. I will update this issue as I collect more info. Anyone else, please feel free to jump in and diagnose/fix ;)

[munen]

@klapauciusisgreat Thank you very much!

Whenever you or another dev has an initial fix, I'll be happy to review and pull it in. I'm happy to hear that you can use organice on standard chrome in the meantime(;

[klapauciusisgreat]

I can reproduce the issue by logging into drive on chrome, then logging out, then trying to sign back in.

I see this error in the console: "A cookie associated with a cross-site resource at https://admin.google.com/ was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032."

This may explain why things are more broken on canary chrome. But I'm not sure if this is related to organice. Chrome is synced to my gsuite account (maybe explaining the admin.google.com domain), but the account I'm signing into is a standard (ie consumer) google account, not a gsuite account.

Hitting shift-alt-R reload on chrome-stable and disabling cache in the devtools allows me to successfully log in again.

[munen]

@klapauciusisgreat Thanks for the update. This is valuable information!

This could actually be related to the other issue that I found while trying to reproduce the sign in problem: #109

organice adds the Google Drive API SDK through an old school <script> tag in the index.html file (here).

It would be better to put it as a proper dependency through yarn add googleapis and then follow the documentation to refactor the sync backend.

My understanding is that we currently need third party cookies whilst we wouldn't after the change.

[klapauciusisgreat]

There seems to be definitely some issue with the cache. Things work much better if the cache is disabled from the start. If I disable the cache AFTER signing in for the first time, I get this exception:

{message: "gapi.auth2 has been initialized with different opt…2.getAuthInstance() instead of gapi.auth2.init().", stack: "gapi.auth2.ExternallyVisibleError: gapi.auth2 has …XXX_KEY_XXX/cb=gapi.loaded_0:159:136)"}
message: "gapi.auth2 has been initialized with different options. Consider calling gapi.auth2.getAuthInstance() instead of gapi.auth2.init()."
stack: "gapi.auth2.ExternallyVisibleError: gapi.auth2 has been initialized with different options. Consider calling gapi.auth2.getAuthInstance() instead of gapi.auth2.init().↵ at new uO (https://apis.google.com/_/scs/apps-static/_/js/k=oz.gapi

The cached requests in question seem to be:

https://content.googleapis.com/discovery/v1/apis/drive/v3/rest?pp=0&fields=kind%2Cname%2Cversion%2CrootUrl%2CservicePath%2Cresources%2Cparameters%2Cmethods%2CbatchPath%2Cid&key=XXX_KEY_XXX

I also haven't really seen a logout request to the server - shouldn't there be, so the OAuth tokens can be invalidated ? I might easily have missed such requests however.

Sorry for not having something more concrete.

[schoettl]

Same warning here, in the chromium v80 console:

notes.org:1 A cookie associated with a cross-site resource at https://google.com/ was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.

google-chrome v79 does not show this warning.

PS: The warning shows up when the page is loaded, unrelated to the sync backend in use. I use Dropbox.

[munen]

Yeah. That’s pretty bad. Google breaking the whole app, because we use Google features.

Is there a way to fix this with the existing <script> tag?

Otherwise someone would have to tackle #150.

I’m neither a Google Drive nor a Chrome user. So as far as I’m concerned (with the limited free time atm as well), I’d rather disable Google Drive than have users not be able to use Dropbox and WebDAV.

NB: Afaik all works in FF - isn’t it fun to see how Google shoots itself in its own foot?(;

[schoettl]

How is #150 related?

I wouldn't disable Google Drive directly, because of existing users (or is it not working at all at the moment?).

For my specific bug (using Dropbox), the simple work-around is to press Ctrl-F5 instead of plain F5 reload.

[munen]

Sorry, #109 is related.

As for how well Google Drive works: Well, I'd say it's up to everyone to decide for themselves. However, apart from this ticket, #150 and well... the need to use Google, there's #127

[munen]

Is anyone interested in taking responsiblility for the Google Drive integration? There's a number of open issues which only relate to Google Drive(#107, #109, #127).

From the current maintainers, nobody is using the Google Drive integration and nobody currently has time to spend on it. Generally speaking, the current integration works (if you're an early adopter on organice.200ok.ch or run your own instance to provide your own Google Drive API key). However, the three issues linked above prevent new users to use Google Drive easily.

It would be great if there's at least one person willing to take on proper Google Drive integration. Otherwise, I fear, that the easiest option would be to disable Google Drive until such a time comes.

If someone speaks up, I'd be absolutely willing to share information, help out, do pairing sessions (on Zoom or the like) and do code reviews.

[schoettl]

It would be great if there's at least one person willing to take on proper Google Drive integration. Otherwise, I fear, that the easiest option would be to disable Google Drive until such a time comes.

But wouldn't disable Google Drive mean that
a) existing users can't use it anymore and
b) users with their own API key can't setup Google Drive without changing the code (re-enable it)?

In that case, I'd rather add some kind of hint in the UI, that it currently doesn't work at the 200ok-hosted instance.

[munen]

@schoettl I understand all your points and they are valid, of course. The situation with the current Google Drive implementation is pretty complex, though. Hence, there's no perfect bullet.

Regarding a: Even existing users of Google Drive cannot use it if they use any new version of Chrome (which likely they are if they are fans of Google products). For example, I can still login using Firefox, but I cannot login using Chromium anymore. But even with Firefox, I'm getting loads of warning messages in the console

In comparison, I'm getting no errors when logging in with Dropbox.

Since Google Drive is not completely functional, it's not a popular method to use the public instance. In the last 30 days, we had 43 API requests. It's not possible for me to know how many users there are, because we don't track any information. I can only see an anonymous total number of requests per API method. But 43 API requests could be just a single user.

In comparison, we are well in the 4 digits regarding API requests per day on Dropbox. Today, so far it's 1836 requests. Again, I cannot tell how many users that is, but it's likely a cople orders of magniture more users.

And then there's webDAV where I don't see anything, because people use their own servers.

Now, let's compare support requests: I regularly get emails from people complaining about GDrive, I never get requests for Dropbox, I sometimes get requests from people regarding WebDAV, but they haven't understood CORS yet and for that we have documentation.

All in all, it's pretty clear to me that somebody has to clean up the Google Drive mess or it's just not worth it to keep it in this state. Personally, I'm not a fan of Google whatsoever, but I did invest quite some time into this already. But from this point on, I don't want to spend the little time on support for a proprietary API. There's other stuff to be done that's beneficial for all the existing and new users.

Regarding b: We could discuss how to disable Google Drive integration. It could be a feature flag that can be set in the config. But it's not completely trivial, because of #109. I'd really like to get rid of that one anyway, because firstly it slows down every user for no benefit to them and secondly I have no trust that Google is not doing some malicious tracking through it.

If we don't find a sponsor for Google Drive and you have a different opinion on the matter, I'd be happy to have a call on this topic anytime. Of course, I'm also not happy to potentially delete/disable code that's largely working that some people might depend on. But at this time, without a sponsor, it seems to me as the most viable solution. When done in a single PR, we could create an issue "Integrate Google Drive" with a tag help wanted that links to the PR that disabled the code to show how to enable it again. So that person can then tackle it rather quickly.

[schoettl]

Alright, your suggestion in the last paragraph sounds good to me. Then, the existing code is not so much "lost" if someone takes the task some day.

We will see in the issues, if someone out there hosts their own Organice instance and uses Google Drive :)

[munen]

We will see in the issues, if someone out there hosts their own Organice instance and uses Google Drive :)

Yes. And the relevant issues already have tags for 'help wanted' and 'good first issue'. Hence, if this is important to someone, it's easy to get started.

I propose to leave the question open for some days. If nobody volunteers, whenever I have time, I'd:

1. Remove all the code and docs related to Google Drive in a single PR
2. Request for a code review from you
3. Close all existing issues related to Google Drive
4. Create a new issue describing the situation which also links to the three (then closed) issues

Does that work for you?

(I hope someone reads this and thinks "Oh no, I'll better get into this and save Google Drive integration!" g)

[munen]

Closed by #817.