Incoming API Requests for Gerrit and CORS

[Fábio Almeida]

Hello all,

I've been trying to implement a "widget" in an internal service (web based), which displays live information about Change Requests from Gerrit. Naturally, the CORS policies get applied and the requests get blocked by Gerrit (while using basic authentication in the headers of the request).

As far I can understand I could:

1. Setup Gerrit to allow that origin by configuring site.allowOriginRegex.
2. Setup a reverse proxy in front of Gerrit to do, basically, the same as in option 1.

However, when browsing Gerrit's documentation, I came across a section that made me believe there is a third option: access tokens.

Gerrit Code Review - REST API (googlesource.com)

The relevant text is this: "Alternatively applications can use access_token in the URL (see above) to authorize requests. Mutations sent as POST with a request content type of text/plain can skip CORS preflight."

As I understand it, if I provide the correct parameter on the request (the access token), I should be able to "bypass" the CORS policy (i.e., Gerrit will not block my cross-origin request), or am I wrong in my interpretation?

Would anyone advice against such a method, if supported? Why?
I myself can see the potential danger of getting the token "stolen" and reused in unauthorized services, while configuring Gerrit to accept CORS from my application as being "more secure". But alas, I'm no expert.

Additionally, where am I supposed to get those access tokens?
I haven't found any more references to these tokens anywhere in the documentation nor the world wide web...

I can always go with options 1 or 2, but I'd like to understand if this really is a possibility, or if I'm reading too much into the documentation.

Thank you in advance, for any help any of you can provide,

Fábio Almeida

[Ben Rohlfs]

On Mon, 29 Jan 2024 at 14:51, Fábio Almeida <fabio....@siscog.pt> wrote:

Hello all,

I've been trying to implement a "widget" in an internal service (web based), which displays live information about Change Requests from Gerrit. Naturally, the CORS policies get applied and the requests get blocked by Gerrit (while using basic authentication in the headers of the request).

As far I can understand I could:

1. Setup Gerrit to allow that origin by configuring site.allowOriginRegex.
2. Setup a reverse proxy in front of Gerrit to do, basically, the same as in option 1.

However, when browsing Gerrit's documentation, I came across a section that made me believe there is a third option: access tokens.

Gerrit Code Review - REST API (googlesource.com)

The relevant text is this: "Alternatively applications can use access_token in the URL (see above) to authorize requests. Mutations sent as POST with a request content type of text/plain can skip CORS preflight."

As I understand it, if I provide the correct parameter on the request (the access token), I should be able to "bypass" the CORS policy (i.e., Gerrit will not block my cross-origin request), or am I wrong in my interpretation?

Would anyone advice against such a method, if supported? Why?
I myself can see the potential danger of getting the token "stolen" and reused in unauthorized services, while configuring Gerrit to accept CORS from my application as being "more secure". But alas, I'm no expert.

I would go for the simpler and better documented solution, which is using site.allowOriginRegex config.

Additionally, where am I supposed to get those access tokens?
I haven't found any more references to these tokens anywhere in the documentation nor the world wide web...

I think this is the access token that can be used: https://gerrit-review.googlesource.com/Documentation/rest-api-accounts.html#get-oauth-token

Here is the implementation, if you want to look deeper:

https://cs.opensource.google/gerrit/gerrit/gerrit/+/master:java/com/google/gerrit/httpd/restapi/CorsResponder.java

HTH Ben

 

I can always go with options 1 or 2, but I'd like to understand if this really is a possibility, or if I'm reading too much into the documentation.

Thank you in advance, for any help any of you can provide,

Fábio Almeida

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/96b10d4b-327d-4aad-a129-2d0fddd01c2fn%40googlegroups.com.

[Fábio Almeida]

Thank you for your reply.

I also find it sensible to use the site.allowOriginRegex configuration.

Best regards,
Fábio

[Fábio Almeida]

Good morning,

I found a weird behavior related to this CORS processing by Gerrit, which I'd like to validate if it is a bug or not.

After implementing the site.allowOriginRegex configuration I started testing and still got the request blocked by the CORS policy. It took me an embarrassing amount of time, but I think I understand what is happening.

The CORS pre-flight request (an OPTIONS request on the same endpoint as the original request) gets blocked with a 401 Unauthorized response, which the browser interprets as a blocked CORS, naturally. This happens on all endpoints that require authorization, however, not on those that don't require it.

From what I understand, and per the documentation, CORS pre-flight requests are not required (and should not) send client credentials to the server (event when forcing the fetch() API to include the said credentials). However, Gerrit is responding with a 401 Unauthorized in these cases, seemingly requiring the passing of credentials headers in the request.

Is this a bug on Gerrit's site?
I've searched the issue tracker but found no relevant issue.

The two examples of accessing the changes/ API and the home of the server:

1. The blocked OPTIONS request on changes/
   
   
2. The passed OPTIONS request on /
   
   

Best regards,
Fábio

[Fábio Almeida]

Hello,

Just as a conclusion to this matter, I ended up setting up my reverse proxy to directly answer CORS pre-flight requests without contacting Gerrit, which was, in all cases I could exercise, answering with a 401 Unauthorized response.

Seems to work just fine.

Best regards,

Fábio