* API: fix set milestone on PR creation
pr creation via API failed with 404, because we searched
for milestoneID 0, due to uninitialized var usage D:
* add tests
* fix expected status codes
* fix tests
Co-authored-by: 6543 <6543@obermui.de>
* Prevent incorrect HTML escaping in swagger.json
Fix#14706
Signed-off-by: Andrew Thornton <art27@cantab.net>
* oops add it to the helper
Signed-off-by: Andrew Thornton <art27@cantab.net>
* try again
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
* fix no items under /org/$org/{issues,pulls}?type=mentioned
it was filtering by org id, but org-mentions are not persisted like that
to the DB, we need to filter by UID.
This means, selecting different teams will only have an effect on the
selected repos, otherwise results will be the same, which may be
suboptimal.
fixes#14941
* don't spam a warning for a perfectly fine request
When editing forked repos using the API the BaseRepository needs to loaded
in order to check its visibility otherwise there will be NPE panic.
Fix#14956
Signed-off-by: Andrew Thornton <art27@cantab.net>
This is an alternative PR to #13687.
Add `[ui.explore]` settings to allow restricting the
explore pages to logged in users only and to disable the users explore page.
The two proposed settings are:
- `REQUIRE_SIGNIN_VIEW`: Only allows access to the explore pages if the
user is signed in. Also restricts
- `/api/v1/user/search`
- `/api/v1/users/{username}`
- `/api/v1/users/{username}/repos`
- but does not restrict `/api/v1/users/{username}/heatmap`
- `DISABLE_USERS_PAGE`: Disables the /explore/users page
Fix#2908Close#13687
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: 6543 <6543@obermui.de>
Add SameSite setting for cookies and rationalise the cookie setting code. Switches SameSite to Lax by default.
There is a possible future extension of differentiating which cookies could be set at Strict by default but that is for a future PR.
Fix#5583
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Make auto check manual merge as a chooseable mod and add manual merge way on ui
as title, Before this pr, we use same way with GH to check manually merge.
It good, but in some special cases, misjudgments can occur. and it's hard
to fix this bug. So I add option to allow repo manager block "auto check manual merge"
function, Then it will have same style like gitlab(allow empty pr). and to compensate for
not being able to detect THE PR merge automatically, I added a manual approach.
Signed-off-by: a1012112796 <1012112796@qq.com>
* make swager
* api support
* ping ci
* fix TestPullCreate_EmptyChangesWithCommits
* Apply suggestions from code review
Co-authored-by: zeripath <art27@cantab.net>
* Apply review suggestions and add test
* Apply suggestions from code review
Co-authored-by: zeripath <art27@cantab.net>
* fix build
* test error message
* make fmt
* Fix indentation issues identified by @silverwind
Co-authored-by: silverwind <me@silverwind.io>
* Fix tests and make manually merged disabled error on API the same
Signed-off-by: Andrew Thornton <art27@cantab.net>
* a small nit
* fix wrong commit id error
* fix bug
* simple test
* fix test
Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
* Organization removal confirmation using name not password
Gitea is asking for user password to confirm organization
removal so this operation cannot be done in systems with
SSO authentication (where no user passwords are used).
This mod changes the way gitea confirms organization
removal - user must enter organization name (not user
password) to confirm operation (similar to repository
removal confirmation).
Author-Change-Id: IB#1107219
* Translation removed
Translation removed from PR - will be restored using Crowdin
after pull got merged.
Fixes: 95ddcdd8bd
Related: https://github.com/go-gitea/gitea/pull/14738
Author-Change-Id: IB#1107219
* make repo as "pending transfer" if on transfer start doer has no right to create repo in new destination
* if new pending transfer ocured, create UI & Mail notifications
When using HCaptcha on link account pages the site key needs to be passed
in. This PR ensures that HCaptchaSiteKey is set in the data.
Fix#14766
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Support create single tag directly
support create tag with message from create release ui
Signed-off-by: a1012112796 <1012112796@qq.com>
Co-authored-by: Lauris BH <lauris@nix.lv>
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: zeripath <art27@cantab.net>
Move the stopwatches to the eventsource stream
Use the /user/events eventsource to update the stopwatches
instead of polling /api/v1/user/stopwatches if the eventsource
is enabled.
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Expose Restricted field for User
* Add Option to Change Restricted on User via adminEditUser API
* Add test who change restricted & test if it changed it ...
* make generate-swagger
Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Somehow the test for detecting if branches are equal broke
this PR restores this functionality.
Fix#14502
Signed-off-by: Andrew Thornton <art27@cantab.net>
Gitea allows to whitelist email domains so that only email addresses from certain domains are allowed to register an account, but does not currently allows to do the opposite: blacklisting email domains so that addresses from certain domains are *forbidden* to register an account.
The idea has been briefly mentioned in the discussion about issue #6350, but never implemented. This PR does that.
The rationale is that, in my experience of running a Gitea instance, *a single email domain* is responsible for *most* of the spam accounts, and for *all* of the spam accounts that manage to get past the email confirmation step. So on top of the other spam mitigation measures already available (email confirmation, CAPTCHA, etc.), having the option to block a particularly annoying domain would be helpful.
close#13628
* Fix a runtime error when modifying a repository through API call
Using the `PATCH /repos/{owner}/{repo}` endpoint and attempting to
modify `default_branch` on an empty repository will cause a
panic. This commit adds a check for a nil pointer before attempting
to dereference it.
* Apply suggestions from code review
* Apply suggestions from code review
* Ensure that the git repository is loaded
If you change the default branch for a repository you must change it in
git too. Therefore you must open the repository before changing the
default branch.
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Allow empty repos to have their default branches changed
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: Anton Khimich <anton.khimicha@mail.utoronto.ca>
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: Andrew Thornton <art27@cantab.net>
* Added option to disable web hooks
This mod introduces DISABLE_WEB_HOOKS parameter in [security] section
of app.ini (by default set to false). If set to true it disables web
hooks feature. Any existing undelivered web hook tasks will be cancelled.
Any existing web hook definitions will be left untouched in db but
its delivery tasks will be ignored.
Author-Change-Id: IB#1105130
* Webhook spelling fixed
Webhook spelling fixed.
Fixes: 07df6614dc
Related: https://github.com/go-gitea/gitea/pull/13176#pullrequestreview-510868421
Author-Change-Id: IB#1105174
* Parameter description fixed
Parameter description fixed.
Fixes: 07df6614dc
Related: https://github.com/go-gitea/gitea/pull/13176#pullrequestreview-514086107
Author-Change-Id: IB#1105174
* Prevent adding nil label to .AddedLabels or .RemovedLabels
There are possibly a few old databases out there with malmigrated data that can
cause panics with empty labels being migrated.
This PR adds a few tests to prevent nil labels being added.
Fix#14466
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Add doctor command to remove the broken label comments
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: 6543 <6543@obermui.de>
Memcached TTL cannot be > 30 days and if it is attempted the TTL is interpreted as
a unix timestamp.
This PR ensures that the TTL is switched to a unix timestamp in those cases.
Fix#14571
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Add Content-Length header to HEAD requests
This change adds the header Content-Length to HEAD HTTP requests.
The previous behaviour was blocking some Windows executables (i.e
bitsadmin.exe) from downloading files hosted in Gitea.
This along with PR #14541, makes the web server compliant with HTTP RFC 2616 which states
"The methods GET and HEAD MUST be supported by all general-purpose servers"
and
"The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response."
This should also respond to issues #8030 and #14532.
* This change adds the header Content-Length to HEAD HTTP requests
Pass the Size of the content as a parameter to ServeData() instead of
calculating it using ioutil.ReadAll(reader) --> this call is dangerous
and can result in a denial of service.
* Add Content-Length header to HEAD requests
Quick fix for imported dependency not used.
* Check if size is positiv int ...
Co-authored-by: zeripath <art27@cantab.net>
REGISTER_MANUAL_CONFIRM is not honored when doing performing an openid registration. The new account is directly accessible.
With this patch, the manual confirm flag gets honored in the same way as a "normal" registration.
Before moving to Chi, HEAD requests were automatically answered by GET
handlers (SetAutoHead(true) from macaron was used).
This Change will restore the previous behaviour.
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
