The newest Manifest V3 policy for Google Chrome states the following:
Building an interpreter to run complex commands fetched from a remote
source, even if those commands are fetched as data
I am building a Google Chrome plug in that helps automate logging in for our enterprise users. Sometimes, the websites we support change their layouts or their login flows. When we detect this scenario, I want to be able to send an updated configuration to our extension from our servers so that our extension is aware of the new steps to execute to login.
Would this general flow be a violation of the above policy?
Appreciate any feedback on this!
Best,
Cerby Extensions
Related
Google chrome has just announced that V3 extensions is the disallowing of remotely hosted code. What does this means ? are they disallowing iframe? I am unable to find any details on this?
As wOxxOm noted, it means all of your code must be in the packaged you upload to the Chrome Web Store, you cannot include code from remote servers.
From the Overview of Manifest V3 docs on developer.chrome.com:
A key security improvement in MV3 is that extensions can't load remote code like JavaScript or Wasm files. This lets us more reliably and efficiently review the safe behavior of extensions when they're submitted to the Chrome Web Store. Specifically, all logic must be included in the extension's package.
I'm trying to get the Cyberduck CLI (duck.sh) to work interfacing with a google drive (not "Google Cloud Storage") and I'm having problems getting the oAuth authorization to work. I found this thread but it's out of date - as the newer versions of Cyberduck do absolutely work with Google Drive. Using the regular cyberduck GUI I can browse and operate on my G-drive instance, but I can't quite quack the code (sorry!) for how to make this work using the CLI.
[lwobker:~]$ duck -l googledrive://<user>#gmail.com/
Authenticating as <user>…
OAuth2 Authentication. Paste the authentication code from your web browser.
Authentication Code: <pasted pass here>
Save password (y/n): n
Disconnecting www.googleapis.com…
Login failed. Malformed auth code. Please contact your web hosting service provider for assistance.
I've tried a number of different URLs, including:
#gmail.com
me#gmail.com#www.googleapis.com
and a couple of others.
I also can't seem to figure out where the GUI version of cyberduck stores it's authorized credentials... if I could re-use those that would be fine, doing a one-time setup at the beginning doesn't break my use case.
I'm somewhat familiar with the Google Developers API, and I've created one for use with this project, but I can't seem to figure out how the Google "Client ID" and other credentials map to the Cyberduck tool.
Make sure you paste the auth code obtained from the Google login page opened exactly as is without any line breaks. More information is available in the wiki.
I'm developing a Chrome App and it's irritating using the suggested workflow of manually refreshing the app every time I make a change. I'd like to use a normal localhost server workflow but I need access to chrome.storage and chrome.fileSystem. Is there a way to enable these features outside of the extensions sandbox?
Is there a way to enable these features outside of the extensions sandbox?
No.
Not directly, anyway.
You could conceivably make a proxy extension/app that will execute privileged commands for you using "externally_connectable" messages.
But that will not help you in development - you'll need to proxy all API calls in a complicated way. It would probably also fail for APIs that require user gestures.
You should instead look into programmatically reloading your app by some external command. This is possible - an extension using management API and a native "proxy" module using WebSockets or Native Messaging can allow you to refresh your app by any event in the system.
It's the approach taken by GhostText, for instance.
I am working on an HTML5 web application, which I need to host in Google cloud platform.
How can I deploy the web application, which is based on HTML5/CSS3, jQuery to Google Cloud platform/App Engine?
Clarification:
My web application is build using HTML5/CSS3 with javascript to process data. I am using Visual Studio IDE for development of the same. As per my understanding, apart from the supported languages like java, Python, etc, we can deploy html5 web application to Google cloud platform. How can I package my HTML5 application, which is not using any specific language and deploy to App Engine?
Thanks
Ambily
You can deploy to a bucket directly:
The Website Configuration feature enables you to configure a Google
Cloud Storage bucket to simulate the behavior of a static website. You
can define main pages or directory indices (for example, index.html)
for buckets and "directories". Also, you can define a custom error
page in case a requested resource does not exist.
No programming language at all required :)
Google Cloud Storage
You need a account with Google Cloud Platform to start with. Assuming you have that.
Go to cloud console where you find all the admin menus for creating instances.
You need to create a compute engine instance, if you want to create full fledged website.
Steps to follow:
Create a instance (linux, 10GB disk, 1.7GB memmory) and configure it for all required components.
After this you can move your files to your website folder usually "htdocs"
You will be assigned with an empirical IP address.
Using zone management tools you can add a new domain. All that using the admin panel, no complexity involved.
You may required to configure proxy, if you need access to other machines.
I'm running into what seems to be a serious usability problem for users trying to use a Google Drive app from more than one account. In order for an app to be able to use Drive APIs on a user's behalf, the user must install the associated Chrome Web Store app while logged in as that user. The problem is that the Chrome Web Store seems to look for an app being installed per browser, whereas the Drive API needs the app to be installed per user.
As far as I can tell, the only way to install the same app for multiple users in the same (Chrome) browser is to install with one user, then log in as the second user, uninstall the app (which the CWS says is already installed), and then reinstall it (so that Drive will mark the app as installed for the second user). This is a very confusing experience, because during this process the app and the CWS are sending the user mixed messages about whether the app is installed.
I'm not sure if there's a canonical app to test for system bugs like this. Is DrEdit live somewhere? But if you want to see the problem behavior in our implementation, install the Graphing Calculator by Desmos.com as one user, launch it and log in using google drive and verify that everything is working. Then log out from the app, and use https://accounts.google.com to log in to google as a different user, and try using the app again. The app will tell you that it isn't installed (that's what Drive's APIs are telling us) and direct you to the CWS, which claims that the app is installed.
We are aware of the issue. And I agree this is a really bad experience for users using the same Browser (and the same Chrome session). One of the issue is that the account you are logged-into chrome can be different than the account you are logged into Google Web (Gmail, Chrome Web Store, Drive etc...) Therefore the Chrome Web Store has to make a choice to either use the apps's install status on the Browser or the Web Google account.
If you write an FAQ for your users maybe you can suggest that the most effective way to install the app for the second user is to simply install it using another browser like Firefox. Especially since Firefox won't be impacted by this issue because the app doesn't get installed on Firefox, only on the Drive account :)
The bug is filed internally, now we can only wait for it to be prioritized and fixed/sorted-out. We are also working on some other way for apps to have an install flow that doesn't involve the Chrome Web Store so that it will be less impacted by all of he Chrome Web Store/Chrome browser intricacies.
I'll make sure to ping our eng team on that issue again.