mirror of
https://github.com/zkldi/Tachi.git
synced 2026-10-04 21:08:09 +03:00
feat: move urls
This commit is contained in:
zkldi
@@ -19,4 +19,4 @@ lamps for the game.
|
||||
|
||||
*****
|
||||
|
||||
This documentation is unfinished. It is probably easier for you to [just read the config.ts file](https://github.com/TNG-dev/Tachi/tree/staging/common/src/config/config.ts)
|
||||
This documentation is unfinished. It is probably easier for you to [just read the config.ts file](https://github.com/zkldi/Tachi/tree/main/common/src/config/config.ts)
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Codebase Overview
|
||||
|
||||
This part of the documentation is for the [Tachi-Server](https://github.com/TNG-dev/Tachi/tree/staging/server) codebase.
|
||||
This part of the documentation is for the [Tachi-Server](https://github.com/zkldi/Tachi/tree/main/server) codebase.
|
||||
|
||||
## Codebase Documentation vs. Code Documentation
|
||||
|
||||
|
||||
@@ -1,25 +1,7 @@
|
||||
# Branching Model
|
||||
|
||||
`Tachi` maintains two long-running branches, and uses a remarkably simple model for merging.
|
||||
|
||||
*****
|
||||
|
||||
## Branches
|
||||
|
||||
### `release/v2.x`
|
||||
|
||||
This is the current release version of `Tachi`, and is automatically deployed into production.
|
||||
|
||||
!!! note
|
||||
Our CI automatically selects the largest value of `x` to use as the production
|
||||
branch.
|
||||
|
||||
### `staging`
|
||||
|
||||
This is the development branch, and is where pull requests
|
||||
are merged to. This will be automatically deployed to the Tachi staging servers
|
||||
for further testing.
|
||||
`main` is the current release version of `Tachi`, and is automatically deployed into production.
|
||||
|
||||
## How should I PR?
|
||||
|
||||
You should submit your PRs for `staging`. If this change should be backported into production, note that in your PR.
|
||||
You should submit your PRs for `main`.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Database Seeds
|
||||
|
||||
Tachi tracks the contents of its songs and charts in something called the [Database Seeds](https://github.com/TNG-dev/Tachi/tree/staging/database-seeds).
|
||||
Tachi tracks the contents of its songs and charts in something called the [Database Seeds](https://github.com/zkldi/Tachi/tree/main/database-seeds).
|
||||
|
||||
The databases in question aren't (normally) altered by the server code. We essentially overload git and its CI tools to version control parts of our database.
|
||||
|
||||
@@ -12,9 +12,7 @@ They also include all Folder Documents, Table Documents and BMS Course Documents
|
||||
|
||||
## Synchronisation
|
||||
|
||||
When pushes are made to `staging` (the main branch), our running staging servers will automatically update to that new bit of data.
|
||||
|
||||
When pushes are made to `release/2.X`, our running *production* servers will automatically update in the same way.
|
||||
When pushes are made to `main`, our running production servers will automatically update to that new bit of data.
|
||||
|
||||
## Why bother?
|
||||
|
||||
|
||||
@@ -10,11 +10,11 @@ site, and results in the user downloading a file, or copying a string.
|
||||
## Outline
|
||||
|
||||
!!! note
|
||||
This documentation uses `bokutachi.xyz` as the example site. You should
|
||||
This documentation uses `boku.tachi.ac` as the example site. You should
|
||||
replace this with the instance of Tachi you're pointing against, if it
|
||||
is different.
|
||||
|
||||
- You navigate the user to `https://bokutachi.xyz/client-file-flow/YOUR_CLIENT_ID`.
|
||||
- You navigate the user to `https://boku.tachi.ac/client-file-flow/YOUR_CLIENT_ID`.
|
||||
- They are asked if they want to create an API Key for your client.
|
||||
- If they select yes, an API Key is created for your client, and depending on your client parameters, they get it.
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ We use an *almost* standard OAuth2 flow, but with the added react-app caveat of
|
||||
In this scenario, we have two users, user A, who is making a service that integrates with Tachi, and user B, who wants to link integrate their service with their tachi profile.
|
||||
|
||||
!!! info
|
||||
In this example we will use `bokutachi.xyz` as the Tachi site name.
|
||||
In this example we will use `boku.tachi.ac` as the Tachi site name.
|
||||
|
||||
- An OAuth2 client is created by user A.
|
||||
|
||||
@@ -35,20 +35,20 @@ This client will have the following properties.
|
||||
|
||||
- User B wants to link their account to this service, and must click on an auth link on Tachi.
|
||||
|
||||
In the `tachi-client`, this link is `https://bokutachi.xyz/oauth/request-auth?clientID={clientID}`
|
||||
In the `tachi-client`, this link is `https://boku.tachi.ac/oauth/request-auth?clientID={clientID}`
|
||||
|
||||
EpicGames would show this link to the user, and they would click it.
|
||||
|
||||
While on Tachi, they are presented with the option to accept linking with `clientID`, or decline it.
|
||||
|
||||
- If they accept, `tachi-client` will make a POST request to `https://bokutachi.xyz/api/v1/oauth/create-code`, which will create an intermediate authorisation code.
|
||||
- If they accept, `tachi-client` will make a POST request to `https://boku.tachi.ac/api/v1/oauth/create-code`, which will create an intermediate authorisation code.
|
||||
|
||||
The user and this authorisation code are then taken to the `redirectUri` defined in the client. In our case, this means they are taken to
|
||||
`https://epicgames.example.com/tachi-auth-callback?code=SOME_INTERMEDIATE_TOKEN`
|
||||
|
||||
This token **IS NOT** an API Key, but rather an intermediate value that needs to then be converted up.
|
||||
|
||||
EpicGames would now have to take this token and make a POST request to `https://bokutachi.xyz/api/v1/oauth/token`, with their client secret and the intermediate token.
|
||||
EpicGames would now have to take this token and make a POST request to `https://boku.tachi.ac/api/v1/oauth/token`, with their client secret and the intermediate token.
|
||||
|
||||
This POST request will then return the API Key EpicGames wants! The user can then be redirected by EpicGames to wherever they want.
|
||||
|
||||
|
||||
@@ -393,7 +393,7 @@ interface CDN_CONFIG: {
|
||||
|
||||
#### WEB_LOCATION
|
||||
|
||||
Configures a URL to redirect users to when returning CDN contents. This could be something like `cdn.bokutachi.xyz`.
|
||||
Configures a URL to redirect users to when returning CDN contents. This could be something like `cdn.boku.tachi.ac`.
|
||||
|
||||
#### SAVE_LOCATION
|
||||
|
||||
|
||||
@@ -121,7 +121,7 @@ The folders here **MUST** be 1:1 with the endpoints
|
||||
on the server. For example, the implementation of
|
||||
|
||||
```
|
||||
https://bokutachi.xyz/api/v1/foo/bar
|
||||
https://boku.tachi.ac/api/v1/foo/bar
|
||||
```
|
||||
|
||||
**MUST** be found at `src/server/router/api/v1/foo/bar/router.ts`
|
||||
|
||||
Reference in New Issue
Block a user