Draw.io SSO with Google Drive doesn't work

[NewAlexandria]

I can take some screenshots and hunt down the relevant domains, later, but for the moment I wanted to see if anyone else has run across this issue.

I am inclined to fork/add the draw.io domains to the Google Container, but I don't want to shoehorn them all in there, in case anyone would find that to be an egregious opinionation to take. Similarly, I am worried about other possible integration overlap issues, such as when draw.io is loaded into an Atlassian product page (Confluence).

Thoughts? Thanks

[Perflyst]

You should create a normal MAC container with your personal domain. This addon is normally for "normal" users which are not so techy

On September 7, 2018 4:35:57 PM UTC, NewAlexandria notifications@github.com wrote:

I can take some screenshots and hunt down the relevant domains, later, but for the moment I wanted to see if anyone else has run across this issue.

I am inclined to fork/add the draw.io domains to the Google Container, but I don't want to shoehorn them all in there, in case anyone would find that to be an egregious opinionation to take. Similarly, I am worried about other possible integration overlap issues, such as when draw.io is loaded into an Atlassian product page (Confluence).

Thoughts? Thanks

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/containers-everywhere/contain-google/issues/29

[NewAlexandria]

The issue is that Draw.io has some issue (probably bad / old implementation) that doesn't allow it to open any file that is permissioned through a Google Drive account, because the google cookie / SSO is in a different container from draw.io.

If certain draw.io domains will not be supported here, then the only option is to fork, or wait for the day that still-freewaree draw.io updates their SSO support.

[Perflyst]

I will take a look into draw.io Maybe we add it to the contained domains

On September 7, 2018 5:58:40 PM UTC, NewAlexandria notifications@github.com wrote:

The issue is that Draw.io has some issue (probably bad / old implementation) that doesn't allow it to open any file that is permissioned through a Google Drive account, because the google cookie / SSO is in a different container from draw.io.

If certain draw.io domains will not be supported here, then the only option is to fork, or wait for the day that still-freewaree draw.io updates their SSO support.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/containers-everywhere/contain-google/issues/29#issuecomment-419518905

[NewAlexandria]

I've added a couple of these domains to my fork, and specifically here.

I have also made a PR to this repo for other domain additions.

Hope that helps! If we find a pattern that's good for your goals with this repo then I can do more PRs.

[Perflyst]

I just took a look at your addon again. You added some SSO domains. Basically this is not a good idea because you can login nearly everywhere with google. Users should create a custom Multi Account Container for their needs. I will not include "not-google" domains just because a google login is possible on their website.

@NewAlexandria please merge newest changeset, it would be good that your fork is also up to date with the domain list.

[NewAlexandria]

I don't disagree with the principled resistance to this merge, but your stance doesn't change the fact that some Google SSO domains do not properly handle the callback, and the use of contain-google will prevent use of the site/tool.

The only workarounds are to

• open all these pages in incognito mode. This is a fail, because then everything else that is incognito is shared with that scope
• make their own fork, as I did.

[Perflyst]

You still dont get my "workaround"? If you want this setup I would say remove this addon, install multi account containers and create your own.

I also get your point. But this would be useless as you can nearly everywhere login with google.

On March 17, 2019 3:55:41 PM UTC, NewAlexandria notifications@github.com wrote:

I don't disagree with the principled resistance to this merge, but your stance doesn't change the fact that some Google SSO domains do not properly handle the callback, and the use of contain-google will prevent use of the site/tool.

The only workarounds are to

• open all these pages in incognito mode. This is a fail, because then everything else that is incognito is shared with that scope
• make their own fork, as I did.

-- You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub: https://github.com/containers-everywhere/contain-google/issues/29#issuecomment-473678841

[NewAlexandria]

If you want this setup I would say remove this addon, install multi account containers and create your own.

This is the problem - and the reason for my plugin. Everyone who wants to use an app with Google SSO needs to do this. That is needless effort, and arguably is the reason for FOSS.

ℹ️ reminder, not all Google SSO apps need to be in the same container as google domains — only those that do not properly handle the webhook and try to rely on the cookies.

[tmladek]

If I may interject, wouldn't a reasonable compromise, rather than maintaining a global independent filter set of domains that need a workaround, to allow the user to add an arbitrary domain into the Google Container rule set?

T

[NewAlexandria]

Yes, but I still think it is ideal to allow also a default set of the arbitrary / SSO domains. Give people a batteries-included experience, but make it extensible to new domains they need to add.