I used to have the v1 of the extension in the store with a set of permissions, when I published v2, I added two more permissions:
A "content_scripts" field with a "matches" entry that matches all
hosts using https://*/*
A "nativeMessaging" permission
These changes in v2 caused the extension being disabled and showed the following warning messages to users when they got the update:
To re-enable it, accept the new permissions:
Read and change all your data on the websites you visit
Communicate with cooperating native applications
The warning message have caused lots of the users to remove the extension, so I am considering to publish a new version v3 to remove the two newly added permissions. In v3 it has the same set of permissions with v1.
My question is what will happen to users after I publish v3:
For users who is still in v1 (haven't got the v2 update), will they still get the extension being disabled first?
For users who have already accept v2's permission, will removing permissions cause the extension being disabled again?
For users who is still having the v2 extension disabled (they didn't accept and didn't remove it), will publish v3 help enable the extension directly?
For users who is still in v1 (haven't got the v2 update), will they still get the extension being disabled first?
No, this happened to me once and the extension was not disabled.
For users who is still having the v2 extension disabled (they didn't accept and didn't remove it), will publish v3 help enable the extension directly?
No, the user will need to both accept the permissions for v2 and explicitly enable the extension.
Related
I am trying to publish a Google Sheets Add-on. I am working on the Google Workspace Marketplace SDK configuration. The configuration automatically includes the following 2 scopes as defaults:
https://www.googleapis.com/auth/userinfo.email
https://www.googleapis.com/auth/userinfo.profile
The Add-on has no reason to access the user's email or profile. Why are these added? Can I delete them? The only scopes that the script code should need are:
https://www.googleapis.com/auth/script.container.ui
https://www.googleapis.com/auth/spreadsheets.currentonly
When I go to create the OAuth Consent Screen. I am told that I need to create "A Youtube video showing how you plan to use the Google user data that you get from scopes". Am I being asked to do this because of these default scopes that are included?
EDIT: I deleted these 2 scopes and did a SAVE. It confirmed that the edits were saved. But when I refreshed the page, the scopes were back!
The reason why the Trust and Safety team is asking you for the video is because this:
1-Most of the apps that will be public, require certain steps. So the video is one of those.
2-Now, the main reason for the video, is because the scope https://www.googleapis.com/auth/script.container.ui is part of the restricted scopes. And according to the documentation it needs to go through the verification.
So basically the reason for the video is because you have a restricted scope because this scope allows you to display and run third-party web content in prompts and sidebars inside Google applications. Therefore, it is important for the verification process.
Now in regards to your concern of the default scopes, I was able to remove them and create OAuth consent screen without them.
When I try to load any website i get this error message from the WatchGuard:
And i can see in FireWare web UI, that the webblocker feature key is expired.
Is this connected? Will that solve my problem to renew that license?
The service may not actually be disabled (by you) and is still trying to reach the watchguard servers to check links. I would say you need to either renew the subscription or enable the license bypass setting. The bypass setting on my XTM Device' Web UI is located at Subscription Services -> WebBlocker -> Advanced and in there you should see "License Bypass". If you cannot do it from there, load up Policy Manager and navigate through to your subscription services, webblocker, configure and you should see the license bypass feature, you need to change it from "Deny" to "Allowed" and that should fix your issues.
I've searched Chrome Extension manifest document docs(https://developer.chrome.com/extensions/manifest), there's a "content_capabilities", but no link for that.
I infer it giving "permissions" to the "matches" as below.
"content_capabilities": {
"matches": [ "https://docs.google.com/*", "https://drive.google.com/*" ],
"permissions": [ "clipboardRead", "clipboardWrite", "unlimitedStorage" ]
},
but whenever I try to use this format in my local sample extension, I get this error.
'content_capabilities' is not allowed for specified extension ID
Is this format able to use in general users?
Indeed, it grants the specified permissions to web sites matching the
specified URL patterns. Here's why it was implemented:
Some hosted apps are used primarily to grant websites clipboardRead and clipboardWrite permissions, e.g. the Drive default hosted app. As part of the platform's move away from hosted apps, extensions should have the ability to grant these permissions to verified websites. These permission grants should be explicitly specified in the extension's manifest and displayed to users on extension install.
It's limited to a list of a few verified extensions (Google Drive and a few unnamed ones that could be internal Google extensions) but the restriction is applied only in the stable Chrome so you can use it in beta/dev/Canary channels [source].
In the old times (or even today in case you target the old browsers), if a web site like a text editor wanted to have the ability to access clipboard or an unlimited storage, the users had to install a separate hosted app for the site with the only purpose of granting these permissions. Hosted apps were deprecated long time ago (still supported though) so this content_capabilities key was exposed to extensions.
This is an obsolete thing now that the web platform supports the asynchronous Clipboard API and Persistent Storage API.
I have several client apps registered in the Azure portal. Each app has different scopes that are enabled/disabled. I used to be able to modify the scopes and save the updates for each of the register apps. Now I get the following error from the Azure portal:
Failed to update {my app} application. Error detail: Property identifierUris is invalid. [mURNc]
I also get this same error even if all I try to do is rename the client app. If I create a brand new app there are no issues. This appears to be a bug in the azure portal, but I'm looking for a workaround as I don't want to redefine all the scopes again, there are quite a few!
I've tried to rename things, change the client app ID, etc, but nothing seems to fix the issue, I get the same error. Again, this all used to work fine and now suddenly with no changes I get this issue.
The error says the identifierUris is invalid, but it isn't descriptive at all on which URI it is referring to. Any suggestions on how to correct this?
As junnas said, click try out the new experience in the Authentication tab of App registration and try again.
Also, when you see the above error, we recommend the following:
1.Edit the attributes individually in the manifest editor instead of uploading a previously downloaded manifest. Use the manifest reference table to understand the syntax and semantics of old and new attributes so that you can successfully edit the attributes you're interested in.
2.If your workflow requires you to save the manifests in your source repository for use later, we suggest rebasing the saved manifests in your repository with the one you see in the App registrations experience.
Hope this helps.
Recently I no longer been able to generate application keys in WAAD...(or to be more specific I can generate the key but I never get to see the value)
and after save I receive unauthorized access error...
I am a directory co-administrator - The key does appear to save, as after a page refresh there is an extra entry into the keys table. Currently only the directory full administrator can see the value but now no-longer co-admins.
The above issues also happens when making modifications to "permissions to other applications", azure reports unauthorized but the changes I make are again committed.
I have ruled out different browsers, have tired IE, and Chrome.
Help much appreciated.
co administrator is a subscription role not an Azure AD role.
In order to perform this you should have admin privileges in the Azure AD on which you're trying to create the keys.
What is the Azure AD role you're currently in ?
The issue was...
"Users may give applications permission to access their data" was set to "No"
Changing this back to "Yes" then allowed me to generate and see the key values.