I have a bit of a nagging problem here. At my current position, we have a Google Apps domain set up (for the sake of this question, it will be pennmanor.net) and I would like to determine a way to log in to Google Chrome (the web browser) and connect the Apps account to sync the settings.
I have found this article: Bug Report that describes the issue, which has been resolved. I have made sure that the options described in Comment 64 are correct, but still no sync. Other articles suggest that it is simply a matter of punching in the credentials and thats it.
We do have a custom SSO and Active Directory set up with the apps account, would this possibly be the cause of the problem?
Does anyone know what I might need to do to enable account Google Chrome to sync pennmanor.net account?
Are you setting user's Google password? Chrome Sync will not use the SSO password. If your users are stored in Active Directory, you can use the Google Apps Password Sync tool to sync passwords from AD to Google as they are changed:
http://support.google.com/a/bin/answer.py?hl=en&answer=2611859
Related
I have published a Google Apps Script as a web app. Because the URL is not so nice, I have included the script in an iframe on a site with a nicer URL. I have included the corresponding option so that it works at all. Now this web app should only be accessible within the Google Workspace (formerly known as GSuite) I am working in. This setting can be done when publishing the Web App. The problem is, however, that some users (by far not all users!) in our Google Workspace cannot access the Google Apps Script that way. There is a error message saying that Google prohibits the connection.
It seems like the authenticiation does not work "through the iframe". Interestingly, the problem only arises when
the script is embedded in an iframe (the direct script URL by Google works for the users)
the script is restricted to the Google workspace.
Chrome is used (the issue does not happen with Firefox)
It is remarkable that for most users in our Google Workspace the issue does not appear. We had similar problems when including the script on a Google site (which, in the end, is also just an iframe), but with less users experiencing the issue. I have already made sure that the users are only logged in with their Google Workspace account (no other account which has no permission). In Inkognito mode the same happens.
Can someone explain this behaviour? And how to fix that (without changing the framework)?
I have been in contact with the Google support. If I remember correctly, this kind of authentication will be deprecated and should now be done with other tools, for example Google's Firebase Auth.
Am I correct that there is NO direct replacement for this process on marketplace:
publish unlisted on chrome add-on store
directly share the link with others who can use the script
In particular, the mechanisms allowed me to use a script that I write across all my google dsocs.
With the move to marketplace, is there any way in which I can do this? I.e., write a script (container-bound or otherwise) and have access to it from ALL my google docs?
This is not about privacy: I am super-happy for the script to be shared with others or be public, but the review process has already turned down the script as unfinished. However, the script does what I need it to do... so I'd like to be able to use it across my google drive primarily... however, with the new google marketplace that doesn't seem to be possible.
One way may be via Google Suite domains. That seems to allow for internal publication. However, I've done that, and so far not received an acknowledgement or notification (while the GSuite page says 'under review'). My understanding was that internal scripts weren't subject to review.
Would anybody be able to comment on this and confirm, clarify or refute this understanding?
The move to Marketplace has certainly caused a lot of confusion! Trying to find all the tick-boxes can be difficult.
The two main places to look are the OAuth Consent Screen, where you need to make sure it is Internal (you have to have a GSuite account for that):
And the Marketplace SDK under Configuration check it is set to Private (although note that if it has transferred from the Chrome store it may already be set to Public, and this can't be changed). And under Publish it is set to unlisted.
This "unlisted" setting may be the crucial one for you as even if it is "Public" it won't be in the Marketplace, but will only be available via a link. But if it is "Public" I don't think you can make updates without going through the verification process. But if you don't go through the verification it should still be available.
Hope this helps, happy to answer any other questions.
Andrew
I have created my script and it works great. I have changed the sharing so anybody can view it, but it still asks users to login to their Google account to run the script.
Here is the link: My script
Currently you're web app is set to execute as User accessing the web app. This means they need to sign into a Google account to execute any of the code in your app.
You need to change this setting to: Execute the app as: Me
As well as change Who has access to the app from Anyone to Anyone even anonymous
Example:
The setting can be found by clicking on the cloud icon in the Apps Script IDE's toolbar.
Edit: Added new image to reflect proper settings.
It might be that they've updated the settings to where the least restrictive option is "Anyone" which would still require a log in. This is happening with my Google Workspace for Education account.
Google Apps admin console has a section dedicated to Google Drive settings for all the domain. Through these you can decide if users can share or not documents outside the domain, etc. Unfortunately you cannot apply the settings to specific sub-orgs but to all the domain. However Flash Panel allows you do to this and I'm wondering which API they're using to accomplish it. I went through Google Apps Admin SDK documentation but I couldn't find anything to control or change Drive settings in the Admin console via API.
Have you got any clues about it?
Thanks a lot!
When you change these settings in the CPanel, as you noted, the setting is strictly enforced for all users in the Google Apps instance. The user no longer even has the ability to share Drive files outside of the domain.
There are no API settings that correspond to the CPanel settings. The way FlashPanel appears to be enforcing the settings is by setting up "rules" (this OU can't share with people outside the domain except for this external domain). Then FlashPanel monitors user file sharing under that OU, looks for violations and can either automatically undo the share or send a notification of the violation.
Thus FlashPanel is not strictly enforcing the sharing policies like the CPanel setting can. The user still has the option to share externally and for some period of time, the file is actually shared externally. FlashPanel simply has the ability to notifiy and or rectify the situation afterwards.
I uploaded a utility in the last few days to google cloud storage.
It's a zip file containing two executables and a readme file.
I tested the download and it worked fine. I then looked into how I could see the download stats and yesterday I enabled logging.
I posted the link to a mailing list this afternoon and clicked it to verify that I had the right link and the download in chrome reports "xxx.zip appears to be malicious".
This did not happen prior to when I enabled logging, but I don't know for sure that is what caused it.
I am using a CNAME alias for the download, and I am a paying google apps customer.
The executables are not malicious in any way. They are simple utilities for doing replacements in text files. They do not access the network at all.
My question is "Why is my zip file being reported as malicious?" and is there any way to remedy this situation?
I looked around for a solution to this problem and I found the following advice:
1) Sign your EXEs. As it turns out, this advice is incorrect. While it has worked for some people, there are people who report that even signed executables are reported as malicious downloads.
2) Use SSL. SSL access is not available for google cloud storage unless you use the commondatastorage.googleapis.com or sandbox.google.com URLs. While this does might work, it doesn't resolve my problem.
3) Use the commondatastorage.googleapis.com URL. This works. The same file using the commondatastorage.googleapis.com url rather than my custom CNAME record does not report that it "appears malicious".
4) Register your site with Google Webmaster Tools. Getting around Chrome's Malicious File Warning According to this stackoverflow entry, the solution is to sign up for Google Webmaster Tools and add your site.
I have tried this one, but it has not made a change just yet. Because this is google cloud storage and not a main site, I added an index.html page, a 404 page, and ran the gsutil commands to enable web configuration within google cloud storage. I added the site to Webmaster Tools and additionally added it to Google Analytics.
I'll give solution 4 a few days to see if it pans out.
It seems like this is more of an issue with Google Chrome and not necessarily Google Cloud Storage. Chrome's methods for identifying malicious files are less than desirable right now.