github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-22 06:24:14 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Consider relaxing access constraints on /api/users/{username}/keys #12907

New Issue
Open
opened 2025-11-02 10:24:33 -06:00 by GiteaMirror · 11 comments
GiteaMirror commented 2025-11-02 10:24:33 -06:00
Owner
Copy Link

Originally created by @wiktor-k on GitHub (Apr 24, 2024).

Feature Description

Hi,

I'm building an identity service (similar to https://keyoxide.org but based on SSH keys) and I'm looking for a way to get the keys without tokens with a CORS headers.

Just for the record both GitHub and Gitlab allow unauthenticated, CORS-ok access:

Gitlab:

$ curl -H Origin:http://example.com -i https://gitlab.com/api/v4/users/wiktor/keys
HTTP/2 200 
date: Wed, 24 Apr 2024 10:06:36 GMT
content-type: application/json
content-length: 1761
access-control-allow-methods: GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS
access-control-allow-origin: *
access-control-expose-headers: Link, X-Total, X-Total-Pages, X-Per-Page, X-Page, X-Next-Page, X-Prev-Page, X-Gitlab-Blob-Id, X-Gitlab-Commit-Id, X-Gitlab-Content-Sha256, X-Gitlab-Encoding, X-Gitlab-File-Name, X-Gitlab-File-Path, X-Gitlab-Last-Commit-Id, X-Gitlab-Ref, X-Gitlab-Size
access-control-max-age: 7200
...

[{"id":2938736,"title":"openpgp:0x64CFEBC4","created_at":"2018-12-31T23:22:23.809Z","expires_at":null,"key":"ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC50X67d9QXRVTiVgVhuKO3CbDu76yV85Cp7CRwBVmv5nwEczFweT/p5XdTARjj25PiQRv0YMFIEdrh7LDB/lSgAcoIJptfHSSJzwd6tCMyXtgujtbz47oGhmZAzKvQl8xbxlZnhjxt9tjt9nPU+P1wIBJU7aOqx9k4kX25mP5HXeFZ1qNzPetwh9h5QzB/6f26iu1U004DdR2f27kBnzUNu/bUPLUI5hiFSxSXl6Oy3/y2srCUyQiUtDDD8498PiO+OZWNaz8xvZN2lyJLjy3dDWQP5y1GaEN2Jk5TdAxP/N/fXII/vZuRMFALhWupuLoytdUL7h27fubSnA6rKbJn Wiktor Kwapisiewicz (gitlab.com)","usage_type":"auth_and_signing"},{"id":6553087,"title":"openpgp:0x0529CE0A","created_at":"2021-01-05T07:17:04.934Z","expires_at":null,"key":"ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILHCXBJYlPPkrt2WYyP3SZoMx43lDBB5QALjE762EQlc Wiktor Kwapisiewicz (gitlab.com)","usage_type":"auth_and_signing"},{"id":9644651,"title":"/usr/lib/pkcs11/libtpm2_pkcs11.so.0.0.0","created_at":"2022-05-30T10:42:15.495Z","expires_at":null,"key":"ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDQv2RJtGurpNLWyiGz9sSuX8agzV98gHW2ZG/7vFkIQrPlaYsd/OH1z7BZNeCHs5vcoq6c2Eh5s6a0vcH4n181TKfjgpbq4t7OFNygWBJplXIZvIlsY//UCxfp5ZdKWJfrYUu/0HeEv5r/7ZcpwF/omC97aM0ipmAeQ8QEGLfgGW427ATa/r2SFwK/4h0C+BTUnMj/YC/4KI/MPWA6x7RdAw+RbVjZd4kT2ZPXcUdruSqDQ4vSP/b8gERv1IjWUn+HHteRJgR2SwNmsuuT/Ko3FRFfXxXPV2yMEvUY2+DoU781VhZJl0aqpW5bIhlK5VE5rGvmMuE5S7XwYDM9V0Wl Wiktor Kwapisiewicz (gitlab.com)","usage_type":"auth_and_signing"},{"id":9713501,"title":"tpm@radon","created_at":"2022-06-09T19:13:11.340Z","expires_at":null,"key":"ecdsa-sha2-nistp384 AAAAE2VjZHNhLXNoYTItbmlzdHAzODQAAAAIbmlzdHAzODQAAABhBButvOpt5qRRPazVFSfV6a4A33eXtlVkXL7x4PHr2zryw1wGb7tzpuSTZKabJaTlSZP/Jpva2caGNNtoNbXVDisOsiS4/wSa3AJ2/PmxOcpv/lZcpCynKq4zDeogo+FxrA== Wiktor Kwapisiewicz (gitlab.com)","usage_type":"auth_and_signing"}]

GitHub:

$ curl -i https://api.github.com/users/castedo/ssh_signing_keys
HTTP/2 200 
server: GitHub.com
date: Mon, 16 Oct 2023 09:59:53 GMT
...
access-control-allow-origin: *
strict-transport-security: max-age=31536000; includeSubdomains; preload

[
  {
    "id": 164688,
    "key": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIQdQut465od3lkVyVW6038PcD/wSGX/2ij3RcQZTAqt",
    "title": "ellersign2023",
    "created_at": "2023-09-20T12:05:12.685Z"
  }
]

Compare that with Gitea, that returns 401 (unauthenticated):

$ curl 'https://gitea.com/api/v1/users/minge/keys'   -H 'accept: application/json' -H Origin:http://example.com -i
HTTP/2 401 
date: Wed, 24 Apr 2024 10:11:56 GMT
content-type: application/json;charset=utf-8
content-length: 70
access-control-allow-origin: *
cache-control: max-age=0, private, must-revalidate, no-transform
server: Caddy
vary: Origin
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN

{"message":"token is required","url":"https://gitea.com/api/swagger"}

Note that the keys are already public via the other endpoint, which sadly is not CORS-enabled:

$ curl https://gitea.com/minge.keys -i
HTTP/2 200 
date: Wed, 24 Apr 2024 10:11:38 GMT
content-type: text/plain;charset=utf-8
content-length: 725
cache-control: max-age=0, private, must-revalidate, no-transform
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCo+x0KpXBUENNLk+VctUICG4+cgN5SsOr+KpUFrAmgKL7ql1Ti86TQK7bp694ciuspkLkT3HyrRiMND2hRUHexK+HHO35KGu8+MEj/yJREhLFOIicqOn0cz1r74V9hMrNYZO/uakBHJ5EDxZ2zVXs+fEtQjQYvOa3PW55vcRTeXXsUN2nRIzEiQMj6dpHdCz+is4iIMV9YiBhuXcvDSmag60fSYe437PZR4usBMTmYWwcdaTnzS4/swlGVGlEpP+xReJRyntt4WnelkphuYbgwe9BM5psWonbPf7r8e/s9lsOAsjgpZaySRlL85YSZlwGnswxLrw9gqTCpRr7KoVcjPPy4x5N5jghhah1DgPf0HrBT5LLkQCT9XJihAPP7qfnQcYzncR2FzHzCoQGdFoQHrz3VK/qRKNLqHe90yyHZGatfBfk/8TWkZ0DOJEl7BYL4vWUv9GuRsX1rxuPIz8ab5Pn2hKBDusFP8Mw6/1WaM1cB4eYIpHQcj+/xAMp9J4Q1oyh98MJUA0PDhTajoHiTsur31fZ7zqnTOOiOMtOhC42vFO5EO36hEqL8NZ1GA4VKK5Yj53CWnYF+OOSyFxMYd2yaqsjNaJ0SaLEaAcqBaYRutnD2ipHJcIatzebUch3RwdU2Sydf67yL/5dzvm9QWbeOV5+Gh1ZpBYj3sqXvYQ==

I think given what others do and the already-public aspect of the keys it would be OK to allow unauthenticated access to https://gitea.com/api/v1/users/{username}/keys and if that sounds OK for you I'm volunteering to implement it.

Screenshots

No response

Originally created by @wiktor-k on GitHub (Apr 24, 2024). ### Feature Description Hi, I'm building an identity service (similar to https://keyoxide.org but based on SSH keys) and I'm looking for a way to get the keys without tokens with a CORS headers. Just for the record both GitHub and Gitlab allow unauthenticated, CORS-ok access: Gitlab: ```sh $ curl -H Origin:http://example.com -i https://gitlab.com/api/v4/users/wiktor/keys HTTP/2 200 date: Wed, 24 Apr 2024 10:06:36 GMT content-type: application/json content-length: 1761 access-control-allow-methods: GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS access-control-allow-origin: * access-control-expose-headers: Link, X-Total, X-Total-Pages, X-Per-Page, X-Page, X-Next-Page, X-Prev-Page, X-Gitlab-Blob-Id, X-Gitlab-Commit-Id, X-Gitlab-Content-Sha256, X-Gitlab-Encoding, X-Gitlab-File-Name, X-Gitlab-File-Path, X-Gitlab-Last-Commit-Id, X-Gitlab-Ref, X-Gitlab-Size access-control-max-age: 7200 ... [{"id":2938736,"title":"openpgp:0x64CFEBC4","created_at":"2018-12-31T23:22:23.809Z","expires_at":null,"key":"ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC50X67d9QXRVTiVgVhuKO3CbDu76yV85Cp7CRwBVmv5nwEczFweT/p5XdTARjj25PiQRv0YMFIEdrh7LDB/lSgAcoIJptfHSSJzwd6tCMyXtgujtbz47oGhmZAzKvQl8xbxlZnhjxt9tjt9nPU+P1wIBJU7aOqx9k4kX25mP5HXeFZ1qNzPetwh9h5QzB/6f26iu1U004DdR2f27kBnzUNu/bUPLUI5hiFSxSXl6Oy3/y2srCUyQiUtDDD8498PiO+OZWNaz8xvZN2lyJLjy3dDWQP5y1GaEN2Jk5TdAxP/N/fXII/vZuRMFALhWupuLoytdUL7h27fubSnA6rKbJn Wiktor Kwapisiewicz (gitlab.com)","usage_type":"auth_and_signing"},{"id":6553087,"title":"openpgp:0x0529CE0A","created_at":"2021-01-05T07:17:04.934Z","expires_at":null,"key":"ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILHCXBJYlPPkrt2WYyP3SZoMx43lDBB5QALjE762EQlc Wiktor Kwapisiewicz (gitlab.com)","usage_type":"auth_and_signing"},{"id":9644651,"title":"/usr/lib/pkcs11/libtpm2_pkcs11.so.0.0.0","created_at":"2022-05-30T10:42:15.495Z","expires_at":null,"key":"ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDQv2RJtGurpNLWyiGz9sSuX8agzV98gHW2ZG/7vFkIQrPlaYsd/OH1z7BZNeCHs5vcoq6c2Eh5s6a0vcH4n181TKfjgpbq4t7OFNygWBJplXIZvIlsY//UCxfp5ZdKWJfrYUu/0HeEv5r/7ZcpwF/omC97aM0ipmAeQ8QEGLfgGW427ATa/r2SFwK/4h0C+BTUnMj/YC/4KI/MPWA6x7RdAw+RbVjZd4kT2ZPXcUdruSqDQ4vSP/b8gERv1IjWUn+HHteRJgR2SwNmsuuT/Ko3FRFfXxXPV2yMEvUY2+DoU781VhZJl0aqpW5bIhlK5VE5rGvmMuE5S7XwYDM9V0Wl Wiktor Kwapisiewicz (gitlab.com)","usage_type":"auth_and_signing"},{"id":9713501,"title":"tpm@radon","created_at":"2022-06-09T19:13:11.340Z","expires_at":null,"key":"ecdsa-sha2-nistp384 AAAAE2VjZHNhLXNoYTItbmlzdHAzODQAAAAIbmlzdHAzODQAAABhBButvOpt5qRRPazVFSfV6a4A33eXtlVkXL7x4PHr2zryw1wGb7tzpuSTZKabJaTlSZP/Jpva2caGNNtoNbXVDisOsiS4/wSa3AJ2/PmxOcpv/lZcpCynKq4zDeogo+FxrA== Wiktor Kwapisiewicz (gitlab.com)","usage_type":"auth_and_signing"}] ``` GitHub: ```sh $ curl -i https://api.github.com/users/castedo/ssh_signing_keys HTTP/2 200 server: GitHub.com date: Mon, 16 Oct 2023 09:59:53 GMT ... access-control-allow-origin: * strict-transport-security: max-age=31536000; includeSubdomains; preload [ { "id": 164688, "key": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIQdQut465od3lkVyVW6038PcD/wSGX/2ij3RcQZTAqt", "title": "ellersign2023", "created_at": "2023-09-20T12:05:12.685Z" } ] ``` Compare that with Gitea, that returns 401 (unauthenticated): ``` $ curl 'https://gitea.com/api/v1/users/minge/keys' -H 'accept: application/json' -H Origin:http://example.com -i HTTP/2 401 date: Wed, 24 Apr 2024 10:11:56 GMT content-type: application/json;charset=utf-8 content-length: 70 access-control-allow-origin: * cache-control: max-age=0, private, must-revalidate, no-transform server: Caddy vary: Origin x-content-type-options: nosniff x-frame-options: SAMEORIGIN {"message":"token is required","url":"https://gitea.com/api/swagger"} ``` Note that the keys are already public via the other endpoint, which sadly is not CORS-enabled: ``` $ curl https://gitea.com/minge.keys -i HTTP/2 200 date: Wed, 24 Apr 2024 10:11:38 GMT content-type: text/plain;charset=utf-8 content-length: 725 cache-control: max-age=0, private, must-revalidate, no-transform x-content-type-options: nosniff x-frame-options: SAMEORIGIN ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCo+x0KpXBUENNLk+VctUICG4+cgN5SsOr+KpUFrAmgKL7ql1Ti86TQK7bp694ciuspkLkT3HyrRiMND2hRUHexK+HHO35KGu8+MEj/yJREhLFOIicqOn0cz1r74V9hMrNYZO/uakBHJ5EDxZ2zVXs+fEtQjQYvOa3PW55vcRTeXXsUN2nRIzEiQMj6dpHdCz+is4iIMV9YiBhuXcvDSmag60fSYe437PZR4usBMTmYWwcdaTnzS4/swlGVGlEpP+xReJRyntt4WnelkphuYbgwe9BM5psWonbPf7r8e/s9lsOAsjgpZaySRlL85YSZlwGnswxLrw9gqTCpRr7KoVcjPPy4x5N5jghhah1DgPf0HrBT5LLkQCT9XJihAPP7qfnQcYzncR2FzHzCoQGdFoQHrz3VK/qRKNLqHe90yyHZGatfBfk/8TWkZ0DOJEl7BYL4vWUv9GuRsX1rxuPIz8ab5Pn2hKBDusFP8Mw6/1WaM1cB4eYIpHQcj+/xAMp9J4Q1oyh98MJUA0PDhTajoHiTsur31fZ7zqnTOOiOMtOhC42vFO5EO36hEqL8NZ1GA4VKK5Yj53CWnYF+OOSyFxMYd2yaqsjNaJ0SaLEaAcqBaYRutnD2ipHJcIatzebUch3RwdU2Sydf67yL/5dzvm9QWbeOV5+Gh1ZpBYj3sqXvYQ== ``` I think given what others do and the already-public aspect of the keys it would be OK to allow unauthenticated access to `https://gitea.com/api/v1/users/{username}/keys` and if that sounds OK for you I'm volunteering to implement it. ### Screenshots _No response_
GiteaMirror added the proposal/acceptedtype/proposal labels 2025-11-02 10:24:33 -06:00
GiteaMirror commented 2025-11-02 10:24:34 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Apr 24, 2024):

/<user>.keys and /<user>.pgp info is okay to expose. API has more metadata that some may consider sensitive like the key's comment.

Ideally you would fetch those in a client that does not require CORS, e.g. in the backend.

@silverwind commented on GitHub (Apr 24, 2024): `/<user>.keys` and `/<user>.pgp` info is okay to expose. API has more metadata that some may consider sensitive like the key's comment. Ideally you would fetch those in a client that does not require CORS, e.g. in the backend.
GiteaMirror commented 2025-11-02 10:24:34 -06:00
Author
Owner
Copy Link

@wiktor-k commented on GitHub (Apr 24, 2024):

Ideally you would fetch those in a client that does not require CORS, e.g. in the backend.

Yes, that's a workaround I could use but the point of my solution is not using any backend services as trusted third parties but doing it all in the browser. This has a couple of benefits: it's easier to self host for others and in general is less complex.

Additionally the JSON endpoint provides structured data, which is also beneficial.

I'm aware that this could be worked around but given other forges already having similar rules I hope implementing unauthenticated access would just be the cleanest solution.

As for the key comment maybe it can be omitted in unauthenticated requests but included in requests with tokens? I'm looking for just the key material and I'm okay with this adjustment (note that other forges just output that, as you can see in my samples above).

@wiktor-k commented on GitHub (Apr 24, 2024): > Ideally you would fetch those in a client that does not require CORS, e.g. in the backend. Yes, that's a workaround I could use but the point of my solution is not using any backend services as trusted third parties but doing it all in the browser. This has a couple of benefits: it's easier to self host for others and in general is less complex. Additionally the JSON endpoint provides structured data, which is also beneficial. I'm aware that this could be worked around but given other forges already having similar rules I hope implementing unauthenticated access would just be the cleanest solution. As for the key comment maybe it can be omitted in unauthenticated requests but included in requests with tokens? I'm looking for just the key material and I'm okay with this adjustment (note that other forges just output that, as you can see in my samples above).
GiteaMirror commented 2025-11-02 10:24:35 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Apr 24, 2024):

As for the key comment maybe it can be omitted in unauthenticated requests but included in requests with tokens? I'm looking for just the key material and I'm okay with this adjustment (note that other forges just output that, as you can see in my samples above).

I guess I would be okay if the non-authenticated API returns the exact format that github does, with the stripped comment. It should be clearly documented that this specific API has a difference whether the request is authenticated or not.

@silverwind commented on GitHub (Apr 24, 2024): > As for the key comment maybe it can be omitted in unauthenticated requests but included in requests with tokens? I'm looking for just the key material and I'm okay with this adjustment (note that other forges just output that, as you can see in my samples above). I guess I would be okay if the non-authenticated API returns the exact format that github does, with the stripped comment. It should be clearly documented that this specific API has a difference whether the request is authenticated or not.
GiteaMirror commented 2025-11-02 10:24:35 -06:00
Author
Owner
Copy Link

@lafriks commented on GitHub (May 28, 2024):

I hope the public does not mean unauthenticated for private instances? 🤔

@lafriks commented on GitHub (May 28, 2024): I hope the public does not mean unauthenticated for private instances? 🤔
GiteaMirror commented 2025-11-02 10:24:35 -06:00
Author
Owner
Copy Link

@wiktor-k commented on GitHub (May 28, 2024):

I hope the public does not mean unauthenticated for private instances? 🤔

It's the same kind of access that is available through the .keys endpoint (but with JSON+CORS):

$ curl https://codeberg.org/lafriks.keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAB+wCwJEbmp2zS0aREkMdUGyfinYTCsb56Cprbr+Oe1WMpsuf0efBUy5ZJ0AIfsfT40elnzyxCpw2m5WlzR1TgpEOMcuB21dqhqA5L10eoWjbMXf5N2fyeKMUguBjuIwemzRj2sIQwAoDY3FWfafrUwwswtbIBkZWT4kiwXwOqsXgzkqGf+w37oP0XhxF+HliN9qwx95RVQa9322ErLlRN4tsJs0qv6XyZGmyWO934ksPCsHXuPwz2iONXUWzf9SeTSJEfQyNup++LqMaXVbTggc+fNzJM5tyDAFLxbMSdVmbey7MAeluWLe5MKlBysFnlE68nXh8aoB11gr+w1+o6DTntbjjUlzpw5yTMnRMVHMOEDcBOv5ABaOU8D7jm45GnFtcH/hnPYecOWP639x7M20QGT4Z/9pN7WVlSyxW2lha2t2oi2Gn+5VEcN5YKsHKW7TyH1mg+miumwwR8Nvq93M7dnncA1+T/w1waJUriYGjYszqMMkhx/HVLo5ySdB2nsn0qkCP1/9RMn+3vVbyCiqeZOodo8iNRrdrwKJss9SH9AwHwodFfaoF0wgYbbGtB6frX1mRB1Z6UMlef4NomuPnXfMJxrrdFcbyyOIQQhzZg1EhoHF8BS5/laqw/DFg2xQ41cAVk8VludwBNeICI0ow+tR4wUyWeoA3cPQ==

(note no authentication tokens passed).

Or maybe I misunderstood your question?

@wiktor-k commented on GitHub (May 28, 2024): > I hope the public does not mean unauthenticated for private instances? 🤔 It's the same kind of access that is available through the `.keys` endpoint (but with JSON+CORS): ``` $ curl https://codeberg.org/lafriks.keys ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAB+wCwJEbmp2zS0aREkMdUGyfinYTCsb56Cprbr+Oe1WMpsuf0efBUy5ZJ0AIfsfT40elnzyxCpw2m5WlzR1TgpEOMcuB21dqhqA5L10eoWjbMXf5N2fyeKMUguBjuIwemzRj2sIQwAoDY3FWfafrUwwswtbIBkZWT4kiwXwOqsXgzkqGf+w37oP0XhxF+HliN9qwx95RVQa9322ErLlRN4tsJs0qv6XyZGmyWO934ksPCsHXuPwz2iONXUWzf9SeTSJEfQyNup++LqMaXVbTggc+fNzJM5tyDAFLxbMSdVmbey7MAeluWLe5MKlBysFnlE68nXh8aoB11gr+w1+o6DTntbjjUlzpw5yTMnRMVHMOEDcBOv5ABaOU8D7jm45GnFtcH/hnPYecOWP639x7M20QGT4Z/9pN7WVlSyxW2lha2t2oi2Gn+5VEcN5YKsHKW7TyH1mg+miumwwR8Nvq93M7dnncA1+T/w1waJUriYGjYszqMMkhx/HVLo5ySdB2nsn0qkCP1/9RMn+3vVbyCiqeZOodo8iNRrdrwKJss9SH9AwHwodFfaoF0wgYbbGtB6frX1mRB1Z6UMlef4NomuPnXfMJxrrdFcbyyOIQQhzZg1EhoHF8BS5/laqw/DFg2xQ41cAVk8VludwBNeICI0ow+tR4wUyWeoA3cPQ== ``` (note no authentication tokens passed). Or maybe I misunderstood your question?
GiteaMirror commented 2025-11-02 10:24:35 -06:00
Author
Owner
Copy Link

@lafriks commented on GitHub (May 28, 2024):

Or maybe I misunderstood your question?

I mean it should be still inaccessible if gitea instance is set to always require authentication (REQUIRE_SIGNIN_VIEW=true)

@lafriks commented on GitHub (May 28, 2024): > Or maybe I misunderstood your question? I mean it should be still inaccessible if gitea instance is set to always require authentication (`REQUIRE_SIGNIN_VIEW=true`)
GiteaMirror commented 2025-11-02 10:24:35 -06:00
Author
Owner
Copy Link

@wiktor-k commented on GitHub (May 28, 2024):

I mean it should be still inaccessible if gitea instance is set to always require authentication (REQUIRE_SIGNIN_VIEW=true)

Yeah, just to be crystal clear: I don't want to relax that. Just provide the same info under the same rules as .keys but in JSON+CORS. Nothing more.

@wiktor-k commented on GitHub (May 28, 2024): > I mean it should be still inaccessible if gitea instance is set to always require authentication (`REQUIRE_SIGNIN_VIEW=true`) Yeah, just to be crystal clear: I *don't* want to relax *that*. Just provide the same info under the same rules as `.keys` but in JSON+CORS. Nothing more.
GiteaMirror commented 2025-11-02 10:24:36 -06:00
Author
Owner
Copy Link

@lafriks commented on GitHub (May 28, 2024):

PR title should be fixed that as it is quite misleading "unauthenticated access"

@lafriks commented on GitHub (May 28, 2024): PR title should be fixed that as it is quite misleading "unauthenticated access"
GiteaMirror commented 2025-11-02 10:24:36 -06:00
Author
Owner
Copy Link

@wiktor-k commented on GitHub (May 28, 2024):

PR title should be fixed that as it is quite misleading "unauthenticated access"

Okay, what do you suggest? .keys is available to users who are not logged in (example above), that's why I used unauthenticated. Is there a better terminology for such an access in Gitea?

@wiktor-k commented on GitHub (May 28, 2024): > PR title should be fixed that as it is quite misleading "unauthenticated access" Okay, what do you suggest? `.keys` is available to users who are not logged in ([example above](https://github.com/go-gitea/gitea/issues/30681#issuecomment-2135477372)), that's why I used `unauthenticated`. Is there a better terminology for such an access in Gitea?
GiteaMirror commented 2025-11-02 10:24:36 -06:00
Author
Owner
Copy Link

@florent4014 commented on GitHub (Oct 3, 2024):

It would be very helpful to be able to allow public access to users' public keys. I've been using Gitlab and Gitea for some time now and i was able to do so in Gitlab (https://gitlab.domain.lan/user.keys).

Maybe put a toggle that each user can freely allow or not.

@florent4014 commented on GitHub (Oct 3, 2024): It would be very helpful to be able to allow public access to users' public keys. I've been using Gitlab and Gitea for some time now and i was able to do so in Gitlab (https://gitlab.domain.lan/user.keys). Maybe put a toggle that each user can freely allow or not.
GiteaMirror commented 2025-11-02 10:24:36 -06:00
Author
Owner
Copy Link

@techknowlogick commented on GitHub (Oct 3, 2024):

@florent4014 I have some good news for you. That is already possible. This is in regards to changes in access to the API endpoint.

@techknowlogick commented on GitHub (Oct 3, 2024): @florent4014 I have some good news for you. That is already possible. This is in regards to changes in access to the API endpoint.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label proposal/accepted type/proposal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#12907
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?