I have a Chrome extension built with MV3. It is a companion product to a mobile app that allows users to sign up / sign in with email, Google, and Apple. I have used the Firebase Authentication service to set up email sign up and Chrome Identity API to set up Google Sign in (solutions offered e.g. here & here). However, Apple Sign in (or any other 3rd party auth) seems to be completely broken in MV3 because popup/redirect OAuth operations are not yet supported in MV3. Seems like such a big miss by the Chrome Extension team!
My question
Is there a workaround solution to implement Apple Sign in for Chrome extensions using MV3?
Solutions I've tried thus far
I've spent a week now testing/trying different ideas and this is the closest I've gotten. Quick summary of solutions tested (in case it can help others save time):
Firebase Authentication service for Apple Sign in. It offers two methods that can be used, signInWithPopup and signInWithRedirect. As noted above though, popup/redirect operations aren't supported in MV3, so neither of these worked. I also tried this approach (also seen here) of storing the Firebase Auth files locally in case fetching remote scripts was the main culprit. That however didn't work either because the files still have some dynamic (remote) script imports that are called at compile time (I think) which again is prevented in MV3.
FirebaseUI library. In short, this library depends on the main Firebase library and therefore you get the same issues as the above.
Sign in with Apple JS. This implementation makes a call to fetch the Apple JS script. Again, MV3 doesn't allow for remote scripts, so it fails. As a workaround, same as with the first option above, I copied the Apple JS script and stored it locally in the extension. But it doesn't work in this case either. (I don't recall the exact reason, but the Apple auth object in the file wasn't instantiating or something).
Sign in to Apple manually. The most promising result thus far but I am stuck at how to read/extract the authorization response from Apple. I've outlined that issue here.
The only remaining workaround that I can think of is that I set up an externally hosted site using Sign in with Apple JS (option 3 above). Then when the user clicks the Apple Sign in button in my Chrome extension, I redirect them to that site, they conduct the Apple Sign in, and the auth details are then sent back to the Chrome extension. That however is both a very poor user experience and presumably has many security flaws.
Has anyone successfully implemented Apple Sign in with Chrome extension MV3 or can offer some workable solutions?? Thanks in advance.
Related
I've created a Bot in MS teams that can authenticate the user against AAD. I've used the AuthBot code for this.
This works correctly. I have questions regarding further improving the sign-in experience. The Bot currently opens up a web browser, the user logs in and is redirect to a page with a magic number that he or she needs to copy-paste back into teams.
If I understand the Authentication section on this page correctly, then the following should be possible:
The browser window can be opened inside of Teams instead of through
the browser by specifying a validDomains attribute in the Teams
package manifest file. However, I chat with the Bot 1:1 and it
doesnt seem to use the manifest file (the Bot's image doesnt use the
one from the manifest). How do I get the login window to open inside
Teams?
There is a MS Teams javascript file. Can I use this (on the page that my Bots shows after authentication) to
redirect the user back to teams, and possibly automatically paste
the magic number into the chat with the Bot?
We missed answering this in August, apologies.
A more elegant way of doing bot authentication has been a common developer request. We are almost ready to publish samples and documentation for this solution once it's fully deployed on all client platforms. This approach removes the need for AuthBot completely and supports an integrated authentication experience, i.e. without opening a browser tab.
Currently, however, to answer your question, there is no way to have an inline authentication experience and the validDomains is not enforced (since it's just opening a browser page). The JavaScript client SDK you refer to is not used at all with bots because bots cannot currently run code on the client.
So in other words, what you are doing with AuthBot is currently the best possible way to do it.
My Google Chrome Extension (Annotate for Chrome) has successfully received payments.
I have updated the app recently but not the payment flow.
Now when a user initiates a payment the Google modal pops up (that displays the Google payment - from Buy.js) the spinner just runs endlessly and console shows a 401 error.
I double-checked manifest and in-app purchase SKU etc and don't see any differences from previous versions that worked. My check for current license is working fine - which tells me my app is being recognized by the Google Web Store and returning data on specific users license status...
Any thoughts on what could cause this? Many thanks.
(I submitted a ticket to CWS support - nothing yet). Probably something stupid but I don't know how to debug. Or epic fail on Google's part.
The root cause of this issue has been fixed and purchase flows should be working as expected now. Details over here: https://groups.google.com/a/chromium.org/d/msg/chromium-extensions/bxoptYk8--Y/Mh_qJp4gDQAJ
This is a problem with the Chrome Web Store.
I tried to purchase another Extension (https://www.twinword.com/blog/how-to-quickly-monetize-your-chrome-browser/) that uses in-app purchases and saw the exact same problem.
So Google's Web Store purchasing process has been broken for a week+ and no one at Google cares. Maybe they should get out of the payments business and require developers use 3rd party solutions. Utterly disgusting on Google's part. I'd like my 6 hours of troubleshooting back...
Before deciding to write this issue on Stackoverflow, we tried everything that we could through the normal/official (and slow) contact process (contact form and developers emails).
So this is actually our last try to solve it and also expose some of the Google's review mistakes and inconsistency when reviewing new items (extensions).
We currently have an extension (item hjdkfeeffbfcoanbnkeedjccphcmpehm) that was approved and published few months ago and that is now used by more than 70,000 people, with excellent rating on Chrome Web Store.
https://chrome.google.com/webstore/detail/ad-block-chega-de-publici/hjdkfeeffbfcoanbnkeedjccphcmpehm?hl=pt-BR
This extension is an Ad Blocker and was primarily focused in the Brazilian market, for Portuguese-speaking people.
Due the success of this extension, last week we decided to add two new extensions (Ids: mmcgdfakfmbepgnoogipkccigohjjcim and hgekbffcnpflnhfjkdfdlhffigdfbnae) that would focus on English-speaking and Spanish-speaking countries and, when we tried to add these extensions with the exact same source code that we used for the item that is approved and published, the Chrome review team is always rejecting with these arguments below:
To have your item reinstated, please make any necessary changes to ensure:
All of the files and code are included in the item’s package.
All code inside the package is human readable (no obfuscated or minified code).
Avoid requesting or executing remotely hosted code (including by referencing remote javascript files or executing code obtained by XHR requests).
So, just to make it clear:
1) The extension that is currently approved and published (item hjdkfeeffbfcoanbnkeedjccphcmpehm) does have minified code and even so was approved.
Even so, we did what Chrome's team was requesting and uploaded new packages with human-readable code (not minified) and even so, again, our extensions were rejected;
2) The extension that is currently approved and published (item hjdkfeeffbfcoanbnkeedjccphcmpehm) does load dynamic content from our server, as we need to daily and automatically update our URL list for blocking ads, its impossible to simply build and publish a new extension version every time we need to block a new URL or type of Ad.
Ad Block Plus, uBlock and other Ad Blockers do the same and they are approved and published on the Chrome Web Store.
3) The extension source code of the new items, except by the text that needed to be changed, as the new extensions are in different languages (English and Spanish), is exact the same of the extension that is approved and published, line by line;
In order to prove that from them, we even created a diff file comparing line by line the source of the approved extension with the new extensions, even so this was not enough to prove them we were right and also to simply get some answer on our emails.
We have already argued all of that through email with Chrome's team, but never received any answer or reply, except by the standard "rejection and removal" emails. They simply don't care.
That being said, it's clear to me that:
Google Chrome team is deliberately trying to prevent us for publishing two new Ad Blocker extensions, because they saw the growth that we had with our first extension (that is approved and published);
or
Someone at Chrome's team is simply making repeated mistakes and no one cares nor read our emails;
I hope this message can help us get some human attention within Google's team and also alert you guys about the "really strange" problems that we are facing.
Although this issue was more related to Google's policies than programming in the first place, the solution is still relevant to share for other Chrome extension developers, as it was somehow related about how to load remote resources for your extensions.
After posting this issue Google's team contact us and their question for keeping rejecting our extensions was related to the way we were loading remote resources for our extension.
Google's reply by email
Your new extensions are fetching resource(s) from AAA.com.br. However, the official website(s) registered for your new items is BBB.com. This means that the resource(s) being fetched are coming from remote/third-party source(s) and as per our program policies, we had requested you to check the following:
If all of the files and code are included in the item’s package,
All code inside the package is human readable (no obfuscated or minified code), and
If the items are requesting or executing any remotely hosted code (including by referencing remote javascript files or executing code obtained by XHR requests)
The specific issue here is with #3.
It'll be great if you can give us some context on the resource that you're fetching and how the two websites in question are related. Once we have that information, we'll be happy to help you guys with the publishing process.
As we have two different URLs related to the same extensions (we have three extensions), for the new extensions the URL BBB.com was configured on Chrome Web Store Developers Console, but we were actually loading the resources from the URL AAA.com, that have being in use since we published our first extension.
Although both URLs were added and owner-validated to our Chrome Web Store Developers Console and both URLs were related to the same extensions, we now understood that is a good practice to load the resources from the URL that is actually configured on the extension details, even if you have more than one URL for the same extensions.
So, if you have URL AAA.com and BBB.com, and both are used for the extensions A and B, try to load the resources of the extension A from the URL AAA.com and the resources of the extension B from the URL BBB.com, even with both share the same backend.
This will avoid Google's team to think that you might be loading resources for your extension from unknown 3rd parties, that is forbidden according to the program policies.
I would like to add the ability to cast my chrome packaged app to a google chromecast device.
So far google states that all you have to do is add
to your page and the API will inject itself.
For me that doesn't happen. No code is injected.
Am I doing something wrong?
There doesn't seem to be a demo showing this type of capability.
EDIT:
I just wanted to clarify a bit. All that I would like to do is display my app to a screen.
I have no media. I simply want to display it exactly as the chrome extension in the chrome browser would.Therefore I would follow the directions for a sender only. The app is packaged so it is running only CSS/JS/HTML5 code. The app is designed to run offline.
Steps I've taken to cast:
1. I've added the extra bit to the HTML line:
2. I've followed the whitelisting, to the best of my understanding, by adding my "website address" to the chrome extension. So I've added the only two address that should matter.
127.0.0.1
192.168.1.106
There is a good chance Content Security Policy is blocking the implementation of the cast API being injected. I see that you've filed Issue 287254: Google cast (chromecast) ability for packaged apps, and suspect we will need to wait for it to be implemented in a packaged apps compliant way.
You must whitelist your device and your Chrome app. See here for more details:
https://developers.google.com/cast/whitelisting#whitelist-chrome
I'm making an extension for Google Chrome and I use code for autoupdating. This is because the extension isn't yet in Google Chrome webstore. But in a few days I will upload it to the Webstore and Google says you can use the Webstores autoupdating. But if I don't want to use that, will my app still update by my own server, like the way it does now?
Thanks in advance!!
I agree that docs are not very clear about this:
If you publish your extension using the Chrome Developer Dashboard,
you can ignore this page. You can use the dashboard to release updated
versions of your extension to users, as well as to the Chrome Web
Store.
But, I've tested it myself and your update_url setting in manifest.json will be overridden when you publish your extension via Chrome Web Store (CWS). In other words, publishing to CWS means that you can't use self hosted autoupdating anymore.
The reasons for that, that I could think of, may be as follows:
CWS wants to keep track of each extension stats (i.e. number of users using each extension)
privacy concerns (people don't want you to track them when they update extension)
security concerns (each extension update must go through CWS verification process)
If you want to track people (please don't) use Google Analytics on i.e. background page of your extension.