Refactor docs (#13275)

* First pass

Signed-off-by: jolheiser <john.olheiser@gmail.com>

* More changes

Signed-off-by: jolheiser <john.olheiser@gmail.com>

* Redirects

Signed-off-by: jolheiser <john.olheiser@gmail.com>

docs/content/doc/developers/api-usage.en-us.md

@@ -0,0 +1,106 @@
+---
+date: "2018-06-24:00:00+02:00"
+title: "API Usage"
+slug: "api-usage"
+weight: 40
+toc: true
+draft: false
+menu:
+  sidebar:
+    parent: "developers"
+    name: "API Usage"
+    weight: 40
+    identifier: "api-usage"
+---
+
+# Gitea API Usage
+
+## Enabling/configuring API access
+
+By default, `ENABLE_SWAGGER` is true, and
+`MAX_RESPONSE_ITEMS` is set to 50.  See [Config Cheat
+Sheet](https://docs.gitea.io/en-us/config-cheat-sheet/) for more
+information.
+
+## Authentication via the API
+
+Gitea supports these methods of API authentication:
+
+- HTTP basic authentication
+- `token=...` parameter in URL query string
+- `access_token=...` parameter in URL query string
+- `Authorization: token ...` header in HTTP headers
+
+All of these methods accept the same API key token type.  You can
+better understand this by looking at the code -- as of this writing,
+Gitea parses queries and headers to find the token in
+[modules/auth/auth.go](https://github.com/go-gitea/gitea/blob/6efdcaed86565c91a3dc77631372a9cc45a58e89/modules/auth/auth.go#L47).
+
+You can create an API key token via your Gitea installation's web interface:
+`Settings | Applications | Generate New Token`.
+
+### OAuth2
+
+Access tokens obtained from Gitea's [OAuth2 provider](https://docs.gitea.io/en-us/oauth2-provider) are accepted by these methods:
+
+- `Authorization bearer ...` header in HTTP headers
+- `token=...` parameter in URL query string
+- `access_token=...` parameter in URL query string
+
+### More on the `Authorization:` header
+
+For historical reasons, Gitea needs the word `token` included before
+the API key token in an authorization header, like this:
+
+```
+Authorization: token 65eaa9c8ef52460d22a93307fe0aee76289dc675
+```
+
+In a `curl` command, for instance, this would look like:
+
+```
+curl -X POST "http://localhost:4000/api/v1/repos/test1/test1/issues" \
+    -H "accept: application/json" \
+    -H "Authorization: token 65eaa9c8ef52460d22a93307fe0aee76289dc675" \
+    -H "Content-Type: application/json" -d "{ \"body\": \"testing\", \"title\": \"test 20\"}" -i
+```
+
+As mentioned above, the token used is the same one you would use in
+the `token=` string in a GET request.
+
+## API Guide:
+
+API Reference guide is auto-generated by swagger and available on:
+    `https://gitea.your.host/api/swagger`
+    or on
+    [gitea demo instance](https://try.gitea.io/api/swagger)
+
+
+## Listing your issued tokens via the API
+
+As mentioned in
+[#3842](https://github.com/go-gitea/gitea/issues/3842#issuecomment-397743346),
+`/users/:name/tokens` is special and requires you to authenticate
+using BasicAuth, as follows:
+
+### Using basic authentication:
+
+```
+$ curl --request GET --url https://yourusername:yourpassword@gitea.your.host/api/v1/users/yourusername/tokens
+[{"name":"test","sha1":"..."},{"name":"dev","sha1":"..."}]
+```
+
+As of v1.8.0 of Gitea, if using basic authentication with the API and your user has two factor authentication enabled, you'll need to send an additional header that contains the one time password (6 digit rotating token). An example of the header is `X-Gitea-OTP: 123456` where `123456` is where you'd place the code from your authenticator. Here is how the request would look like in curl:
+
+```
+$ curl -H "X-Gitea-OTP: 123456" --request GET --url https://yourusername:yourpassword@gitea.your.host/api/v1/users/yourusername/tokens
+```
+
+## Sudo
+
+The API allows admin users to sudo API requests as another user. Simply add either a `sudo=` parameter or `Sudo:` request header with the username of the user to sudo.
+
+## SDKs
+
+* [Official go-sdk](https://gitea.com/gitea/go-sdk)
+* [more](https://gitea.com/gitea/awesome-gitea#user-content-sdk)

docs/content/doc/developers/api-usage.zh-cn.md

@@ -0,0 +1,71 @@
+---
+date: "2018-06-24:00:00+02:00"
+title: "API 使用指南"
+slug: "api-usage"
+weight: 40
+toc: true
+draft: false
+menu:
+  sidebar:
+    parent: "developers"
+    name: "API 使用指南"
+    weight: 40
+    identifier: "api-usage"
+---
+
+# Gitea API 使用指南
+
+## 开启/配置 API 访问
+
+通常情况下， `ENABLE_SWAGGER` 默认开启并且参数 `MAX_RESPONSE_ITEMS` 默认为 50。您可以从 [Config Cheat
+Sheet](https://docs.gitea.io/en-us/config-cheat-sheet/) 中获取更多配置相关信息。
+
+## 通过 API 认证
+
+Gitea 支持以下几种 API 认证方式：
+
+- HTTP basic authentication 方式
+- 通过指定 `token=...` URL 查询参数方式
+- 通过指定 `access_token=...` URL 查询参数方式
+- 通过指定 `Authorization: token ...` HTTP header 方式
+
+以上提及的认证方法接受相同的 apiKey token 类型，您可以在编码时通过查阅代码更好地理解这一点。
+Gitea 调用解析查询参数以及头部信息来获取 token 的代码可以在 [modules/auth/auth.go](https://github.com/go-gitea/gitea/blob/6efdcaed86565c91a3dc77631372a9cc45a58e89/modules/auth/auth.go#L47) 中找到。
+
+您可以通过您的 gitea web 界面来创建 apiKey token：
+`Settings | Applications | Generate New Token`.
+
+### 关于 `Authorization:` header
+
+由于一些历史原因，Gitea 需要在 header 的 apiKey token 里引入前缀 `token`，类似于如下形式：
+
+```
+Authorization: token 65eaa9c8ef52460d22a93307fe0aee76289dc675
+```
+
+以 `curl` 命令为例，它会以如下形式携带在请求中：
+
+```
+curl -X POST "http://localhost:4000/api/v1/repos/test1/test1/issues" \
+    -H "accept: application/json" \
+    -H "Authorization: token 65eaa9c8ef52460d22a93307fe0aee76289dc675" \
+    -H "Content-Type: application/json" -d "{ \"body\": \"testing\", \"title\": \"test 20\"}" -i
+```
+
+正如上例所示，您也可以在 GET 请求中使用同一个 token 并以 `token=` 的查询参数形式携带 token 来进行认证。
+
+## 通过 API 列出您发布的令牌
+
+`/users/:name/tokens` 是一个特殊的接口，需要您使用 basic authentication 进行认证，具体原因在 issue 中
+[#3842](https://github.com/go-gitea/gitea/issues/3842#issuecomment-397743346) 有所提及，使用方法如下所示：
+
+### 使用 Basic authentication 认证：
+
+```
+$ curl --request GET --url https://yourusername:yourpassword@gitea.your.host/api/v1/users/yourusername/tokens
+[{"name":"test","sha1":"..."},{"name":"dev","sha1":"..."}]
+```
+
+## 使用 Sudo 方式请求 API
+
+此 API 允许管理员借用其他用户身份进行 API 请求。只需在请求中指定查询参数 `sudo=` 或是指定 header 中的 `Sudo:` 为需要使用的用户 username 即可。

docs/content/doc/developers/integrations.en-us.md

@@ -0,0 +1,26 @@
+---
+date: "2019-04-15T17:29:00+08:00"
+title: "Integrations"
+slug: "integrations"
+weight: 40
+toc: true
+draft: false
+menu:
+  sidebar:
+    parent: "developers"
+    name: "Integrations"
+    weight: 65
+    identifier: "integrations"
+---
+
+# Integrations
+
+Gitea has a wonderful community of third-party integrations, as well as first-class support in various other 
+projects.
+
+We are curating a list over at [awesome-gitea](https://gitea.com/gitea/awesome-gitea) to track these!
+
+If you are looking for [CI/CD](https://gitea.com/gitea/awesome-gitea#devops), 
+an [SDK](https://gitea.com/gitea/awesome-gitea#sdk), 
+or even some extra [themes](https://gitea.com/gitea/awesome-gitea#themes), 
+you can find them listed in the [awesome-gitea](https://gitea.com/gitea/awesome-gitea) repository!

docs/content/doc/developers/migrations.en-us.md

@@ -0,0 +1,41 @@
+---
+date: "2019-04-15T17:29:00+08:00"
+title: "Migrations Interfaces"
+slug: "migrations-interfaces"
+weight: 30
+toc: true
+draft: false
+menu:
+  sidebar:
+    parent: "developers"
+    name: "Migrations Interfaces"
+    weight: 55
+    identifier: "migrations-interfaces"
+---
+
+# Migration Features
+
+Complete migrations were introduced in Gitea 1.9.0. It defines two interfaces to support migrating
+repository data from other git host platforms to Gitea or, in the future, migrating Gitea data to other
+git host platforms.  
+Currently, migrations from Github, Gitlab, and other Gitea instances are implemented.
+
+First of all, Gitea defines some standard objects in packages [modules/migrations/base](https://github.com/go-gitea/gitea/tree/master/modules/migrations/base).  
+They are `Repository`, `Milestone`, `Release`, `ReleaseAsset`, `Label`, `Issue`, `Comment`, `PullRequest`, `Reaction`, `Review`, `ReviewComment`.
+
+## Downloader Interfaces
+
+To migrate from a new git host platform, there are two steps to be updated.
+
+- You should implement a `Downloader` which will be used to get repository information.
+- You should implement a `DownloaderFactory` which will be used to detect if the URL matches and create the above `Downloader`.
+   - You'll need to register the `DownloaderFactory` via `RegisterDownloaderFactory` on `init()`.
+
+You can find these interfaces in [downloader.go](https://github.com/go-gitea/gitea/blob/master/modules/migrations/base/downloader.go).
+
+## Uploader Interface
+
+Currently, only a `GiteaLocalUploader` is implemented, so we only save downloaded
+data via this `Uploader` to the local Gitea instance. Other uploaders are not supported at this time.
+
+You can find these interfaces in [uploader.go](https://github.com/go-gitea/gitea/blob/master/modules/migrations/base/uploader.go).

docs/content/doc/developers/oauth2-provider.md

@@ -0,0 +1,92 @@
+---
+date: "2019-04-19:44:00+01:00"
+title: "OAuth2 provider"
+slug: "oauth2-provider"
+weight: 41
+toc: true
+draft: false
+menu:
+  sidebar:
+    parent: "developers"
+    name: "OAuth2 Provider"
+    weight: 41
+    identifier: "oauth2-provider"
+---
+
+
+# OAuth2 provider
+
+Gitea supports acting as an OAuth2 provider to allow third party applications to access its resources with the user's consent. This feature is available since release 1.8.0.
+
+## Endpoints
+
+
+Endpoint               | URL
+-----------------------|----------------------------
+Authorization Endpoint | `/login/oauth/authorize`
+Access Token Endpoint  | `/login/oauth/access_token`
+
+
+## Supported OAuth2 Grants
+
+At the moment Gitea only supports the [**Authorization Code Grant**](https://tools.ietf.org/html/rfc6749#section-1.3.1) standard with additional support of the [Proof Key for Code Exchange (PKCE)](https://tools.ietf.org/html/rfc7636) extension.
+ 
+
+To use the Authorization Code Grant as a third party application it is required to register a new application via the "Settings" (`/user/settings/applications`) section of the settings.
+
+## Scopes
+
+Currently Gitea does not support scopes (see [#4300](https://github.com/go-gitea/gitea/issues/4300)) and all third party applications will be granted access to all resources of the user and his/her organizations.
+
+## Example
+
+**Note:** This example does not use PKCE.
+
+1. Redirect to user to the authorization endpoint in order to get his/her consent for accessing the resources:
+
+```curl
+https://[YOUR-GITEA-URL]/login/oauth/authorize?client_id=CLIENT_ID&redirect_uri=REDIRECT_URI& response_type=code&state=STATE
+``` 
+
+The `CLIENT_ID` can be obtained by registering an application in the settings. The `STATE` is a random string that will be send back to your application after the user authorizes. The `state` parameter is optional but should be used to prevent CSRF attacks.
+
+
+![Authorization Page](/authorize.png)
+
+The user will now be asked to authorize your application. If they authorize it, the user will be redirected to the `REDIRECT_URL`, for example:
+
+```curl
+https://[REDIRECT_URI]?code=RETURNED_CODE&state=STATE
+```
+
+2. Using the provided `code` from the redirect, you can request a new application and refresh token. The access token endpoints accepts POST requests with  `application/json` and `application/x-www-form-urlencoded` body, for example:
+
+```curl
+POST https://[YOUR-GITEA-URL]/login/oauth/access_token
+```
+
+```json
+{
+	"client_id": "YOUR_CLIENT_ID",
+	"client_secret": "YOUR_CLIENT_SECRET",
+	"code": "RETURNED_CODE",
+	"grant_type": "authorization_code",
+	"redirect_uri": "REDIRECT_URI"
+}
+```
+
+Response:
+```json
+{  
+"access_token":"eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJnbnQiOjIsInR0IjowLCJleHAiOjE1NTUxNzk5MTIsImlhdCI6MTU1NTE3NjMxMn0.0-iFsAwBtxuckA0sNZ6QpBQmywVPz129u75vOM7wPJecw5wqGyBkmstfJHAjEOqrAf_V5Z-1QYeCh_Cz4RiKug",  
+"token_type":"bearer",  
+"expires_in":3600,  
+"refresh_token":"eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJnbnQiOjIsInR0IjoxLCJjbnQiOjEsImV4cCI6MTU1NzgwNDMxMiwiaWF0IjoxNTU1MTc2MzEyfQ.S_HZQBy4q9r5SEzNGNIoFClT43HPNDbUdHH-GYNYYdkRfft6XptJBkUQscZsGxOW975Yk6RbgtGvq1nkEcklOw"  
+}
+```
+
+The `CLIENT_SECRET` is the unique secret code generated for this application. Please note that the secret will only be visible after you created/registered the application with Gitea and cannot be recovered. If you lose the secret you must regenerate the secret via the application's settings.
+
+The `REDIRECT_URI` in the `access_token` request must match the `REDIRECT_URI` in the `authorize` request.
+
+3. Use the  `access_token` to make [API requests](https://docs.gitea.io/en-us/api-usage#oauth2) to access the user's resources.