// Copyright 2017 The Gitea Authors. All rights reserved.
// SPDX-License-Identifier: MIT
Refactor internal API for git commands, use meaningful messages instead of "Internal Server Error" (#23687)
# Why this PR comes
At first, I'd like to help users like #23636 (there are a lot)
The unclear "Internal Server Error" is quite anonying, scare users,
frustrate contributors, nobody knows what happens.
So, it's always good to provide meaningful messages to end users (of
course, do not leak sensitive information).
When I started working on the "response message to end users", I found
that the related code has a lot of technical debt. A lot of copy&paste
code, unclear fields and usages.
So I think it's good to make everything clear.
# Tech Backgrounds
Gitea has many sub-commands, some are used by admins, some are used by
SSH servers or Git Hooks. Many sub-commands use "internal API" to
communicate with Gitea web server.
Before, Gitea server always use `StatusCode + Json "err" field` to
return messages.
* The CLI sub-commands: they expect to show all error related messages
to site admin
* The Serv/Hook sub-commands (for git clients): they could only show
safe messages to end users, the error log could only be recorded by
"SSHLog" to Gitea web server.
In the old design, it assumes that:
* If the StatusCode is 500 (in some functions), then the "err" field is
error log, shouldn't be exposed to git client.
* If the StatusCode is 40x, then the "err" field could be exposed. And
some functions always read the "err" no matter what the StatusCode is.
The old code is not strict, and it's difficult to distinguish the
messages clearly and then output them correctly.
# This PR
To help to remove duplicate code and make everything clear, this PR
introduces `ResponseExtra` and `requestJSONResp`.
* `ResponseExtra` is a struct which contains "extra" information of a
internal API response, including StatusCode, UserMsg, Error
* `requestJSONResp` is a generic function which can be used for all
cases to help to simplify the calls.
* Remove all `map["err"]`, always use `private.Response{Err}` to
construct error messages.
* User messages and error messages are separated clearly, the `fail` and
`handleCliResponseExtra` will output correct messages.
* Replace all `Internal Server Error` messages with meaningful (still
safe) messages.
This PR saves more than 300 lines, while makes the git client messages
more clear.
Many gitea-serv/git-hook related essential functions are covered by
tests.
---------
Co-authored-by: delvh <dev.lh@web.de>
2 years ago
// Package private contains all internal routes. The package name "internal" isn't usable because Golang reserves it for disabling cross-package usage.
package private
import (
"net/http"
"strings"
"code.gitea.io/gitea/modules/log"
"code.gitea.io/gitea/modules/private"
"code.gitea.io/gitea/modules/setting"
"code.gitea.io/gitea/modules/web"
"code.gitea.io/gitea/services/context"
"gitea.com/go-chi/binding"
chi_middleware "github.com/go-chi/chi/v5/middleware"
)
// CheckInternalToken check internal token is set
func CheckInternalToken ( next http . Handler ) http . Handler {
return http . HandlerFunc ( func ( w http . ResponseWriter , req * http . Request ) {
tokens := req . Header . Get ( "Authorization" )
fields := strings . SplitN ( tokens , " " , 2 )
if setting . InternalToken == "" {
log . Warn ( ` The INTERNAL_TOKEN setting is missing from the configuration file: %q, internal API can't work. ` , setting . CustomConf )
http . Error ( w , http . StatusText ( http . StatusForbidden ) , http . StatusForbidden )
return
}
if len ( fields ) != 2 || fields [ 0 ] != "Bearer" || fields [ 1 ] != setting . InternalToken {
log . Debug ( "Forbidden attempt to access internal url: Authorization header: %s" , tokens )
http . Error ( w , http . StatusText ( http . StatusForbidden ) , http . StatusForbidden )
} else {
next . ServeHTTP ( w , req )
}
} )
}
// bind binding an obj to a handler
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
2 years ago
func bind [ T any ] ( _ T ) any {
return func ( ctx * context . PrivateContext ) {
theObj := new ( T ) // create a new form obj for every request but not use obj directly
binding . Bind ( ctx . Req , theObj )
web . SetForm ( ctx , theObj )
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
2 years ago
}
}
// Routes registers all internal APIs routes to web application.
// These APIs will be invoked by internal commands for example `gitea serv` and etc.
func Routes ( ) * web . Route {
r := web . NewRoute ( )
r . Use ( context . PrivateContexter ( ) )
r . Use ( CheckInternalToken )
// Log the real ip address of the request from SSH is really helpful for diagnosing sometimes.
// Since internal API will be sent only from Gitea sub commands and it's under control (checked by InternalToken), we can trust the headers.
r . Use ( chi_middleware . RealIP )
r . Post ( "/ssh/authorized_keys" , AuthorizedPublicKeyByContent )
r . Post ( "/ssh/{id}/update/{repoid}" , UpdatePublicKeyInRepo )
r . Post ( "/ssh/log" , bind ( private . SSHLogOption { } ) , SSHLog )
r . Post ( "/hook/pre-receive/{owner}/{repo}" , RepoAssignment , bind ( private . HookOptions { } ) , HookPreReceive )
r . Post ( "/hook/post-receive/{owner}/{repo}" , context . OverrideContext , bind ( private . HookOptions { } ) , HookPostReceive )
r . Post ( "/hook/proc-receive/{owner}/{repo}" , context . OverrideContext , RepoAssignment , bind ( private . HookOptions { } ) , HookProcReceive )
r . Post ( "/hook/set-default-branch/{owner}/{repo}/{branch}" , RepoAssignment , SetDefaultBranch )
r . Get ( "/serv/none/{keyid}" , ServNoCommand )
r . Get ( "/serv/command/{keyid}/{owner}/{repo}" , ServCommand )
r . Post ( "/manager/shutdown" , Shutdown )
r . Post ( "/manager/restart" , Restart )
r . Post ( "/manager/reload-templates" , ReloadTemplates )
r . Post ( "/manager/flush-queues" , bind ( private . FlushOptions { } ) , FlushQueues )
r . Post ( "/manager/pause-logging" , PauseLogging )
r . Post ( "/manager/resume-logging" , ResumeLogging )
r . Post ( "/manager/release-and-reopen-logging" , ReleaseReopenLogging )
r . Post ( "/manager/set-log-sql" , SetLogSQL )
r . Post ( "/manager/add-logger" , bind ( private . LoggerOptions { } ) , AddLogger )
Rewrite logger system (#24726)
## ⚠️ Breaking
The `log.<mode>.<logger>` style config has been dropped. If you used it,
please check the new config manual & app.example.ini to make your
instance output logs as expected.
Although many legacy options still work, it's encouraged to upgrade to
the new options.
The SMTP logger is deleted because SMTP is not suitable to collect logs.
If you have manually configured Gitea log options, please confirm the
logger system works as expected after upgrading.
## Description
Close #12082 and maybe more log-related issues, resolve some related
FIXMEs in old code (which seems unfixable before)
Just like rewriting queue #24505 : make code maintainable, clear legacy
bugs, and add the ability to support more writers (eg: JSON, structured
log)
There is a new document (with examples): `logging-config.en-us.md`
This PR is safer than the queue rewriting, because it's just for
logging, it won't break other logic.
## The old problems
The logging system is quite old and difficult to maintain:
* Unclear concepts: Logger, NamedLogger, MultiChannelledLogger,
SubLogger, EventLogger, WriterLogger etc
* Some code is diffuclt to konw whether it is right:
`log.DelNamedLogger("console")` vs `log.DelNamedLogger(log.DEFAULT)` vs
`log.DelLogger("console")`
* The old system heavily depends on ini config system, it's difficult to
create new logger for different purpose, and it's very fragile.
* The "color" trick is difficult to use and read, many colors are
unnecessary, and in the future structured log could help
* It's difficult to add other log formats, eg: JSON format
* The log outputer doesn't have full control of its goroutine, it's
difficult to make outputer have advanced behaviors
* The logs could be lost in some cases: eg: no Fatal error when using
CLI.
* Config options are passed by JSON, which is quite fragile.
* INI package makes the KEY in `[log]` section visible in `[log.sub1]`
and `[log.sub1.subA]`, this behavior is quite fragile and would cause
more unclear problems, and there is no strong requirement to support
`log.<mode>.<logger>` syntax.
## The new design
See `logger.go` for documents.
## Screenshot
<details>
![image](https://github.com/go-gitea/gitea/assets/2114189/4462d713-ba39-41f5-bb08-de912e67e1ff)
![image](https://github.com/go-gitea/gitea/assets/2114189/b188035e-f691-428b-8b2d-ff7b2199b2f9)
![image](https://github.com/go-gitea/gitea/assets/2114189/132e9745-1c3b-4e00-9e0d-15eaea495dee)
</details>
## TODO
* [x] add some new tests
* [x] fix some tests
* [x] test some sub-commands (manually ....)
---------
Co-authored-by: Jason Song <i@wolfogre.com>
Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: Giteabot <teabot@gitea.io>
2 years ago
r . Post ( "/manager/remove-logger/{logger}/{writer}" , RemoveLogger )
r . Get ( "/manager/processes" , Processes )
r . Post ( "/mail/send" , SendEmail )
r . Post ( "/restore_repo" , RestoreRepo )
r . Post ( "/actions/generate_actions_runner_token" , GenerateActionsRunnerToken )
return r
}