90% of my Google Apps Script/HTMLService web app is available to anonymous users, however user must be signed in with G-Suite account in order to access the remaining 10%.
Desired behavior is that if user is already logged in to G-Suite (e.g. read Gmail from that browser), the web app recognizes the user without prompting to log in again – as if you went to Google Calendar just after reading Gmail. If user isn’t logged in yet – he needs to be prompted to log in using #my_g-suite.com account when accessing the restricted features.
My first try was two app approach: one published as “available to anyone including anonymous” and another “available to members of the my_g-suite.com”. The problem with this approach is that 2nd app only shows log in screen if browser has no google identity. If user is logged in to regular, non-g-suite gmail, strange google Driver error is shown instead of login prompt. I posted question about this a while ago, no solution.
So instead I implemented a sign-in button using this guide. Behavior I’m seeing is not what I expected:
If user is already signed in with UserOne#my_g-suite.com prior to accessing the app (e.g. looked at G-Suite email account), Session.getActiveUser() on server side returns correct user ID, however googleUser.getBasicProfile().getEmail() on client has nothing.
If user has not signed in with G-Suite ID using prior to accessing the app and then signs in using the Sign In button on web app, googleUser.getBasicProfile().getEmail() returns correct user ID, however ), Session.getActiveUser() on server side returns nothing.
If user has signs in using the button as UserTwo#my_g-suite.com, no other G-Suite app recognizes it. So if user then signs in to UserOne#my_g-suite.com and comes back to the app, Session.getActiveUser() says it’s UserOne#my_g-suite.com and googleUser.getBasicProfile().getEmail() says it’s UserTwo#my_g-suite.com. Two conflicting identities simultaneously.
How do I make sign-in into my app be 1) seamless with other G-Suite services rather than having completely separate, app-only 2nd identity and 2) restricted to #my_g-suite.com?
Following #TheMaster advice I tried this:
Created a Google Sites site "login.my_g-suite.com" which is only available to g-suite users and has a single page which says "you are logged in to g-suite"
In my web app which runs as "me" and is "available to everyone, even anonymous", I implemented a check if Session.getActiveUser() is g-suite user. If not, I do window.open("https://login.my_g-suite.com") which opens log-in screen in the new tab as expected.
After user logs in, I reload web app. And here's the sad part:
If browser hasn't been used for non-G-Suite account (like regular Gmail) - all works great. Session.getActiveUser() shows newly logged in user ID
BUT if that browser has been logged in to non-G-Suite account, Session.getActiveUser() has no idea about the fact that I just logged in G-Suite in another tab (even after reloading web app). Which is back to square one.
Comparing this to Google's own apps, this behavior is not much different: e.g. if you read regular non-g-suite gmail, then go and log in to Google drive using G-Suite account, and then reload gmail - it doesn't take you to G-Suite Gmail automatically just because you logged in to G-Suite account on that browser. You need to explicitly tell Gmail that you want to use G-Suite account by invoking active-account-selection menu (round avatar icon on the right upper corner).
Looks like no matter what approach I take, I hit the same wall: the need to tell stand-alone Google App Script which Google identity is current. And I don't see any way of doing that.
What I stated above is no longer true due to recent change by Google. (2) now results in Error 404 instead of login screen.
Sign-in issues which a few days ago were only affecting stand-alone Google App Script apps now are plaguing entire G-Suite. Our volunteer first-responder organization got G-Suite mainly for the secure intranet site (members.my_g-suite.com) where we share internal protocols and documentation. It's built on new Google Sites and Google Team Drive. Before Wednesday attempt to access members.my_g-suite.com used to take to G-Suite login screen. Now it takes them to "404. That’s an error. The requested URL / was not found on this server. That’s all we know.". The only workaround is to force users to log out of personal Gmail each time before accessing G-Suite, which is not a reasonable request for a volunteer using personal device. We feel like Google pulled the rug from under our feet. The only hope is that this is a temporary change and they'll revert it to how it was in the beginning of the week. We also confirmed that this change is not limited to our G-Suite.
This is because your web-app runs inside a iframe. You can force login by denying access to the web-app manually.
onload, Check Session.getActiveUser().getEmail() server side and see if it matches your domain,
If it does, proceed to load your actual web-app
If not, just provide the information that the user needs to login to your gsuite to access.
You can also
Proceed to open https://admin.google.com (or any url specific to your domain) in a another tab
See whether it's open and use setInterval to check the other window.close property. When closed, reload your web-app.
Related
So the issue is that sometimes users end up getting endless Authorisation Screens even after approving authorization.
This happens because of the multiple-user login sessions issue in the Google Apps script "https://issuetracker.google.com/issues/69270374" which somehow mix the account approving the authorization and executing the script.
I have tried the methods found on the issue page so far like these
https://apps.myrout.es/msii
https://sites.google.com/site/scriptsexamples/home/announcements/multiple-accounts-issue-with-google-apps-script
Most of them are relevant to Add-ons not for web apps as I don't see a possibility to compare user emails.
Gone through these questions here but none of them have any references which can be used to find a workaround for web-apps
I can't open my Web App Link on Google App Scripts when multiple Gmail accounts logged in
Google Web App Multiple Google Accounts Error
At the moment I want to determine whether the user is having multiple users logged in and ask them to log out(will provide a link to log out) and log in with a single account instead.
Is there a way to handle it?
Thanks
I'm writing a Playwright test that starts with a Google Auth0 login. After I fill my test user and password in the UI (google login), in Firefox and Webkit the authentication passes successfully, while, on Chromium, I'm getting the Verify it's you message (with a "send sms" message).
The account does not have 2 steps authentication.
When it happened locally, I opened the browser in headful mode, and after few clicks (which I assume "told" the browser that I'm a real user) the problem disappeared (I can now run my tests in headless mode locally). But, it still happens on CI (GitHub)
I run the test with chromium flags: --disable-dev-shm-usage and --disable-web-security.
I couldn't find any data about it anywhere...
When Google determines that a user is logging in from an unknown device or a new location, they may prompt the user with an additional login challenge.
The login challenge that the user receives depends on the information that associated with the account.
Does the prompt say "Enter a phone number to get a text message" or something else like "This device isn't recognized..."
If the former I believe you can circumvent this extra prompt by having a phone number linked to the Google account in question. If the latter I believe the prompt is once per user per device.
My understanding it is basically Google trying to get a valid phone number for the account (to prevent spam etc).
-- Edit
The only other thing I can think of is that you can temporarily turn off the verify-it's-you challenge, for 10 mins, but only if the account is a member of a Google Workspace or Cloud Identity service. I am not sure this is possible for an unmanaged account - or how useful it would be. The other issue is that for "free services" Google doesn't really offer any kind of support.
Anyhow, you might try "Temporarily turn off login challenges for a user" -
https://support.google.com/a/answer/12077697
There is also so good information on this verify-it's-you challenge here.
https://workspaceupdates.googleblog.com/2018/04/more-secure-sign-in-chrome.html
It has some notes on disabling the challenge per organization via response headers, but again this is for an organization and managed accounts.
If you wish to disable the new screen for your organization, you can
use the X-GoogApps-AllowedDomains HTTP header to identify specific
domains whose users can access Google services. Users in those domains
won’t see this additional screen, as we assume those accounts are
trusted by your users. This header can be set in Chrome via the
AllowedDomainsForApps group policy.
When I am logged in to lets say my personal gmail account on our work domain and run a script within Google Sheets that pops up a ui.showmodaldialog with embedded html it works exactly as expected. The issue is people often need to log into a different email account within the work domain. When they click their icon and switch to this other account and then run the exact same script, it refuses to display because of the X-Frames-Options policy. The user can rerun the same script from their personal account they were logged into originally and it will still work just fine.
It only appears to work from whatever email account they were originally logged into and not from any additional accounts you log into thereafter. If they logged into the work email account on the domain first and then their personal one second, it will only work on the work account and not their personal account (on the same domain). This seems like it is an issue with the Google Suite. It is not browser dependent.
Any ideas on if there is a way to correct this issue? Thanks!
If I specify access_type=offline in the auth url and a user attempts to auth a second time I get a box that says it is asking for offline access.
I would have expected it to be already authorised and so not require additional permissions
Any ideas?
Edit:
A bit more info. The first time around it makes no mention to the user of needing offline access. I would have thought the offline permission to be mentioned in the original auth anyway.
Edit 2:
Some more info on my use case. It is possible in our system for a person to have two accounts but then use the same google drive account. This means that we have no way of knowing that user has already authorized with google and so have to present the authorization again for the second user.
The first time around (for user 1) you are told that the app is asking for :
View and manage Google Drive files that you have opened or created
with this app
View and manage the files and documents in your Google
Drive
The second time around (for user 2) you are told the app is asking to:
Have offline access
This seems wrong to me.
As an aside:
The whole "have offline access" statement is very confusing for a user and also quite misleading. Most people assume this means the app can read the contents of your pc. In fact it means that the app can authenticate with your account with out you being there (i.e. using a refresh token).
I'm using Google Apps Script UI to create forms for students at my school. I've restricted access to my domain for added security, and to capture users' email addresses.
The problem is that many of our students have separate Gmail accounts. If they are already logged into Gmail (not our domain), they don't get a log-in page, but something prompting them to request access.
Any suggestions for avoiding this?
Thought I saw a request in the issue tracker for an account choosing feature, but my guess is that you'll want to allow anyone to access your web app and show a custom prompt if their email is non-domain. I don't know how well this would work with shared computers, but creating separate Chrome user accounts for each of my Google accounts has solved all my multiple sign-in pain.