2021-01-26 23:36:53 +08:00
|
|
|
// Copyright 2020 The Gitea Authors. All rights reserved.
|
2022-11-27 13:20:29 -05:00
|
|
|
// SPDX-License-Identifier: MIT
|
2021-01-26 23:36:53 +08:00
|
|
|
|
|
|
|
|
package web
|
|
|
|
|
|
|
|
|
|
import (
|
|
|
|
|
"net/http"
|
|
|
|
|
"strings"
|
|
|
|
|
|
2025-03-27 19:40:14 +00:00
|
|
|
"forgejo.org/modules/web/middleware"
|
2021-01-26 23:36:53 +08:00
|
|
|
|
2024-11-05 21:40:44 +01:00
|
|
|
"code.forgejo.org/go-chi/binding"
|
2023-06-18 15:59:09 +08:00
|
|
|
"github.com/go-chi/chi/v5"
|
2021-01-26 23:36:53 +08:00
|
|
|
)
|
|
|
|
|
|
2023-06-18 15:59:09 +08:00
|
|
|
// Bind binding an obj to a handler's context data
|
|
|
|
|
func Bind[T any](_ T) http.HandlerFunc {
|
|
|
|
|
return func(resp http.ResponseWriter, req *http.Request) {
|
2022-12-12 16:09:26 +08:00
|
|
|
theObj := new(T) // create a new form obj for every request but not use obj directly
|
2023-06-18 15:59:09 +08:00
|
|
|
data := middleware.GetContextData(req.Context())
|
|
|
|
|
binding.Bind(req, theObj)
|
|
|
|
|
SetForm(data, theObj)
|
|
|
|
|
middleware.AssignForm(theObj, data)
|
Refactor web route (#24080)
The old code is unnecessarily complex, and has many misuses.
Old code "wraps" a lot, wrap wrap wrap, it's difficult to understand
which kind of handler is used.
The new code uses a general approach, we do not need to write all kinds
of handlers into the "wrapper", do not need to wrap them again and
again.
New code, there are only 2 concepts:
1. HandlerProvider: `func (h any) (handlerProvider func (next)
http.Handler)`, it can be used as middleware
2. Use HandlerProvider to get the final HandlerFunc, and use it for
`r.Get()`
And we can decouple the route package from context package (see the
TODO).
# FAQ
## Is `reflect` safe?
Yes, all handlers are checked during startup, see the `preCheckHandler`
comment. If any handler is wrong, developers could know it in the first
time.
## Does `reflect` affect performance?
No. https://github.com/go-gitea/gitea/pull/24080#discussion_r1164825901
1. This reflect code only runs for each web handler call, handler is far
more slower: 10ms-50ms
2. The reflect is pretty fast (comparing to other code): 0.000265ms
3. XORM has more reflect operations already
2023-04-21 02:49:06 +08:00
|
|
|
}
|
2021-01-26 23:36:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// SetForm set the form object
|
2023-07-04 20:36:08 +02:00
|
|
|
func SetForm(dataStore middleware.ContextDataStore, obj any) {
|
2023-06-18 15:59:09 +08:00
|
|
|
dataStore.GetData()["__form"] = obj
|
2021-01-26 23:36:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// GetForm returns the validate form information
|
2023-07-04 20:36:08 +02:00
|
|
|
func GetForm(dataStore middleware.ContextDataStore) any {
|
2023-06-18 15:59:09 +08:00
|
|
|
return dataStore.GetData()["__form"]
|
2021-01-26 23:36:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Route defines a route based on chi's router
|
|
|
|
|
type Route struct {
|
|
|
|
|
R chi.Router
|
|
|
|
|
curGroupPrefix string
|
2023-07-04 20:36:08 +02:00
|
|
|
curMiddlewares []any
|
2021-01-26 23:36:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// NewRoute creates a new route
|
|
|
|
|
func NewRoute() *Route {
|
|
|
|
|
r := chi.NewRouter()
|
2023-04-27 14:06:45 +08:00
|
|
|
return &Route{R: r}
|
2021-01-26 23:36:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Use supports two middlewares
|
2023-07-04 20:36:08 +02:00
|
|
|
func (r *Route) Use(middlewares ...any) {
|
2023-04-27 14:06:45 +08:00
|
|
|
for _, m := range middlewares {
|
2023-07-09 20:25:53 +08:00
|
|
|
if m != nil {
|
|
|
|
|
r.R.Use(toHandlerProvider(m))
|
|
|
|
|
}
|
2021-01-26 23:36:53 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Group mounts a sub-Router along a `pattern` string.
|
2023-07-04 20:36:08 +02:00
|
|
|
func (r *Route) Group(pattern string, fn func(), middlewares ...any) {
|
2022-01-20 18:46:10 +01:00
|
|
|
previousGroupPrefix := r.curGroupPrefix
|
|
|
|
|
previousMiddlewares := r.curMiddlewares
|
2021-01-26 23:36:53 +08:00
|
|
|
r.curGroupPrefix += pattern
|
|
|
|
|
r.curMiddlewares = append(r.curMiddlewares, middlewares...)
|
|
|
|
|
|
|
|
|
|
fn()
|
|
|
|
|
|
|
|
|
|
r.curGroupPrefix = previousGroupPrefix
|
|
|
|
|
r.curMiddlewares = previousMiddlewares
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *Route) getPattern(pattern string) string {
|
|
|
|
|
newPattern := r.curGroupPrefix + pattern
|
|
|
|
|
if !strings.HasPrefix(newPattern, "/") {
|
|
|
|
|
newPattern = "/" + newPattern
|
|
|
|
|
}
|
|
|
|
|
if newPattern == "/" {
|
|
|
|
|
return newPattern
|
|
|
|
|
}
|
|
|
|
|
return strings.TrimSuffix(newPattern, "/")
|
|
|
|
|
}
|
|
|
|
|
|
Refactor web route (#24080)
The old code is unnecessarily complex, and has many misuses.
Old code "wraps" a lot, wrap wrap wrap, it's difficult to understand
which kind of handler is used.
The new code uses a general approach, we do not need to write all kinds
of handlers into the "wrapper", do not need to wrap them again and
again.
New code, there are only 2 concepts:
1. HandlerProvider: `func (h any) (handlerProvider func (next)
http.Handler)`, it can be used as middleware
2. Use HandlerProvider to get the final HandlerFunc, and use it for
`r.Get()`
And we can decouple the route package from context package (see the
TODO).
# FAQ
## Is `reflect` safe?
Yes, all handlers are checked during startup, see the `preCheckHandler`
comment. If any handler is wrong, developers could know it in the first
time.
## Does `reflect` affect performance?
No. https://github.com/go-gitea/gitea/pull/24080#discussion_r1164825901
1. This reflect code only runs for each web handler call, handler is far
more slower: 10ms-50ms
2. The reflect is pretty fast (comparing to other code): 0.000265ms
3. XORM has more reflect operations already
2023-04-21 02:49:06 +08:00
|
|
|
func (r *Route) wrapMiddlewareAndHandler(h []any) ([]func(http.Handler) http.Handler, http.HandlerFunc) {
|
2023-07-09 20:25:53 +08:00
|
|
|
handlerProviders := make([]func(http.Handler) http.Handler, 0, len(r.curMiddlewares)+len(h)+1)
|
Refactor web route (#24080)
The old code is unnecessarily complex, and has many misuses.
Old code "wraps" a lot, wrap wrap wrap, it's difficult to understand
which kind of handler is used.
The new code uses a general approach, we do not need to write all kinds
of handlers into the "wrapper", do not need to wrap them again and
again.
New code, there are only 2 concepts:
1. HandlerProvider: `func (h any) (handlerProvider func (next)
http.Handler)`, it can be used as middleware
2. Use HandlerProvider to get the final HandlerFunc, and use it for
`r.Get()`
And we can decouple the route package from context package (see the
TODO).
# FAQ
## Is `reflect` safe?
Yes, all handlers are checked during startup, see the `preCheckHandler`
comment. If any handler is wrong, developers could know it in the first
time.
## Does `reflect` affect performance?
No. https://github.com/go-gitea/gitea/pull/24080#discussion_r1164825901
1. This reflect code only runs for each web handler call, handler is far
more slower: 10ms-50ms
2. The reflect is pretty fast (comparing to other code): 0.000265ms
3. XORM has more reflect operations already
2023-04-21 02:49:06 +08:00
|
|
|
for _, m := range r.curMiddlewares {
|
2023-07-09 20:25:53 +08:00
|
|
|
if m != nil {
|
|
|
|
|
handlerProviders = append(handlerProviders, toHandlerProvider(m))
|
|
|
|
|
}
|
Refactor web route (#24080)
The old code is unnecessarily complex, and has many misuses.
Old code "wraps" a lot, wrap wrap wrap, it's difficult to understand
which kind of handler is used.
The new code uses a general approach, we do not need to write all kinds
of handlers into the "wrapper", do not need to wrap them again and
again.
New code, there are only 2 concepts:
1. HandlerProvider: `func (h any) (handlerProvider func (next)
http.Handler)`, it can be used as middleware
2. Use HandlerProvider to get the final HandlerFunc, and use it for
`r.Get()`
And we can decouple the route package from context package (see the
TODO).
# FAQ
## Is `reflect` safe?
Yes, all handlers are checked during startup, see the `preCheckHandler`
comment. If any handler is wrong, developers could know it in the first
time.
## Does `reflect` affect performance?
No. https://github.com/go-gitea/gitea/pull/24080#discussion_r1164825901
1. This reflect code only runs for each web handler call, handler is far
more slower: 10ms-50ms
2. The reflect is pretty fast (comparing to other code): 0.000265ms
3. XORM has more reflect operations already
2023-04-21 02:49:06 +08:00
|
|
|
}
|
|
|
|
|
for _, m := range h {
|
2025-11-21 combined security patches (#10037)
[CVSS 5.3 Medium](https://www.first.org/cvss/calculator/4-0#CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N) -- The `/repos/{owner}/{repo}/issues/{index}/dependencies` APIs allow a user to link an issue in one repository as "depending upon" an issue in another repository. Forgejo's implementation had an incorrect permission check which would verify only that the user had write permissions on the issue being modified, and not on the issue it was linking to. Due to the incorrect permission check, it was possible to view limited information (the existence of, and title of) an issue in a private repository that the user does not have access to view. The permission check has been corrected to take into account visibility of the remote repository.
[CVSS 5.3 Medium](https://www.first.org/cvss/calculator/4-0#CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N) -- Fetching information about a release via the `/repos/{owner}/{repo}/releases/tag/{tag}` API endpoint did not check whether the release was a draft, allowing accessing to information about a draft release to users who could predict an upcoming release tag but didn't have access to view it. The missing check has been added, returning a 404 response when the release is not published.
[CVSS 6.3 Medium](https://www.first.org/cvss/calculator/4-0#CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N) -- Forgejo's web interface allows deleting tags on a git repository through a form post. The endpoint for this form post had misconfigured middleware handlers which enforce security rights, allowing an anonymous user, or a logged-in user without the correct permissions, to delete tags on repositories that they did not own by injecting arbitrary internal tag identifiers into the form. The middleware handler configuration has been corrected.
[CVSS 2.1 Low](https://www.first.org/cvss/calculator/4-0#CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N) -- When the head branch of a pull request matches a branch protection rule, the head branch should be able to be merged or rebased only according to the "Push" rules defined in the protection rule. An implementation error checked those branch protection rules in the context of the base repository rather than the head repository, allowing users with write access to the base repository to be considered able to push to the branch, bypassing the "Enable push" option's expected security control.
[CVSS 2.1 Low](https://www.first.org/cvss/calculator/4-0#CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N) -- An issue owner can manipulate form inputs to delete the content history of comments they did not create, as long as those comments are on issues that they own. Although comment content is not affected, the history of edits on the comment can be trimmed. The validation in the form handler was corrected.
[CVSS 5.1 Medium](https://www.first.org/cvss/calculator/4-0#CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N) -- When a repository is configured with tag protection rules, it should not be possible for a user that is outside the whitelisted users or teams from modifying the protected tags. An incorrect parameter being passed to a security verification method allowed a user with write access to the repo to delete tags even if they were protected, as long as the tag was originally created by a user who is still authorized by the protection rules.
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Security bug fixes
- [PR](https://codeberg.org/forgejo/forgejo/pulls/10037): <!--number 10037 --><!--line 0 --><!--description Zml4KGFwaSk6IGZpeCBkZXBlbmRlbmN5IHJlcG8gcGVybXMgaW4gQ3JlYXRlL1JlbW92ZUlzc3VlRGVwZW5kZW5jeQ==-->fix(api): fix dependency repo perms in Create/RemoveIssueDependency<!--description-->
- [PR](https://codeberg.org/forgejo/forgejo/pulls/10037): <!--number 10037 --><!--line 1 --><!--description Zml4KGFwaSk6IGRyYWZ0IHJlbGVhc2VzIGNvdWxkIGJlIHJlYWQgYmVmb3JlIGJlaW5nIHB1Ymxpc2hlZA==-->fix(api): draft releases could be read before being published<!--description-->
- [PR](https://codeberg.org/forgejo/forgejo/pulls/10037): <!--number 10037 --><!--line 2 --><!--description bWlzY29uZmlndXJlZCBzZWN1cml0eSBjaGVja3Mgb24gdGFnIGRlbGV0ZSB3ZWIgZm9ybQ==-->misconfigured security checks on tag delete web form<!--description-->
- [PR](https://codeberg.org/forgejo/forgejo/pulls/10037): <!--number 10037 --><!--line 3 --><!--description aW5jb3JyZWN0IGxvZ2ljIGluICJVcGRhdGUgUFIiIGRpZCBub3QgZW5mb3JjZSBoZWFkIGJyYW5jaCBwcm90ZWN0aW9uIHJ1bGVzIGNvcnJlY3RseQ==-->incorrect logic in "Update PR" did not enforce head branch protection rules correctly<!--description-->
- [PR](https://codeberg.org/forgejo/forgejo/pulls/10037): <!--number 10037 --><!--line 4 --><!--description aXNzdWUgb3duZXIgY2FuIGRlbGV0ZSBhbm90aGVyIHVzZXIncyBjb21tZW50J3MgZWRpdCBoaXN0b3J5IG9uIHNhbWUgaXNzdWU=-->issue owner can delete another user's comment's edit history on same issue<!--description-->
- [PR](https://codeberg.org/forgejo/forgejo/pulls/10037): <!--number 10037 --><!--line 5 --><!--description dGFnIHByb3RlY3Rpb24gcnVsZXMgY2FuIGJlIGJ5cGFzc2VkIGR1cmluZyB0YWcgZGVsZXRlIG9wZXJhdGlvbg==-->tag protection rules can be bypassed during tag delete operation<!--description-->
<!--end release-notes-assistant-->
Co-authored-by: Joshua Rogers <MegaManSec@users.noreply.github.com>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10037
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
2025-11-21 05:23:43 +01:00
|
|
|
if m != nil {
|
2023-07-09 20:25:53 +08:00
|
|
|
handlerProviders = append(handlerProviders, toHandlerProvider(m))
|
|
|
|
|
}
|
Refactor web route (#24080)
The old code is unnecessarily complex, and has many misuses.
Old code "wraps" a lot, wrap wrap wrap, it's difficult to understand
which kind of handler is used.
The new code uses a general approach, we do not need to write all kinds
of handlers into the "wrapper", do not need to wrap them again and
again.
New code, there are only 2 concepts:
1. HandlerProvider: `func (h any) (handlerProvider func (next)
http.Handler)`, it can be used as middleware
2. Use HandlerProvider to get the final HandlerFunc, and use it for
`r.Get()`
And we can decouple the route package from context package (see the
TODO).
# FAQ
## Is `reflect` safe?
Yes, all handlers are checked during startup, see the `preCheckHandler`
comment. If any handler is wrong, developers could know it in the first
time.
## Does `reflect` affect performance?
No. https://github.com/go-gitea/gitea/pull/24080#discussion_r1164825901
1. This reflect code only runs for each web handler call, handler is far
more slower: 10ms-50ms
2. The reflect is pretty fast (comparing to other code): 0.000265ms
3. XORM has more reflect operations already
2023-04-21 02:49:06 +08:00
|
|
|
}
|
|
|
|
|
middlewares := handlerProviders[:len(handlerProviders)-1]
|
|
|
|
|
handlerFunc := handlerProviders[len(handlerProviders)-1](nil).ServeHTTP
|
2023-07-09 20:25:53 +08:00
|
|
|
mockPoint := RouteMockPoint(MockAfterMiddlewares)
|
|
|
|
|
if mockPoint != nil {
|
|
|
|
|
middlewares = append(middlewares, mockPoint)
|
|
|
|
|
}
|
Refactor web route (#24080)
The old code is unnecessarily complex, and has many misuses.
Old code "wraps" a lot, wrap wrap wrap, it's difficult to understand
which kind of handler is used.
The new code uses a general approach, we do not need to write all kinds
of handlers into the "wrapper", do not need to wrap them again and
again.
New code, there are only 2 concepts:
1. HandlerProvider: `func (h any) (handlerProvider func (next)
http.Handler)`, it can be used as middleware
2. Use HandlerProvider to get the final HandlerFunc, and use it for
`r.Get()`
And we can decouple the route package from context package (see the
TODO).
# FAQ
## Is `reflect` safe?
Yes, all handlers are checked during startup, see the `preCheckHandler`
comment. If any handler is wrong, developers could know it in the first
time.
## Does `reflect` affect performance?
No. https://github.com/go-gitea/gitea/pull/24080#discussion_r1164825901
1. This reflect code only runs for each web handler call, handler is far
more slower: 10ms-50ms
2. The reflect is pretty fast (comparing to other code): 0.000265ms
3. XORM has more reflect operations already
2023-04-21 02:49:06 +08:00
|
|
|
return middlewares, handlerFunc
|
|
|
|
|
}
|
|
|
|
|
|
2023-12-25 20:13:18 +08:00
|
|
|
// Methods adds the same handlers for multiple http "methods" (separated by ",").
|
|
|
|
|
// If any method is invalid, the lower level router will panic.
|
|
|
|
|
func (r *Route) Methods(methods, pattern string, h ...any) {
|
Refactor web route (#24080)
The old code is unnecessarily complex, and has many misuses.
Old code "wraps" a lot, wrap wrap wrap, it's difficult to understand
which kind of handler is used.
The new code uses a general approach, we do not need to write all kinds
of handlers into the "wrapper", do not need to wrap them again and
again.
New code, there are only 2 concepts:
1. HandlerProvider: `func (h any) (handlerProvider func (next)
http.Handler)`, it can be used as middleware
2. Use HandlerProvider to get the final HandlerFunc, and use it for
`r.Get()`
And we can decouple the route package from context package (see the
TODO).
# FAQ
## Is `reflect` safe?
Yes, all handlers are checked during startup, see the `preCheckHandler`
comment. If any handler is wrong, developers could know it in the first
time.
## Does `reflect` affect performance?
No. https://github.com/go-gitea/gitea/pull/24080#discussion_r1164825901
1. This reflect code only runs for each web handler call, handler is far
more slower: 10ms-50ms
2. The reflect is pretty fast (comparing to other code): 0.000265ms
3. XORM has more reflect operations already
2023-04-21 02:49:06 +08:00
|
|
|
middlewares, handlerFunc := r.wrapMiddlewareAndHandler(h)
|
|
|
|
|
fullPattern := r.getPattern(pattern)
|
2023-12-25 20:13:18 +08:00
|
|
|
if strings.Contains(methods, ",") {
|
|
|
|
|
methods := strings.Split(methods, ",")
|
Refactor web route (#24080)
The old code is unnecessarily complex, and has many misuses.
Old code "wraps" a lot, wrap wrap wrap, it's difficult to understand
which kind of handler is used.
The new code uses a general approach, we do not need to write all kinds
of handlers into the "wrapper", do not need to wrap them again and
again.
New code, there are only 2 concepts:
1. HandlerProvider: `func (h any) (handlerProvider func (next)
http.Handler)`, it can be used as middleware
2. Use HandlerProvider to get the final HandlerFunc, and use it for
`r.Get()`
And we can decouple the route package from context package (see the
TODO).
# FAQ
## Is `reflect` safe?
Yes, all handlers are checked during startup, see the `preCheckHandler`
comment. If any handler is wrong, developers could know it in the first
time.
## Does `reflect` affect performance?
No. https://github.com/go-gitea/gitea/pull/24080#discussion_r1164825901
1. This reflect code only runs for each web handler call, handler is far
more slower: 10ms-50ms
2. The reflect is pretty fast (comparing to other code): 0.000265ms
3. XORM has more reflect operations already
2023-04-21 02:49:06 +08:00
|
|
|
for _, method := range methods {
|
|
|
|
|
r.R.With(middlewares...).Method(strings.TrimSpace(method), fullPattern, handlerFunc)
|
|
|
|
|
}
|
|
|
|
|
} else {
|
2023-12-25 20:13:18 +08:00
|
|
|
r.R.With(middlewares...).Method(methods, fullPattern, handlerFunc)
|
Refactor web route (#24080)
The old code is unnecessarily complex, and has many misuses.
Old code "wraps" a lot, wrap wrap wrap, it's difficult to understand
which kind of handler is used.
The new code uses a general approach, we do not need to write all kinds
of handlers into the "wrapper", do not need to wrap them again and
again.
New code, there are only 2 concepts:
1. HandlerProvider: `func (h any) (handlerProvider func (next)
http.Handler)`, it can be used as middleware
2. Use HandlerProvider to get the final HandlerFunc, and use it for
`r.Get()`
And we can decouple the route package from context package (see the
TODO).
# FAQ
## Is `reflect` safe?
Yes, all handlers are checked during startup, see the `preCheckHandler`
comment. If any handler is wrong, developers could know it in the first
time.
## Does `reflect` affect performance?
No. https://github.com/go-gitea/gitea/pull/24080#discussion_r1164825901
1. This reflect code only runs for each web handler call, handler is far
more slower: 10ms-50ms
2. The reflect is pretty fast (comparing to other code): 0.000265ms
3. XORM has more reflect operations already
2023-04-21 02:49:06 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-01-26 23:36:53 +08:00
|
|
|
// Mount attaches another Route along ./pattern/*
|
|
|
|
|
func (r *Route) Mount(pattern string, subR *Route) {
|
2023-04-27 14:06:45 +08:00
|
|
|
subR.Use(r.curMiddlewares...)
|
2021-01-26 23:36:53 +08:00
|
|
|
r.R.Mount(r.getPattern(pattern), subR.R)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Any delegate requests for all methods
|
2023-07-04 20:36:08 +02:00
|
|
|
func (r *Route) Any(pattern string, h ...any) {
|
Refactor web route (#24080)
The old code is unnecessarily complex, and has many misuses.
Old code "wraps" a lot, wrap wrap wrap, it's difficult to understand
which kind of handler is used.
The new code uses a general approach, we do not need to write all kinds
of handlers into the "wrapper", do not need to wrap them again and
again.
New code, there are only 2 concepts:
1. HandlerProvider: `func (h any) (handlerProvider func (next)
http.Handler)`, it can be used as middleware
2. Use HandlerProvider to get the final HandlerFunc, and use it for
`r.Get()`
And we can decouple the route package from context package (see the
TODO).
# FAQ
## Is `reflect` safe?
Yes, all handlers are checked during startup, see the `preCheckHandler`
comment. If any handler is wrong, developers could know it in the first
time.
## Does `reflect` affect performance?
No. https://github.com/go-gitea/gitea/pull/24080#discussion_r1164825901
1. This reflect code only runs for each web handler call, handler is far
more slower: 10ms-50ms
2. The reflect is pretty fast (comparing to other code): 0.000265ms
3. XORM has more reflect operations already
2023-04-21 02:49:06 +08:00
|
|
|
middlewares, handlerFunc := r.wrapMiddlewareAndHandler(h)
|
|
|
|
|
r.R.With(middlewares...).HandleFunc(r.getPattern(pattern), handlerFunc)
|
2021-01-26 23:36:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Delete delegate delete method
|
2023-07-04 20:36:08 +02:00
|
|
|
func (r *Route) Delete(pattern string, h ...any) {
|
2023-07-21 06:43:49 +08:00
|
|
|
r.Methods("DELETE", pattern, h...)
|
2021-01-26 23:36:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Get delegate get method
|
2023-07-04 20:36:08 +02:00
|
|
|
func (r *Route) Get(pattern string, h ...any) {
|
2023-07-21 06:43:49 +08:00
|
|
|
r.Methods("GET", pattern, h...)
|
2021-07-21 04:32:35 +01:00
|
|
|
}
|
|
|
|
|
|
2021-01-26 23:36:53 +08:00
|
|
|
// Head delegate head method
|
2023-07-04 20:36:08 +02:00
|
|
|
func (r *Route) Head(pattern string, h ...any) {
|
2023-07-21 06:43:49 +08:00
|
|
|
r.Methods("HEAD", pattern, h...)
|
2021-01-26 23:36:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Post delegate post method
|
2023-07-04 20:36:08 +02:00
|
|
|
func (r *Route) Post(pattern string, h ...any) {
|
2023-07-21 06:43:49 +08:00
|
|
|
r.Methods("POST", pattern, h...)
|
2021-01-26 23:36:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Put delegate put method
|
2023-07-04 20:36:08 +02:00
|
|
|
func (r *Route) Put(pattern string, h ...any) {
|
2023-07-21 06:43:49 +08:00
|
|
|
r.Methods("PUT", pattern, h...)
|
2021-01-26 23:36:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Patch delegate patch method
|
2023-07-04 20:36:08 +02:00
|
|
|
func (r *Route) Patch(pattern string, h ...any) {
|
2023-07-21 06:43:49 +08:00
|
|
|
r.Methods("PATCH", pattern, h...)
|
2021-01-26 23:36:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// ServeHTTP implements http.Handler
|
|
|
|
|
func (r *Route) ServeHTTP(w http.ResponseWriter, req *http.Request) {
|
|
|
|
|
r.R.ServeHTTP(w, req)
|
|
|
|
|
}
|
|
|
|
|
|
Refactor web route (#24080)
The old code is unnecessarily complex, and has many misuses.
Old code "wraps" a lot, wrap wrap wrap, it's difficult to understand
which kind of handler is used.
The new code uses a general approach, we do not need to write all kinds
of handlers into the "wrapper", do not need to wrap them again and
again.
New code, there are only 2 concepts:
1. HandlerProvider: `func (h any) (handlerProvider func (next)
http.Handler)`, it can be used as middleware
2. Use HandlerProvider to get the final HandlerFunc, and use it for
`r.Get()`
And we can decouple the route package from context package (see the
TODO).
# FAQ
## Is `reflect` safe?
Yes, all handlers are checked during startup, see the `preCheckHandler`
comment. If any handler is wrong, developers could know it in the first
time.
## Does `reflect` affect performance?
No. https://github.com/go-gitea/gitea/pull/24080#discussion_r1164825901
1. This reflect code only runs for each web handler call, handler is far
more slower: 10ms-50ms
2. The reflect is pretty fast (comparing to other code): 0.000265ms
3. XORM has more reflect operations already
2023-04-21 02:49:06 +08:00
|
|
|
// NotFound defines a handler to respond whenever a route could not be found.
|
2021-01-26 23:36:53 +08:00
|
|
|
func (r *Route) NotFound(h http.HandlerFunc) {
|
|
|
|
|
r.R.NotFound(h)
|
|
|
|
|
}
|
|
|
|
|
|
Refactor web route (#24080)
The old code is unnecessarily complex, and has many misuses.
Old code "wraps" a lot, wrap wrap wrap, it's difficult to understand
which kind of handler is used.
The new code uses a general approach, we do not need to write all kinds
of handlers into the "wrapper", do not need to wrap them again and
again.
New code, there are only 2 concepts:
1. HandlerProvider: `func (h any) (handlerProvider func (next)
http.Handler)`, it can be used as middleware
2. Use HandlerProvider to get the final HandlerFunc, and use it for
`r.Get()`
And we can decouple the route package from context package (see the
TODO).
# FAQ
## Is `reflect` safe?
Yes, all handlers are checked during startup, see the `preCheckHandler`
comment. If any handler is wrong, developers could know it in the first
time.
## Does `reflect` affect performance?
No. https://github.com/go-gitea/gitea/pull/24080#discussion_r1164825901
1. This reflect code only runs for each web handler call, handler is far
more slower: 10ms-50ms
2. The reflect is pretty fast (comparing to other code): 0.000265ms
3. XORM has more reflect operations already
2023-04-21 02:49:06 +08:00
|
|
|
// Combo delegates requests to Combo
|
2023-07-04 20:36:08 +02:00
|
|
|
func (r *Route) Combo(pattern string, h ...any) *Combo {
|
2021-01-26 23:36:53 +08:00
|
|
|
return &Combo{r, pattern, h}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Combo represents a tiny group routes with same pattern
|
|
|
|
|
type Combo struct {
|
|
|
|
|
r *Route
|
|
|
|
|
pattern string
|
2023-07-04 20:36:08 +02:00
|
|
|
h []any
|
2021-01-26 23:36:53 +08:00
|
|
|
}
|
|
|
|
|
|
Refactor web route (#24080)
The old code is unnecessarily complex, and has many misuses.
Old code "wraps" a lot, wrap wrap wrap, it's difficult to understand
which kind of handler is used.
The new code uses a general approach, we do not need to write all kinds
of handlers into the "wrapper", do not need to wrap them again and
again.
New code, there are only 2 concepts:
1. HandlerProvider: `func (h any) (handlerProvider func (next)
http.Handler)`, it can be used as middleware
2. Use HandlerProvider to get the final HandlerFunc, and use it for
`r.Get()`
And we can decouple the route package from context package (see the
TODO).
# FAQ
## Is `reflect` safe?
Yes, all handlers are checked during startup, see the `preCheckHandler`
comment. If any handler is wrong, developers could know it in the first
time.
## Does `reflect` affect performance?
No. https://github.com/go-gitea/gitea/pull/24080#discussion_r1164825901
1. This reflect code only runs for each web handler call, handler is far
more slower: 10ms-50ms
2. The reflect is pretty fast (comparing to other code): 0.000265ms
3. XORM has more reflect operations already
2023-04-21 02:49:06 +08:00
|
|
|
// Get delegates Get method
|
2023-07-04 20:36:08 +02:00
|
|
|
func (c *Combo) Get(h ...any) *Combo {
|
2021-01-26 23:36:53 +08:00
|
|
|
c.r.Get(c.pattern, append(c.h, h...)...)
|
|
|
|
|
return c
|
|
|
|
|
}
|
|
|
|
|
|
Refactor web route (#24080)
The old code is unnecessarily complex, and has many misuses.
Old code "wraps" a lot, wrap wrap wrap, it's difficult to understand
which kind of handler is used.
The new code uses a general approach, we do not need to write all kinds
of handlers into the "wrapper", do not need to wrap them again and
again.
New code, there are only 2 concepts:
1. HandlerProvider: `func (h any) (handlerProvider func (next)
http.Handler)`, it can be used as middleware
2. Use HandlerProvider to get the final HandlerFunc, and use it for
`r.Get()`
And we can decouple the route package from context package (see the
TODO).
# FAQ
## Is `reflect` safe?
Yes, all handlers are checked during startup, see the `preCheckHandler`
comment. If any handler is wrong, developers could know it in the first
time.
## Does `reflect` affect performance?
No. https://github.com/go-gitea/gitea/pull/24080#discussion_r1164825901
1. This reflect code only runs for each web handler call, handler is far
more slower: 10ms-50ms
2. The reflect is pretty fast (comparing to other code): 0.000265ms
3. XORM has more reflect operations already
2023-04-21 02:49:06 +08:00
|
|
|
// Post delegates Post method
|
2023-07-04 20:36:08 +02:00
|
|
|
func (c *Combo) Post(h ...any) *Combo {
|
2021-01-26 23:36:53 +08:00
|
|
|
c.r.Post(c.pattern, append(c.h, h...)...)
|
|
|
|
|
return c
|
|
|
|
|
}
|
|
|
|
|
|
Refactor web route (#24080)
The old code is unnecessarily complex, and has many misuses.
Old code "wraps" a lot, wrap wrap wrap, it's difficult to understand
which kind of handler is used.
The new code uses a general approach, we do not need to write all kinds
of handlers into the "wrapper", do not need to wrap them again and
again.
New code, there are only 2 concepts:
1. HandlerProvider: `func (h any) (handlerProvider func (next)
http.Handler)`, it can be used as middleware
2. Use HandlerProvider to get the final HandlerFunc, and use it for
`r.Get()`
And we can decouple the route package from context package (see the
TODO).
# FAQ
## Is `reflect` safe?
Yes, all handlers are checked during startup, see the `preCheckHandler`
comment. If any handler is wrong, developers could know it in the first
time.
## Does `reflect` affect performance?
No. https://github.com/go-gitea/gitea/pull/24080#discussion_r1164825901
1. This reflect code only runs for each web handler call, handler is far
more slower: 10ms-50ms
2. The reflect is pretty fast (comparing to other code): 0.000265ms
3. XORM has more reflect operations already
2023-04-21 02:49:06 +08:00
|
|
|
// Delete delegates Delete method
|
2023-07-04 20:36:08 +02:00
|
|
|
func (c *Combo) Delete(h ...any) *Combo {
|
2021-01-26 23:36:53 +08:00
|
|
|
c.r.Delete(c.pattern, append(c.h, h...)...)
|
|
|
|
|
return c
|
|
|
|
|
}
|
|
|
|
|
|
Refactor web route (#24080)
The old code is unnecessarily complex, and has many misuses.
Old code "wraps" a lot, wrap wrap wrap, it's difficult to understand
which kind of handler is used.
The new code uses a general approach, we do not need to write all kinds
of handlers into the "wrapper", do not need to wrap them again and
again.
New code, there are only 2 concepts:
1. HandlerProvider: `func (h any) (handlerProvider func (next)
http.Handler)`, it can be used as middleware
2. Use HandlerProvider to get the final HandlerFunc, and use it for
`r.Get()`
And we can decouple the route package from context package (see the
TODO).
# FAQ
## Is `reflect` safe?
Yes, all handlers are checked during startup, see the `preCheckHandler`
comment. If any handler is wrong, developers could know it in the first
time.
## Does `reflect` affect performance?
No. https://github.com/go-gitea/gitea/pull/24080#discussion_r1164825901
1. This reflect code only runs for each web handler call, handler is far
more slower: 10ms-50ms
2. The reflect is pretty fast (comparing to other code): 0.000265ms
3. XORM has more reflect operations already
2023-04-21 02:49:06 +08:00
|
|
|
// Put delegates Put method
|
2023-07-04 20:36:08 +02:00
|
|
|
func (c *Combo) Put(h ...any) *Combo {
|
2021-01-26 23:36:53 +08:00
|
|
|
c.r.Put(c.pattern, append(c.h, h...)...)
|
|
|
|
|
return c
|
|
|
|
|
}
|
|
|
|
|
|
Refactor web route (#24080)
The old code is unnecessarily complex, and has many misuses.
Old code "wraps" a lot, wrap wrap wrap, it's difficult to understand
which kind of handler is used.
The new code uses a general approach, we do not need to write all kinds
of handlers into the "wrapper", do not need to wrap them again and
again.
New code, there are only 2 concepts:
1. HandlerProvider: `func (h any) (handlerProvider func (next)
http.Handler)`, it can be used as middleware
2. Use HandlerProvider to get the final HandlerFunc, and use it for
`r.Get()`
And we can decouple the route package from context package (see the
TODO).
# FAQ
## Is `reflect` safe?
Yes, all handlers are checked during startup, see the `preCheckHandler`
comment. If any handler is wrong, developers could know it in the first
time.
## Does `reflect` affect performance?
No. https://github.com/go-gitea/gitea/pull/24080#discussion_r1164825901
1. This reflect code only runs for each web handler call, handler is far
more slower: 10ms-50ms
2. The reflect is pretty fast (comparing to other code): 0.000265ms
3. XORM has more reflect operations already
2023-04-21 02:49:06 +08:00
|
|
|
// Patch delegates Patch method
|
2023-07-04 20:36:08 +02:00
|
|
|
func (c *Combo) Patch(h ...any) *Combo {
|
2021-01-26 23:36:53 +08:00
|
|
|
c.r.Patch(c.pattern, append(c.h, h...)...)
|
|
|
|
|
return c
|
|
|
|
|
}
|