Swagger /admin/users/{username} returns 422 Error: Unprocessable Entity

[rscataran]

Gitea Version

1.15.3 built with GNU Make 4.1, go1.16.8 : bindata, sqlite, sqlite_unlock_notify

Git Version

No response

Operating System

Windows 10

How are you running Gitea?

a command-line

Database

SQLite

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Description

When using the web Api /api/swagger
PATCH ​/admin​/users​/{username} Edit an existing user
results in 422 Error: Unprocessable Entity

I can confirm that the token is working because GET ​/admin​/users List all users is working as expected.

Also, user 034732 exists on the list generated by /admin/users

I am using the sample model provided by swagger on PATCH ​/admin​/users​/{username} Edit an existing user.
I just supplied the username of user to edit = 034732

[rscataran]

Screenshots

[rscataran]

Additional note:

I tested the same scenario using Gitea API. 1.14.7 [ Base URL: /api/v1 ]
and PATCH ​/admin​/users​/{username} Edit an existing user works correctly.

[pricly-yellow]

Maybe it intentional? Visibility parameters may be only "public", "limited", "private" others values return 422

[techknowlogick]

What is the content of what you are trying to send via PATCH?

[pricly-yellow]

I will try to send only required field, step by step put additional fields, error only returned if "visibility" field not have valid values. Also check POST /admin​/users​ - it behave same way.

[bturmann]

Hi,
I can confirm the issue. Changing a user via api is producing error 422. In my case, it is even worse, because the response is always error 422, even if "visibility" field is set with a valid string value.

On a test installation of gitea 1.15.3 with PostgreSQL 11 running on Debian 10 Buster I am trying to change a user with following path:

{
"active": true,
"admin": false,
"allow_create_organization": true,
"allow_git_hook": true,
"allow_import_local": true,
"description": "string",
"email": "[email protected]",
"full_name": "string",
"location": "string",
"login_name": "zzuser",
"max_repo_creation": 0,
"must_change_password": false,
"password": "unsafe",
"prohibit_login": false,
"restricted": false,
"source_id": 0,
"visibility": "public",
"website": "example.com"
}

Up to version 1.14.7 all is working fine. I will test with versions between 1.14.7 and 1.15.3 and report back the results.

[bturmann]

Tests with all 1.15.x versions (including -rc1, -rc2 and -rc3) show same Error 422 "Unprocessable Entity". All tests were done in a consistent way with the same data by using an ansible playbook.

Means, the issue started with 1.15.0-rc1. Last known good version is 1.14.7.

With the current status and error message it is very hard to debug. You would have to try with brute force methods. I would suggest improving the API error message and show which field is not accepted.

Hope that helps.
Regards

[Gusted]

Hi!

I gave this issue a go and I wasn't able to reproduce this - the 422 error only should happen on wrong requests format(e.g. sending json data but not the correct Content-Type header).

With the current status and error message it is very hard to debug. You would have to try with brute force methods. I would suggest improving the API error message and show which field is not accepted.

See #17750

[pintoflager]

This bit me as well with rootless docker image v. 1.15.6 and ansible setup.
Following worked:

- name: Finalize system user account setup through API
  ansible.builtin.uri:
    method: PATCH
    url: "https://{{ gitea_host }}.{{ domain }}/api/v1/admin/users/{{ system_user }}"
    body_format: json
    headers:
      accept: application/json
      Content-Type: application/json
      Authorization: "token {{ (lookup('file', gitea_resources + '/token_' + gitea_system_user + '.json') | from_json ).sha1 }}"
    body: {
      "description": "Gitea system user account created with a script",
      "full_name": "{{ registered_org }} system administrator",
      "login_name": "{{ gitea_system_user }}",
      "source_id": 0,
      "visibility": "private"
    }
    validate_certs: false
    status_code: 200

[bturmann]

Finally, after extensive trial and error, I found the issue: With versions 1.15.x and 1.16.x the user field "website" cannot be updated through the API. As soon as you remove the field "website" all is working as expected.

I tried different content for "website", e.g. "", "string", "example.com", "www.example.com" or even "https://www.example.com", but none of those were accepted. In all cases I got the same error message:
{
"message": "Url",
"url": "http://gitea.example.com:80/api/swagger"
}

Example json causing error:
{
"active": true,
"admin": false,
"allow_create_organization": true,
"allow_git_hook": true,
"allow_import_local": true,
"description": "ci user",
"email": "[email protected]",
"full_name": "full username",
"location": "string",
"login_name": "jenkins",
"max_repo_creation": 0,
"must_change_password": false,
"prohibit_login": true,
"restricted": true,
"source_id": 0,
"website": "example.com",
"visibility": "public"
}

Example json OK (only difference is "website" is omitted):
{
"active": true,
"admin": false,
"allow_create_organization": true,
"allow_git_hook": true,
"allow_import_local": true,
"description": "ci user",
"email": "[email protected]",
"full_name": "full username",
"location": "string",
"login_name": "jenkins",
"max_repo_creation": 0,
"must_change_password": false,
"prohibit_login": true,
"restricted": true,
"source_id": 0,
"visibility": "public"
}

@rscataran, please test again without providing the field "website" and confirm your results.

Thanks
Berni

[rscataran]

This is great! Thank you for your tests.

I have tested it with the current version 1.16.2 and it works as stated. omitting the "website" on the json results in 200 OK and when I tried putting a value on "website" error 422 resulted.

I also tried this on the latest 1.15.10 version and the same results are produced. When "website" parameter in json is omitted (200OK).

I'll close this issue since I don't intend to change the website of the user over API for the time being. But this feature maybe needed in the future, so this thread will be a useful reference.

Cheers!