-
Notifications
You must be signed in to change notification settings - Fork 44
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
3 changed files
with
37 additions
and
13 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -68,55 +68,79 @@ knex migrate:latest --env production | |
For the sake of security, you should immeidately change the default admin user username and password upon installation. This can be done by `login` as the admin user and then `update` the username and password. The default username and password for the admin user are `[email protected]` and `pleaseChangePassword`, respectively. | ||
4. Run [shadowsocks-restful-api](https://github.com/shadowsocks/shadowsocks-restful-api) on every server acting as a shadowsocks node. | ||
5. Have fun! | ||
Admininistration and user operations should be intuitive, or feel free to leave feedback otherwise. | ||
## Rate limit | ||
You may enforce a rate limit by setting the maximum number of requests allowed within 15-minute window from the same ip address. Requests exceeding the limit will be refused with HTTP status code `429 Too Many Requests`. This setting can be done by add the following config to the `.env` file. | ||
``` | ||
RATE_LIMIT = 50 | ||
``` | ||
 | ||
Change the number to your choice. | ||
4. Run [shadowsocks-restful-api](https://github.com/shadowsocks/shadowsocks-restful-api) on every server acting as a shadowsocks node. | ||
## Usage | ||
### Admin | ||
Once logged in as the admin, the menu looks like: | ||
 | ||
The admin may choose to navigate to: | ||
1. Managing servers. A `server` is a machine acting as a shadowsocks exit point. A `server` may have more than one `node`. Admin has to provide its IP address or domain name when adding a `server`. Admin may add, edit, and delete a `server`. Note that a `server` cannot be deleted if a `node` has been created using this `server`. Admin has to delete all its `nodes` before successfully deleting the `server`. | ||
The admin may also check and navigate to any `nodes`, `accounts`, or `users` using a `server`, and check total `traffic` that a `server` has served. | ||
 | ||
2. Managing nodes. A `node` is a virtual shadowsocks exit point. The difference between `server` and `node` is that a `server` is an indpendent machine where a `node` is a logical machine whose functionality relies on `server`. There can be multiple `nodes` residing on a single `server`. From users' perspective, `nodes` using the same `server` are different shadowsocks exit points. Before adding a `node`, the underlying `server` has to be added into the system first. When adding a new `node`, the admin has to select a server, give it a descriptive name, and provide its managing port, and managing password. Admin may also edit and delete a `node`. Note that a `node` cannot be deleted if an `account` has been created using this `node`. Admin has to delete all its `accounts` before successfully deleting the `node`. | ||
The admin may also check and navigate to the `server` that a `node` belongs to, any `accounts` or `users` using a `node`, and check total `traffic` that a `node` has serverd. | ||
 | ||
3. Managing products. A `product` is a shadowsocks service subscription. When adding a new `product`, the admin has to give it a descriptive name, select a period of subscription, and provide traffic allowance for the period. The admin may also edit and delete a `product`. Note that a `product` cannot be deleted if a `request` has been created on this `product` (regardless of whether the `request` is aproved or not). | ||
The admin may also check and navigate to any `accounts`, `users`, or `requests` relating to a `product`. | ||
 | ||
4. Managing users. A `user` is a person using the shadowsocks service provided. The system is not open for registration, due to its nature of internal use. A new `user` has to be added by the admin into the system. When adding a new `user`, the admin has to provide an email and initial password. The admin may also edit and delete a `user`. Note that a `user` cannot be deleted if a `request` has been created for this this `user` (regardless of whether the `request` is aproved or not). | ||
The admin may also check and navigate to any `accounts`, `requests`, `products`, `nodes`, or `servers` relating to a `user`. | ||
 | ||
5. Managing requests. A `request` is made by the admin for a `user` on a `product`, or is made by a `user` on a `product`. Before making a `request`, its underlying `user` and `product` have been added into the system. It requests for a shadowsocks service. The admin may choose to approve a `request`. Upon approval, the system will create one `account` on every `node` that the system has. These `accounts` will allow the `user` to use the specified shadowsocks service. The `account` information will be shown when the `user` login the system. | ||
The admin may also check and navigate to any `accounts`, `product`, or `user`, and check total `traffic` relating to a `request`. | ||
 | ||
6. Managing accounts. An `account` is a shadowsocks account containing all information needed for its `user` to use the shadowsocks service. The admin may manually add a new `account` by selecting a `user` and a `request`. Before adding an `account`, its underlying `user` and `request` have to be added into the system first. The admin may also delete an `account`. Note that an `account` cannot be deleted if `traffic` information of the `account` has been created by the system. | ||
The admin may also check and navigate to the `server`, `node`, `product`, `user`, `request`, and check total `traffic` relating to an `account`. In addition, the admin may choose to show a QR code encoding the account information. | ||
 | ||
### Users | ||
Once logged in as a user, the menu looks like: | ||
 | ||
A user may choose to navigate to: | ||
1. Showing their accounts. A `user` check the latest `traffic` of any of their own `accounts`. They may also get the QR code displayed for any of their `accounts`. | ||
 | ||
2. Showing all products. A `user` may choose the make a `request` on a `product`. Once a `request` is created, it has to be approved by the admin before `accounts` created by the system. | ||
 | ||
3. Showing their requests. A `user` may check and navigate to any `accounts`, and check the `traffic` relating to a `request`. | ||
 | ||
## Rate limit | ||
You may enforce a rate limit by setting the maximum number of requests allowed within 15-minute window from the same ip address. Requests exceeding the limit will be refused with HTTP status code `429 Too Many Requests`. This setting can be done by add the following config to the `.env` file. | ||
``` | ||
RATE_LIMIT = 50 | ||
``` | ||
Change the number to your choice. | ||
## Bug report, feature request, and feedback | ||
Bug report, feature request, and feedback is welcome. Bugs have a high priority to get addressed. Feature requests and improvement feedback will be considered depending on their popularity and importance. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.