401 error on CWS Payment Flow - google-chrome-extension

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...

Related

How to implement Apple Sign In in Chrome Extension MV3?

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.

google removed my extension, trying to understand why

My chrome extension was removed from google chrome store and I don't know why, I'm not using remote hosted code. I am using manifest V2
Does anyone can suggest why they removed my extension?
Time line (emails that I received from google):
18 November 2020:
Dear Developer,
Protecting users and their data is a fundamental aspect of the work we do on Chrome. Last year we announced a set of policies to protect users and their data by requiring that extensions request the narrowest possible permissions, and we required more extensions to post privacy policies and handle user data securely.
Today, we are announcing policy changes that build upon those protections by:
Limiting what extension developers can do with the data they collect.
Requiring developers to certify their data use practices.
Starting January 2021, each extension’s detail page in the Chrome Web Store will show the data collected by the extension, in clear and easy to understand language.
Data privacy policy update
We’re introducing an additional policy focused on limiting usage of user data collected through a Chrome extension. More specifically:
Reiterating that the sale of user data is never allowed. Google does not sell user data and extension developers may not do this either.
The use or transfer of user data should be for the primary benefit of the user and in accordance with the stated purpose of the extension.
The use or transfer of user data cannot be used for creditworthiness or any form of lending qualification.
The Chrome Web Store will also help users understand an extension’s privacy practices directly on the Chrome Web store listing.
On each extension detail page, the data collected by the extension will be displayed in a standardized manner. Additionally, whether a developer has certified their compliance with the limited use policy will also be displayed.
Developer-provided privacy disclosures
To publish or update an extension, developers must provide data usage disclosures directly from the developer dashboard. These disclosures include:
The nature of the data being collected from users.
The developer’s certification that they comply with the new policy on limited use.
The content of the form is grouped by category to make it simpler for developers, and maps exactly to the disclosures that will be displayed to Chrome users. Most of this information should be consistent with the existing privacy policies that developers have provided to the Chrome Web Store.
Implementation timeline
Data disclosures collection will be made available to developers today and will be displayed on the Chrome Web Store listing starting January 18, 2021.
Starting in March 2021, the Chrome Web Store team will reach out to developers with a warning to complete the disclosure requirement. Inaction after 30 days of the warning will result in the suspension of affected items and the deactivation of the existing user base.
See the limited use policy FAQ and the corresponding blog post for additional detail.
Thank you for your cooperation, and for your participation in the Chrome extension ecosystem!
The Google Chrome Web Store team
5 February 2021:
"Dear Developer, Last year, we announced the rollout of Manifest V3 support for Chrome extensions alongside Chrome 88. These updates to the extension platform make the extension experience safer, more privacy-preserving, and more performant for Chrome users. One of the key changes for V3 extensions is the disallowing of remotely hosted code. Now that you can submit to the Chrome Web Store, we’ve updated our Developer Program Policies to reflect these new guidelines. Please refer to our Developer Program Policies for more details on these updates. Thank you for your cooperation and for your participation in the Chrome extension ecosystem!"
31 March 2021
"We regret to inform you that the item has been removed from the Chrome web store. Details are shown below."
"We did not receive an update from you regarding the Google Chrome item before the end of the warning period specified in our previous email. Because the item still does not meet our policy requirements mentioned in the previous email, it was removed from the Chrome web store. "
Based on your timeline it doesn't look like you received a warning email. Try reaching out to CWS Developer Support using the following options:
My item (extensions, app, or theme)
My item was warned / removed / rejected
I did not receive any communication
Yes
In the additional comments section, note that you did not receive a warning email and that the takedown email you received did not state the reason for the takedown. A member of the review team should follow up with you in less than 24 hours.

Actions on Google - My alpha tester could not access my action

Initially, I built up a test agent on DialogFlow console according to the document, and it works well on the Actions On Google which is a simulator of Google Assistant on mobile devices.
Then, I deployed it through the Release in the left menu as you can see the pic attached.
deployed successfully
After that, I added some Alpha Testers including my colleague and sent my opt-in link to my colleague, besides, I granted them all the viewer permission in IAM.
However, problem appeared. It didn't work well on my testers’ phone(IOS 10+) but only worked well on developer's account(mine). When they opened the link I sent to them, and clicked send to devices, then clicked the notification on top of the screen.
send to device
The result is shown as below.
Google Assistant didn't respond to "Talk to mytest app"
In my case the command was set as "Talk to hello qad", and it did work well on my phone used the developer account.
developer account works well
If my tester input the text "Talk to hello qad", it just replied some direct searching results not hello qad diaglog.
To recap:
My action has already been in "deployed" status for couple of days
I've added the tester accounts in whitelist and give them "Viewer" permission in IAM
Testers could see the action directory page in devices by open opt-in link, but they couldn't see the "I'm In" button and couldn't access the action
Appreciate for any help or advice
During my project development, I also faced a similar issue. This is how managed to do testing:
Made sure all Google Accounts were created with the US as the country.
Through IAM, share AoG project with the tester's Google accounts.
All testers to open the shared simulator link in their browsers. This is important!
Test the app on browser first using the simulator.
Once tested, use any device with the whitelisted Google Accounts.
US country was required for my use case as I was having Transaction API in my Assistant. I had to also mock my location to the US on mobile for testing US specific features.
See if the above steps help you.
I contacted Google and this is what they said:
You have to copy the link to the notes app, and then click it and in the prompt, choose “Open in Assistant”.
Full text:
Please ensure that the opt-in link is opened in Google Assistant app and not in a browser. At this time, Google Assistant app is only available in USA. For opening an opt-in link in iPhone or any iOS device, please follow the steps below:
1. Download the Assistant App in App Store
2. Log in using the included account for Beta testing
3. Copy the opt-in URL to Notes app
4. Hold press the opt-in link then select 'Open in "Assistant"'. Google Assistant and App page in the Assistant Directory will be displayed.
5. Scroll down the page until you see the "Become a Beta tester" section
6. Click the I'M IN button
7. Test the Action
This does not work for me, probably because I am not in the US. However, the app is of course available here.
I ran into a similar issue with Google Actions/Dialog Flow. Here is how I resolved it...
Share the app from within DialogFlow to the test user
Copy the current DialogFlow URL from the address bar
Launch an Incognito Window
Paste the DialogFlow URL from Step 2 in the address bar
Log into DialogFlow using the test account
At the Standard Google Account Access Prompt Allow the access so your Google Action can talk to DialogFlow.
I couldn't find this documented anywhere and wasted about 8 hours figuring it out.
For me it only worked after I shared with the user the link to test on desktop that look likes: https://console.actions.google.com/project/XXX/simulatorcreate?isDeepLink the one you can get the the console menu on the sharing icon.
I asked him to login with same google email he has opted-in in Google Assistant and
to verify if when mouse over on the devices icon on the menu he would see "Testing on Device: Enabled
You currently are able to test your Actions on all
Assistant devices connected to "xxxx#gmail.com". "
Then he could invoque almost right away the alpha version of the BOT.
All that considering that he has already clicked on the opt-in link, I had added his emails as a Alpha tester and I had also added him as a Viewer on Permissions at the console admin https://console.cloud.google.com/iam-admin.
If you are a developer of the project, the test version is enabled by default on your device. If you want to access the alpha and beta versions, make sure to disable the ‘Testing on device’ option on the Actions Console simulator.
Add users before deploying alpha release
I feel obligated to copy dedman's comment on your question here, since his solution worked for me and is the only one directly addressing the problem at hand: an alpha release is not available to testers you have added after deploying the release.
As stated in question, you first deployed the test version and then added alpha testers. You might have to publish new alpha version "after adding the testers" and then wait till you get "deployed" status on the new alpha release too... – dedman
I was encountering this exact problem with the Alpha release of my Action, i.e. assistant not responding on alpha users devices, even though I had deployed the release, shared the opt-in link with users and had them click on it to opt-in. Deploying a new alpha release after users had clicked the opt-in link solved the problem and the action is now responding correctly for all users.
IAM Viewer status is not mandatory
By the way, I can also confirm your suspicion that "Viewer" permission in IAM is not needed for alpha users to have access to your release - they only need to opt-in before you deploy a new release.

Is there a way to get an email for all bug reports and feedbacks I receive for a published chrome extension?

I have a chrome extension published in chrome store. The problem is that I don't receive any emails or notifications for any feedbacks or bug reports users raise. Is there any option to enable them? The only way to find now is to manually check if there are any feedbacks or open bugs, which is very inefficient.
Web Store provides no way to access feedback (or reviews), with the exception of web scraping those pages.
Here's the (old) feature request for this. It's in limbo for well over a year.

Gmail contextual gadget broken (again)

Link to previous issue: Gmail contextual gadget broken
Yesterday we received a couple of customer complaints regarding our Gmail gadget. They claimed that it had gone missing from their account. This morning, several of our employees have reported the same although, this isn't happening for everyone.
We haven't made any changes to the gadget and since it loads for some, I don't think this was caused by us.
What happens:
The window of the contextual gadget does not appear in the main Gmail interface
The window of the contextual gadget does not appear when opening an email in a new window (shift + click). This differs from when this happened previously.
We've also contacted Google and they have responded that they are looking into the issue. We've also seen that the shift-click to open an email in a new window doesn't work as a work around this time.
The last time this happened our monitoring showed that about 10% of users lost their access to the gadget per-day. We seeing a similar drop off in activity this time around.
Here are the details of the response I received from Google for this issue
Thank you for contacting Google for Work Support. I understand that
that you Gmail Contextual Gadgets have disappeared again from the
Gmail web interface.
I notice there are other user reporting a similar behavior hence he
have requested an update from our Eng team and I am currently waiting
for their response. As soon as I have an official response, I will be
contacting you back directly with the next steps.
Also I notice you mentioned that the previous workaround is no longer
working. Previously the workaround provided was to press "Shift" and
then click on the email. The email will be opened in a new window and
then the gadgets should be displayed. Can you please confirm if the
above workaround is working or not?
I’ll keep this case open while I wait for your reply. If you have any
other questions or additional comments, don’t hesitate to reply and
I'll be happy to continue helping you.
Sincerely,
Wilmer Google for Work Support
Here is the latest update from Google
As before this issue appears to be UI based as opposed to any problem with the Contextual Gadget API itself, we've gathered some troubleshooting information from affected test environments and are working on identifying a clear root cause and then remedying the behaviour at the moment.
There isn't any further you need to do on your end, I'll update you as I learn of any changes in the status of this behaviour.
Regards,
Patrick

Resources