Response code 401 (Unauthorized) in enter credetial stage

[ishifman-nvidia]

Hi

previously we could enter the http token in settings

i regenerated new HTTP token I understand that we should insert it in "Gerrit: enter credentials" during this stage i get an Error: "HTTPError: Response code 401 (Unauthorized)" when i put my URL

steps :

1. Gerrit: enter credentials 2.enter user name and passwrord
2. enter the url

how should i solve it? Thanks

[SanderRonde]

Can you double check whether the token is correct and whether the account is still authenticated?

If so there should be a "copy curl command" buttons somewhere along the credential entereing stage. If you run the curl command in a terminal and still can't authenticate that probably means you've entered the wrong credentials/url or maybe your administrator has disabled the HTTP API.

[ishifman-nvidia]

Can you double check whether the token is correct i generate new token from gerrit server :

i failed in the first step of credential entering stage i assume that the http token step is after the url step, right?

could it be that the url step use old http token ? how can i set new http token in the plugin

account is still authenticated?

how i can i check that the account is still authenticated?

If you run the curl command in a terminal and still can't authenticate that probably means you've entered the wrong credentials/url

can i use curl with the http token ? can you specify which curl is being used in the url stage that cause the 401 error ? I will test that command

[ishifman-nvidia]

issue was updated with steps

[SanderRonde]

Ahhh I think you might be right. The URL check should not be doing an authenticated check and so shouldn't be able to return a 401. Will look into this some time this week!

[ishifman-nvidia]

great Thank you

[SanderRonde]

Looked into it some more, it's only doing a simple get request (code) without any credentials to the provided URL. So if that URL is returning a 401, chances are you're behind some sort of (corporate) proxy that also checks for an additional company cookie before allowing access. Or maybe HTTP access has been disabled entirely. You can check by just running curl --url "your_url" in a terminal

[ishifman-nvidia]

i ran :

curl --url ""

this is the response:

is it match the response expected by plugin?

[SanderRonde]

No that response is not expected and redirects won't be handled by the extension. I guess I could add support for something like this but I have no idea how the redirection scheme is set up so it's kind of hard for me to do so without more info. I think it should work if you just change the URL to be the actual URL (so the one that you've moved to). In this case I think that's https://git-xxxxxx.com/r/# but I'm not too sure. I'm sure your gerrit admin knows more about your specific setup.

[ishifman-nvidia]

after speaking with our admin i understand that our setup assume that all endpoints requests should be authenticated 1) the default url ( curl --url https://git-xxx.yyyyy.com ) redirect to projects endpoint ( https://git-xxx.yyyyy.com/r/#/admin/projects) 2) when accessing an endpoint without authentication (curl --url https://git-xxx.yyyyy.com/r/#/admin/projects ) i get 302 status code that redirect me again to the our org SSO (Single Sign On) page if I understand it correctly from gerrit Docs, rest api projects endpoint can be authenticated, as described in Gerrit authentication section 3) is it possible to allow 3XX Redirection status code at urlStep check in enterBasicCredentials code?

[SanderRonde]

Alright the default endpoint redirecting is not a big issue. This endpoint isn't actually being used.

However endpoints requiring SSO to be reached is an issue. Even if the extension would follow redirects, it would need to log into your SSO provider via an API request which is pretty much impossible. That is unless authenticated API requests (under the /a/ URL) are allowed without authentication. That would allow using of the REST API like normal without SSO.

Or am I misunderstanding and would only following redirects fix this?

[ishifman-nvidia]

Alright the default endpoint redirecting is not a big issue. This endpoint isn't actually being used. However endpoints requiring SSO to be reached is an issue. Even if the extension would follow redirects

i think that allow 302 redirection status will solve the issue i think that the redirection to SSO is done only for requests that are not authenticated

Or am I misunderstanding and would only following redirects fix this?

i think we don't need to follow the redirection at all , as you mentioned, the endpoint in urlStep isn't actually being used. right?

the real validation is done with the authentication (user+http token) in passwordStep->validate step i don't know which endpoint is being requested in passwordStep phase, but i assume this step will pass, because it contains the Authentication credentials

i tested curl with Authentication as described in gerrit Authentication with the following format: curl --url https://git-xxx.yyyyy.com/r/a/accounts//detail --user :

and got the following response:

what is your opinion, can we ignore the redirection in urlStep ?

[SanderRonde]

Hey sorry for the slow response. Indeed you're right that the main URL isn't actually being used. I think the easiest fix is for the test-URL to just be /config/server/version (which is actually being used). That will fix your case without needing to do any SSO.

[SanderRonde]

Fixed in version 1.2.48!

[BaconPancakes]

/config/server/version also requires authentication in our use case. You need to ask for credentials first and then send an auth header as part of the GET request. I've used the REST API with our instance and it works as expected.

[BaconPancakes]

Yeah, it works totally fine if you just bypass the testConnection() check. I went in and edited the extension.js locally and things are totally working now after being able to skip testConnection to enter credentials. GET requests to my gerrit instance work fine in the output window.

Not sure how you want to handle this, but I'd think you want to run the test connection checks a little bit less eagerly.

// this is my hack to bypass test connection to allow me to enter user credentials
testConnection() {
        let e = {
            path: "",
            method: "GET",
            onError: null,
            unauthenticated: !0
        },
            r = {
                path: "r/a/accounts/self",
                method: "GET",
                onError: null
            },
            i = this;
        return {
            get exists() {
                return Promise.resolve(true); // shim this to True
            },
            get authenticated() {
                return Promise.resolve(true); // also shim this to true
            },
            runCurlCommand: s => {
                let o = zo.window.createTerminal("cUrl"),
                    a = this._username && this._password ? ` --user "${this._username}:${this._password}"` : "",
                    u = "",
                    l = this._getCookieJar(r);
                l?.cookieString && (u = ` --cookie "${l.cookieString}"`);
                let f = this._getUrlAndParams(e).url ?? "<no-url>",
                    y = this._getUrlAndParams(r).url ?? "<no-url>",
                    C = `echo "Unauthenticated: " && curl${u} "${f}"`,
                    _ = `echo "Authenticated: " && curl${a}${u} "${y}"`,
                    v = [];
                s.forExists && v.push(C), s.forAuthenticated && v.push(_), o.sendText(v.join(' && echo -e "\\n" && '), !1), o.show()
            }
        }
    }

[SanderRonde]

Hmm I want to understand before I fix this. Is just {host}/config/server/version authenticated? How so? Is this some custom authentication or Gerrit's builtin one?

I could consider adding a "ignore test" button somewhere but ideally that wouldn't be needed

[ishifman-nvidia]

unfortunately, the fix didn't resolve it for me also in our org methodology all Gerrit request are authenticated , including host}/config/server/version therefore i still get the unauthorized response

[SanderRonde]

Changed it to fall back to an authenticated request if the unauthenticated one fails in version 1.2.51