Skip to content

CLI cannot handle server response #2618

New issue
New issue
Closed as not planned
Closed as not planned
CLI cannot handle server response#2618
Assignees
nejch
Labels
need infostale

Description

@twil69
twil69
opened on Jul 18, 2023

Description of the problem, including code/CLI snippet

gitlab -c ./gitlab-cli.cfg project-merge-request get --iid 98765 --project-id 12345

with config file content being

[global]
default = foo
ssl_verify = False
timeout = 5
api_version = 4

[foo]
url=https://some-project.url
private_token=some-token-here

results in

Attempted to initialize RESTObject with a non-dictionary value: <Response [200]>
This likely indicates an incorrect or malformed server response.

Expected Behavior

Since I can successfully interact with the same server programmatically from Python (i.e. I am getting a valid server JSON response) I suspect this is a problem of the CLI.
The server response is 200 this typically indicates OK. So it will have sent some payload back.
I expect identical behaviour of package and CLI.

Actual Behavior

Specifications

  • python-gitlab version: 3.15.0
  • API version you are using (v3/v4): v4
  • Gitlab server version (or gitlab.com): 14.9.5

Activity

  1. stdedos commented on Mar 6, 2024

    @stdedos
    stdedos
    on Mar 6, 2024
    Contributor

    Apologies for the "necrobump" and the @nejch -bump 😅

    I am having the same issue in gitlab --version 4.4.0.

    $ gitlab --debug project-merge-request-discussion list --project-id ./. --mr-iid 14254 
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): gitlab.....com:443
DEBUG:http.client:send: b'GET /-/profile/personal_access_tokens/api/v4/user HTTP/1.1\r\nHost: gitlab.....com\r\nUser-Agent: python-gitlab/4.4.0\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nConnection: keep-alive\r\nContent-type: application/json\r\nPRIVATE-TOKEN: [MASKED]\r\n\r\n'
DEBUG:http.client:reply: 'HTTP/1.1 302 Found\r\n'
DEBUG:http.client:header: Server: nginx
DEBUG:http.client:header: Date: Wed, 06 Mar 2024 10:15:56 GMT
DEBUG:http.client:header: Content-Type: text/html; charset=utf-8
DEBUG:http.client:header: Content-Length: 113
DEBUG:http.client:header: Connection: keep-alive
DEBUG:http.client:header: Cache-Control: no-cache
DEBUG:http.client:header: Content-Security-Policy: 
DEBUG:http.client:header: Location: https://gitlab.....com/users/sign_in
DEBUG:http.client:header: Permissions-Policy: interest-cohort=()
DEBUG:http.client:header: Set-Cookie: _gitlab_session=123; path=/; expires=Wed, 06 Mar 2024 12:15:56 GMT; secure; HttpOnly; SameSite=None
DEBUG:http.client:header: X-Content-Type-Options: nosniff
DEBUG:http.client:header: X-Download-Options: noopen
DEBUG:http.client:header: X-Frame-Options: SAMEORIGIN
DEBUG:http.client:header: X-Permitted-Cross-Domain-Policies: none
DEBUG:http.client:header: X-Request-Id: 01HR9M6EQ612FW242WQ9R3Q31B
DEBUG:http.client:header: X-Runtime: 0.036455
DEBUG:http.client:header: X-Ua-Compatible: IE=edge
DEBUG:http.client:header: X-Xss-Protection: 1; mode=block
DEBUG:http.client:header: Strict-Transport-Security: max-age=63072000
DEBUG:http.client:header: Referrer-Policy: strict-origin-when-cross-origin
DEBUG:urllib3.connectionpool:https://gitlab.....com:443 "GET /-/profile/personal_access_tokens/api/v4/user HTTP/1.1" 302 113
DEBUG:http.client:send: b'GET /users/sign_in HTTP/1.1\r\nHost: gitlab.....com\r\nUser-Agent: python-gitlab/4.4.0\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nConnection: keep-alive\r\nPRIVATE-TOKEN: [MASKED]\r\nCookie: _gitlab_session=123\r\n\r\n'
DEBUG:http.client:reply: 'HTTP/1.1 200 OK\r\n'
DEBUG:http.client:header: Server: nginx
DEBUG:http.client:header: Date: Wed, 06 Mar 2024 10:15:57 GMT
DEBUG:http.client:header: Content-Type: text/html; charset=utf-8
DEBUG:http.client:header: Transfer-Encoding: chunked
DEBUG:http.client:header: Connection: keep-alive
DEBUG:http.client:header: Vary: Accept-Encoding
DEBUG:http.client:header: Cache-Control: max-age=0, private, must-revalidate
DEBUG:http.client:header: Content-Security-Policy: 
DEBUG:http.client:header: Etag: W/"284a8b1c3b1ef3b933248c22518c7867"
DEBUG:http.client:header: Permissions-Policy: interest-cohort=()
DEBUG:http.client:header: Set-Cookie: preferred_language=en; path=/; Secure; SameSite=None
DEBUG:http.client:header: Set-Cookie: _gitlab_session=123; path=/; expires=Wed, 06 Mar 2024 12:15:57 GMT; secure; HttpOnly; SameSite=None
DEBUG:http.client:header: Vary: Accept
DEBUG:http.client:header: X-Content-Type-Options: nosniff
DEBUG:http.client:header: X-Download-Options: noopen
DEBUG:http.client:header: X-Frame-Options: SAMEORIGIN
DEBUG:http.client:header: X-Permitted-Cross-Domain-Policies: none
DEBUG:http.client:header: X-Request-Id: 01HR9M6ESETMSCH66NRRVZNX9Q
DEBUG:http.client:header: X-Runtime: 0.064135
DEBUG:http.client:header: X-Ua-Compatible: IE=edge
DEBUG:http.client:header: X-Xss-Protection: 1; mode=block
DEBUG:http.client:header: Strict-Transport-Security: max-age=63072000
DEBUG:http.client:header: Referrer-Policy: strict-origin-when-cross-origin
DEBUG:http.client:header: Content-Encoding: gzip
DEBUG:urllib3.connectionpool:https://gitlab.....com:443 "GET /users/sign_in HTTP/1.1" 200 None
Attempted to initialize RESTObject with a non-dictionary value: <Response [200]>
This likely indicates an incorrect or malformed server response.

    idk why would I need to sign_in 😕 private_token = helper: does return the correct token

    Any ideas?

  2. nejch commented on Mar 6, 2024

    @nejch
    nejch
    on Mar 6, 2024
    Member

    @stdedos in your case, you seem to have the wrong base URL. /-/profile/personal_access_tokens/api/v4/user in the initial GET call looks suspicious as that's a web endpoint and not for the v4 API. did you make sure it's just set to https://gitlab.com or left out (maybe there's an environment variable is interfering)?

  3. nejch commented on Mar 6, 2024

    @nejch
    nejch
    on Mar 6, 2024
    Member

    And I suspect the same thing might be happening in the original post, but our CLI might not be the most informative with the malformed response error (e.g. if it's returning some HTML because the user hits the web browser URL instead of the API endpoints).

  4. stdedos commented on Mar 6, 2024

    @stdedos
    stdedos
    on Mar 6, 2024
    Contributor

    Yeap 😕 That's it

    Can you please make gitlab.Gitlab a bit more strict it what it accepts? And/or check early if "it's valid" or not?

    ... do you want a new issue, or re-use this one?

  5. nejch commented on Mar 6, 2024

    @nejch
    nejch
    on Mar 6, 2024
    Member

    a bit more strict it what it accepts? And/or check early if "it's valid" or not?

    If you mean the URLs, I don't think we can as people can serve GitLab at arbitrary endpoints (e.g. https://company.com/my-gitlab, https://company.com/apps/-/gitlab/ - silly example but you get the idea). So it's hard to tell whether a URL is a GitLab base URL or a project URL (which shouldn't be used).

    We check if we can authenticate using gl.auth() which I think should already fail here. I'd say best to expose a bit more info if the returned object is a Response perhaps?

  6. stdedos commented on Mar 6, 2024

    @stdedos
    stdedos
    on Mar 6, 2024
    Contributor

    So it's hard to tell whether a URL is a GitLab base URL or a project URL (which shouldn't be used).

    Yeah, I have done that mistake multiple times 😅

    I'd say best to expose a bit more info if the returned object is a Response perhaps?

    Sure, but - I have no idea what. That obviously looks wrong:

    DEBUG:http.client:send: b'GET /users/sign_in HTTP/1.1\r\nHost: gitlab.....com\r\nUser-Agent: python-gitlab/4.4.0\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nConnection: keep-alive\r\nPRIVATE-TOKEN: [MASKED]\r\nCookie: _gitlab_session=123\r\n\r\n'
DEBUG:http.client:reply: 'HTTP/1.1 200 OK\r\n'

    but, in the context of

    DEBUG:http.client:send: b'GET /-/profile/personal_access_tokens/api/v4/user HTTP/1.1\r\nHost: gitlab.....com\r\nUser-Agent: python-gitlab/4.4.0\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nConnection: keep-alive\r\nContent-type: application/json\r\nPRIVATE-TOKEN: [MASKED]\r\n\r\n'
DEBUG:http.client:reply: 'HTTP/1.1 302 Found\r\n'

    "it's not exactly wrong".

  7. JohnVillalovos
    added
    stale
    on May 15, 2024
  8. JohnVillalovos
    added
    need info
    stale
    and removed
    stale
    on Jul 10, 2024
  9. JohnVillalovos
    added a commit that references this issue on Jul 12, 2024

    chore(ci): specify name of "stale" label

    21102b6
  10. nejch
    added a commit that references this issue on Jul 12, 2024

    chore(ci): specify name of "stale" label

    44f62c4

  11. github-actions commented on Jul 28, 2024

    @github-actions
    github-actionsBot
    on Jul 28, 2024 – with GitHub Actions

    This issue was closed because it has been marked stale for 15 days with no activity. If this issue is still valid, please re-open.

  12. github-actions
    closed this as not plannedon Jul 28, 2024

  13. stdedos commented on Jul 28, 2024

    @stdedos
    stdedos
    on Jul 28, 2024
    Contributor

    @nejch Do you think that this should be re-opened? TIA

  14. nejch
    self-assigned this
    on Jul 28, 2024
  15. nejch
    reopened this on Jul 28, 2024
  16. github-actions
    removed
    stale
    on Jul 29, 2024

  17. github-actions commented on Sep 27, 2024

    @github-actions
    github-actionsBot
    on Sep 27, 2024 – with GitHub Actions

    This issue was marked stale because it has been open 60 days with no activity. Please remove the stale label or comment on this issue. Otherwise, it will be closed in 15 days.

  18. github-actions
    added
    stale
    on Sep 27, 2024

  19. github-actions commented on Oct 13, 2024

    @github-actions
    github-actionsBot
    on Oct 13, 2024 – with GitHub Actions

    This issue was closed because it has been marked stale for 15 days with no activity. If this issue is still valid, please re-open.

  20. github-actions
    closed this as not plannedon Oct 13, 2024

  21. stdedos commented on Oct 13, 2024

    @stdedos
    stdedos
    on Oct 13, 2024
    Contributor

    #NotStale? 😕

  22. github-actions
    locked as resolved and limited conversation to collaborators on Oct 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

need infostale

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions