Chrome Web Store API - Stuck in the early stages

[Robbi]

Looking forward to some positive feedback regarding this thread: THREAD LINK

I'm back here to ask another question.

I would like to attempt to update an extension via the Chrome Web Store API.

From the documentation available at this address : docs

it would seem possible to manage the update through cUrl commands.

Well, after:

• having downloaded the cUrl program (for windows)
• creating a project in Google cloud
• enabling the related API
• getting the "CLIENT ID" and the "CLIENT SECRET"
• getting the "CODE"

I'm stuck in the phase to get the ACCESS TOKEN.

The command is the one shown at the middle of the documentation page, that is:

curl "https://accounts.google.com/o/oauth2/token" -d \

"client_id=$CLIENT_ID&client_secret=$ CLIENT_SECRET&code=$CODE&grant_type=authorization_code&redirect_uri=urn:ietf:wg:oauth:2.0:oob"

the documentation says I should get a token in JSON format, but instead I get the error:

{"error": "invalid_grant", "error_description": "Bad Request"}

Anyone have some experience on this subject?

Thank you.

[Erek Speed]

I've successfully setup Chrome Web Store API to publish and honestly it's a cat and mouse game until you get to your first success.

In this case, I just googled your error and you can find many blogs about it (example) so you should just do standard troubleshooting until it's fixed.

Right now, you're problem isn't chrome extension related since this is a problem for all Google APIs but that also means there's a ton of resources out there to help!

Good luck!

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/e85cb0a5-abee-4a64-91ed-e1fdf65ae8a5n%40chromium.org.

[Robbi]

Ok thank you Erek.

I had done some research on the net, but the site you've just suggested I hadn't intercepted.

Tonight I calmly read it carefully; I hope it brings me to an enlightenment.

The next step I haven't had a way to test yet (because I'm stuck to the token) will be to attach the extension's zipped package to the next cUrl command.

In the specification it is not clear if it needs to indicate a physical path on the PC or if I have to pass that file in some encoded version (i.g. base64).

[Robbi]

Well, I read the article with attention (which would seem centered on the server-2-server exchange, which is not my case).

It was very helpful to me anyway.

Now I was able to generate the access token along with the refresh token.

I solved the grant issue synchronizing the PC clock (I wouldn't have staked a cent on it!).

Now I wanted to do a simple thing like get the information of an already published extension.

Here the documentation is objectively quite a bit messed up.

In fact, the cUrl command syntax for getting the object is not described.

At the bottom of the page: https://developer.chrome.com/docs/webstore/using_webstore_api/

it is describes the GET command for "Checking the upload status of an item".

Assuming the syntax could be adaptable...

I've copied the cUrl command but changing the endpoint to:  "https://www.googleapis.com/chromewebstore/v1.1/items/ <extension_id>"

This is the command I run on DOS shell:

curl -H "Authorization: Bearer  xxxxxACCESS_TOKENxxxxxx"
-H "x-goog-api-version: 2"
-H "Content-Length: 0"
-H "Expect:"
-X GET -v https://www.googleapis.com/chromewebstore/v1.1/items/ojlfeplffbmkdibaelofhhhmplajjmmj

And this is the error message I got

{
  "error": {
    "code": 403,
    "message": "Forbidden",
    "errors": [
      {
        "message": "Forbidden",
        "domain": "global",
        "reason": "forbidden"
      }
    ]
  }
}

I've also tried the same commad with the refresh token and the error messsge this time is been:

{
  "error": {
    "code": 401,
    "message": "Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.",
    "errors": [
      {
        "message": "Invalid Credentials",
        "domain": "global",
        "reason": "authError",
        "location": "Authorization",
        "locationType": "header"
      }
    ],
    "status": "UNAUTHENTICATED"
  }
}

In short, I can no longer go on.

if anyone has any notes to pass to me I would be very grateful.

[Erek Speed]

Glad you got further. As you saw, Google Auth is not specific to chrome extensions and thus you you can access many more resources than are available for Chrome extension developers.

Of course, the error message isn't very useful but I can suggest two things that might be the cause:

1. When you created the code (entering auth URL in browser and clicking 'Accept' before issuing curl command), did you make sure you were logged in to Google with the same gmail account that owns the extension?

2. During that same step did you ensure the scope was accurate and the permission screen mentioned access to your chrome extensions.

I know these were covered in the instructions you read already but since the error is Forbidden it implies that the access token you provided does not have permission to make the API call.

A final thing to check (I can't remember if it leads to Forbidden error) is to ensure that you actually enabled the chrome API in your cloud project. You said you did but I did experience one problem where even after I thought I had enabled it, it wasn't enabled and I had to go back and redo that step.

Good luck!

[Robbi]

Hi everybody,

I assumed the cUrl command for "Checking the upload status of an item", since it used the GET method, was editable by changing the endpoint to make it "point" to the API's "get" command endpoint. (to get extension simple info)

I was wrong, because both "GET," and "CHECK ..." want the PROJECTION parameter set to DRAFT (in querystring).

In fact there is a small call in a cell that says to set this parameter, but if you go into the detail of the command you can read that the parameters are optional (obviously PROJECTION is not)

Now I have managed to do both the GET and the CHECH.

It's a cat and mouse game @Erek, you was right!

Next step: Now I would like to attempt to update an extension. (it seems that creating a new item is now impossible since these APIs do not support the insertion and \ or modification of metadata (such as description etc.)

Then I focus on "Uploading a package to update an existing store item" LINK

In the command description (this time present) at a certain point we read a placeholder named $FILE_NAME. (the zip archive to update the extension, I suppose)

How should I indicate this parameter?

Is it a path on my PC that I have to feed to the cURL command or is it something more complex?

Thank you

[Teddy]

On Jul 7, 2021, at 12:06 PM -0700, Robbi <rob...@gmail.com> wrote:
>How should I indicate this parameter?
>Is it a path on my PC that I have to feed to the cURL command or is it
>something more complex?

Yes, it can be as simple as the path to a local file.

From the Curl manual page (https://curl.se/docs/manpage.html):

> -T, --upload-file <file>
> This transfers the specified local file to the remote URL. …

--










*"This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify the
sender immediately"*

[Robbi]

Thank you @Teddy,

I'm almost ready to update my extension.

This weekend I will try to run this cUrl command.

However after all these attempts I have (almost) come to the conclusion that these APIs have no "reason d'etre".

In fact in my next update I wanted to add a hosts in the permissions of the manifest file.

Surely with a manifest like this the update would be denied because for each new permission added you have to add a couple of lines of explanations.

These lines would be nothing but metadata, and metadata is not yet supported.

I repeat, the usefulness of these APIs is close to zero :-(

[Erek Speed]

Certainly metadata updates would be appreciated but for me at least it's been great to be able to publish extensions from Github automatically after merges.

One thing I did experiment with is that you can make metadata updates on the website (creating a draft waiting to be published) and then when you send the publish command via the API it will publish the waiting draft together with the new extension payload.

It still adds a manual step but given how seldom I update the metadata it's not a show stopper.

[Robbi]

Thanks @Erek and @Teddy  for all your answers.

The online dashboard would have been enough for me and I also find it pleasant.

I got interested in the APIs right after the release that Big G would introduce 2FA to access the dashboard.

Basically, as I wrote here I do not agree at all, that someone imposes something on me and that for this I have to get my hands on my wallet or worse share a private data such as my mobile number.

If they do not add a valid alternative it will mean that I will get a cheapest sim card (such as those for tourists) and used that sim only for this purpose or I will be called on a office desk phone so that they cannot associate the number to my person.