Commit graph

2110 commits

Author SHA1 Message Date
oliverpool b6e81357bd
Add Webhook authorization header (#20926)
_This is a different approach to #20267, I took the liberty of adapting
some parts, see below_

## Context

In some cases, a weebhook endpoint requires some kind of authentication.
The usual way is by sending a static `Authorization` header, with a
given token. For instance:

- Matrix expects a `Bearer <token>` (already implemented, by storing the
header cleartext in the metadata - which is buggy on retry #19872)
- TeamCity #18667
- Gitea instances #20267
- SourceHut https://man.sr.ht/graphql.md#authentication-strategies (this
is my actual personal need :)

## Proposed solution

Add a dedicated encrypt column to the webhook table (instead of storing
it as meta as proposed in #20267), so that it gets available for all
present and future hook types (especially the custom ones #19307).

This would also solve the buggy matrix retry #19872.

As a first step, I would recommend focusing on the backend logic and
improve the frontend at a later stage. For now the UI is a simple
`Authorization` field (which could be later customized with `Bearer` and
`Basic` switches):


![2022-08-23-142911](https://user-images.githubusercontent.com/3864879/186162483-5b721504-eef5-4932-812e-eb96a68494cc.png)

The header name is hard-coded, since I couldn't fine any usecase
justifying otherwise.

## Questions

- What do you think of this approach? @justusbunsi @Gusted @silverwind 
- ~~How are the migrations generated? Do I have to manually create a new
file, or is there a command for that?~~
- ~~I started adding it to the API: should I complete it or should I
drop it? (I don't know how much the API is actually used)~~

## Done as well:

- add a migration for the existing matrix webhooks and remove the
`Authorization` logic there


_Closes #19872_

Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Gusted <williamzijl7@hotmail.com>
Co-authored-by: delvh <dev.lh@web.de>
2022-11-03 20:23:20 +02:00
kolaente 085f717529
feat: notify doers of a merge when automerging (#21553)
I found myself wondering whether a PR I scheduled for automerge was
actually merged. It was, but I didn't receive a mail notification for it
- that makes sense considering I am the doer and usually don't want to
receive such notifications. But ideally I want to receive a notification
when a PR was merged because I scheduled it for automerge.

This PR implements exactly that.

The implementation works, but I wonder if there's a way to avoid passing
the "This PR was automerged" state down so much. I tried solving this
via the database (checking if there's an automerge scheduled for this PR
when sending the notification) but that did not work reliably, probably
because sending the notification happens async and the entry might have
already been deleted. My implementation might be the most
straightforward but maybe not the most elegant.

Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: Lauris BH <lauris@nix.lv>
Co-authored-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
2022-11-03 23:49:00 +08:00
Lunny Xiao 44cc684a50 [skip ci] Updated translations via Crowdin 2022-11-03 00:19:50 +00:00
Gusted 4827f42f56 [skip ci] Updated translations via Crowdin 2022-11-02 00:19:48 +00:00
Gusted c2d2323fc8
Configure update checker on installation page (#21655)
- I recently became aware that this was enabled by-default, I don't
necessary agree with that and this should rather be configured by the
user(this patch does that on the installation page) as it connects to a
homeserver, which I'd prefer to avoid on my instance.


![image](https://user-images.githubusercontent.com/25481501/199260613-a77a1b10-347a-4542-8982-9b9b24dad28c.png)
2022-11-01 19:23:56 +00:00
KN4CK3R 9b3e2c5450 [skip ci] Updated translations via Crowdin 2022-10-31 00:19:34 +00:00
KN4CK3R d33b2d473c [skip ci] Updated licenses and gitignores 2022-10-30 00:19:37 +00:00
Jason Song 434622ab6f [skip ci] Updated translations via Crowdin 2022-10-29 00:19:53 +00:00
mpeter50 2cc7408b98 [skip ci] Updated translations via Crowdin 2022-10-28 00:19:53 +00:00
qwerty287 096aed5c1d [skip ci] Updated translations via Crowdin 2022-10-27 00:21:00 +00:00
techknowlogick 49a4e4555a [skip ci] Updated translations via Crowdin 2022-10-26 00:20:58 +00:00
Yarden Shoham 3bd05172d5 [skip ci] Updated translations via Crowdin 2022-10-25 00:20:58 +00:00
M Hickford 191a74d622
Record OAuth client type at registration (#21316)
The OAuth spec [defines two types of
client](https://datatracker.ietf.org/doc/html/rfc6749#section-2.1),
confidential and public. Previously Gitea assumed all clients to be
confidential.

> OAuth defines two client types, based on their ability to authenticate
securely with the authorization server (i.e., ability to
>   maintain the confidentiality of their client credentials):
>
>   confidential
> Clients capable of maintaining the confidentiality of their
credentials (e.g., client implemented on a secure server with
> restricted access to the client credentials), or capable of secure
client authentication using other means.
>
>   **public
> Clients incapable of maintaining the confidentiality of their
credentials (e.g., clients executing on the device used by the resource
owner, such as an installed native application or a web browser-based
application), and incapable of secure client authentication via any
other means.**
>
> The client type designation is based on the authorization server's
definition of secure authentication and its acceptable exposure levels
of client credentials. The authorization server SHOULD NOT make
assumptions about the client type.

 https://datatracker.ietf.org/doc/html/rfc8252#section-8.4

> Authorization servers MUST record the client type in the client
registration details in order to identify and process requests
accordingly.

Require PKCE for public clients:
https://datatracker.ietf.org/doc/html/rfc8252#section-8.1

> Authorization servers SHOULD reject authorization requests from native
apps that don't use PKCE by returning an error message

Fixes #21299

Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
2022-10-24 15:59:24 +08:00
KN4CK3R 876ee8c3cd
Allow package version sorting (#21453) 2022-10-23 09:18:15 +08:00
Vladimir Yakovlev da3b657c45 [skip ci] Updated translations via Crowdin 2022-10-21 00:21:01 +00:00
KN4CK3R 99597dd76a [skip ci] Updated translations via Crowdin 2022-10-20 00:20:58 +00:00
KN4CK3R c3b2e44392
Add team member invite by email (#20307)
Allows to add (not registered) team members by email.

related #5353

Invite by mail:

![grafik](https://user-images.githubusercontent.com/1666336/178154779-adcc547f-c0b7-4a2a-a131-4e41a3d9d3ad.png)

Pending invitations:

![grafik](https://user-images.githubusercontent.com/1666336/178154882-9d739bb8-2b04-46c1-a025-c1f4be26af98.png)

Email:

![grafik](https://user-images.githubusercontent.com/1666336/178164716-f2f90893-7ba6-4a5e-a3db-42538a660258.png)

Join form:

![grafik](https://user-images.githubusercontent.com/1666336/178154840-aaab983a-d922-4414-b01a-9b1a19c5cef7.png)

Co-authored-by: Jack Hay <jjphay@gmail.com>
2022-10-19 14:40:28 +02:00
wxiaoguang 522dfd5425 [skip ci] Updated translations via Crowdin 2022-10-19 00:21:12 +00:00
KN4CK3R ea08559045 [skip ci] Updated translations via Crowdin 2022-10-18 00:21:08 +00:00
Lunny Xiao 683c9af89f [skip ci] Updated translations via Crowdin 2022-10-17 00:20:53 +00:00
Lunny Xiao f860a6d2e4
Add system setting table with cache and also add cache supports for user setting (#18058) 2022-10-17 07:29:26 +08:00
silverwind e2727b73a3 [skip ci] Updated translations via Crowdin 2022-10-16 00:20:58 +00:00
Yarden Shoham 7917123209 [skip ci] Updated translations via Crowdin 2022-10-15 00:21:30 +00:00
Yarden Shoham cda2c38f4a [skip ci] Updated translations via Crowdin 2022-10-13 00:21:26 +00:00
kolaente e026459a2d [skip ci] Updated translations via Crowdin 2022-10-12 00:21:02 +00:00
Lauris BH b59b0cad0a
Add user/organization code search (#19977)
Fixes #19925 

Screenshots:

![attels](https://user-images.githubusercontent.com/165205/173864718-fe789429-55bc-4cad-808c-9f02f335cddf.png)
2022-10-11 00:12:03 +01:00
Yarden Shoham 083ac164dc
Fix missing left and right carets in TRANSLATORS (#21397) 2022-10-10 10:36:37 -04:00
Jason Song 274523baf4 [skip ci] Updated translations via Crowdin 2022-10-04 00:20:52 +00:00
techknowlogick af849ac009 [skip ci] Updated translations via Crowdin 2022-10-03 00:20:54 +00:00
qwerty287 edfba99f11 [skip ci] Updated translations via Crowdin 2022-10-01 00:20:52 +00:00
qwerty287 08609d439d
Add pages to view watched repos and subscribed issues/PRs (#17156)
Adds GitHub-like pages to view watched repos and subscribed issues/PRs
This is my second try to fix this, but it is better than the first since
it doesn't uses a filter option which could be slow when accessing
`/issues` or `/pulls` and it shows both pulls and issues (the first try
is #17053).

Closes #16111 
Replaces and closes #17053


![Screenshot](https://user-images.githubusercontent.com/80460567/134782937-3112f7da-425a-45b6-9511-5c9695aee896.png)

Co-authored-by: Lauris BH <lauris@nix.lv>
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
2022-09-29 22:09:14 +03:00
M Hickford 78c15dabf3 [skip ci] Updated translations via Crowdin 2022-09-29 00:20:54 +00:00
Wim 889a41c6a8
Do not allow organisation owners add themselves as collaborator (#20043)
We're already checking for repo owners, but we also need to check for
organisation owners that try to add themselves as collaborator

Closes #17966
2022-09-28 01:25:40 +02:00
Tyrone Yeh 525751243e [skip ci] Updated translations via Crowdin 2022-09-27 00:21:05 +00:00
Julien Palard 2649e7ffbd [skip ci] Updated translations via Crowdin 2022-09-26 00:20:43 +00:00
wxiaoguang c4742fbea3 [skip ci] Updated licenses and gitignores 2022-09-25 00:20:43 +00:00
Tyrone Yeh da0a9ec811 [skip ci] Updated translations via Crowdin 2022-09-24 00:20:52 +00:00
KN4CK3R 301d84e83a [skip ci] Updated translations via Crowdin 2022-09-23 00:20:55 +00:00
silverwind bdc4c4c379 [skip ci] Updated translations via Crowdin 2022-09-16 00:20:55 +00:00
KN4CK3R ef40324c43
Display image digest for container packages (#21170)
fixes #21160
2022-09-14 22:45:13 +02:00
JakobDev fe73246cf9 [skip ci] Updated translations via Crowdin 2022-09-12 00:20:40 +00:00
silverwind 77c916f6d9 [skip ci] Updated licenses and gitignores 2022-09-11 00:20:43 +00:00
silverwind 754861a020 [skip ci] Updated translations via Crowdin 2022-09-10 00:20:50 +00:00
Tyrone Yeh 619eed913c [skip ci] Updated translations via Crowdin 2022-09-09 00:20:54 +00:00
luzpaz cb3b3e519f
Fix various typos (#21103)
Found via `codespell -q 3 -S
./options/locale,./options/license,./public/vendor,./web_src/fomantic -L
actived,allways,attachements,ba,befores,commiter,pullrequest,pullrequests,readby,splitted,te,unknwon`

Co-authored-by: techknowlogick <techknowlogick@gitea.io>
2022-09-07 14:40:36 -04:00
Kyle D 7006d8297d [skip ci] Updated translations via Crowdin 2022-09-07 00:20:58 +00:00
silverwind 795bd946e2 [skip ci] Updated translations via Crowdin 2022-09-06 00:20:50 +00:00
Aaron F 0232601734 [skip ci] Updated translations via Crowdin 2022-09-05 00:20:46 +00:00
Aaron F 3963625b6e
Webhook for Wiki changes (#20219)
Add support for triggering webhook notifications on wiki changes.

This PR contains frontend and backend for webhook notifications on wiki actions (create a new page, rename a page, edit a page and delete a page). The frontend got a new checkbox under the Custom Event -> Repository Events section. There is only one checkbox for create/edit/rename/delete actions, because it makes no sense to separate it and others like releases or packages follow the same schema.

![image](https://user-images.githubusercontent.com/121972/177018803-26851196-831f-4fde-9a4c-9e639b0e0d6b.png)

The actions itself are separated, so that different notifications will be executed (with the "action" field). All the webhook receivers implement the new interface method (Wiki) and the corresponding tests.

When implementing this, I encounter a little bug on editing a wiki page. Creating and editing a wiki page is technically the same action and will be handled by the ```updateWikiPage``` function. But the function need to know if it is a new wiki page or just a change. This distinction is done by the ```action``` parameter, but this will not be sent by the frontend (on form submit). This PR will fix this by adding the ```action``` parameter with the values ```_new``` or ```_edit```, which will be used by the ```updateWikiPage``` function.

I've done integration tests with matrix and gitea (http).

![image](https://user-images.githubusercontent.com/121972/177018795-eb5cdc01-9ba3-483e-a6b7-ed0e313a71fb.png)

Fix #16457

Signed-off-by: Aaron Fischer <mail@aaron-fischer.net>
2022-09-04 20:54:23 +01:00
silverwind 0887459ac6 [skip ci] Updated licenses and gitignores 2022-09-04 00:20:43 +00:00