README
¶
ARFID Encyclopedia backend
The backend API for the ARFID Encyclopedia web app project
main.go
This file bootstrap the server, housing the request router and the main function
At the moment main() contains some dummy data for testing purposes
api.go
api.go defines how the different API routes should behave as per this table:
| Endpoint | method | function | description |
|---|---|---|---|
/ |
GET | homePage |
This is temporary and just lets a client know the server is up and operational without returning any data |
/foods |
GET | returnAll |
Returns data on all food in the database, as of right now the only data in the program is defined in main and is, again, temporary |
/food |
GET | createNewFood |
Adds a new food to the database |
/food/{name} |
POST | returnByName |
Gets a given foods data |
/food/edit/ |
POST | editFood |
Post a food object to update the food in the db |
/login |
POST | login |
Brokers the user an API token to access certain api endpoints. The way in which all the user stuff is done needs to be fleshed out |
auth.go
Manages authorization of users
This API uses JWT or javascript web tokens to ensure only users of the correct access level can access certain functions of the API. The details of this can be viewed here
Registering Users
Users are registered through a post request sent to /register following the structure of the user struct. The request is then unmarshaled and added to the database. The user can then log in normally.
Users
For testing purposes an admin account is available under: admin, adminpassword
A user will look like this:
type user struct {
ID string `json:"id"`
Username string `json:"username"`
PasswordHash string `json:"passHash"`
AccessLevel int `json:"accessLevel"`
}
with IDs being unique user identifiers generated by satori/go.uuid
Passwords are hashed with SHA1 before they leave the client and the server only deals with hashed passwords
Making a map of usernames to uuids would probably be smart as scribble is not able to gather db entries by field alone (although that probably wouldn't be hard to implement)
An access level dictates what a user can and cannot do
Access Levels
Access levels dictate which users are able to access what resources as described below:
| Access level | Alias | Description |
|---|---|---|
| 0 | ANON | The user hasn't logged in and has no rights to add edit or remove content |
| 1 | USER | The user has logged in and has access to adding editing and removing but the actions must be approved by a mod or admin |
| 2 | MOD | Mods have the right to approve edits and add new foods |
| 3 | ADMIN | Admins can do everything a mod can do plus the ability do delete foods |
database.go
The database will use scribble mainly as it is very light
There will be 2 collections:
- Users
- Foods
Foods
Foods are described under this struct
type food struct {
Name string `json:"Name"`
Category string `json:"Category"`
Visual string `json:"Visual"`
Texture string `json:"Texture"`
Smell string `json:"Smell"`
Taste string `json:"Taste"`
Nutrients []string `json:"Nutrients"`
}
They follow the format dictated in the google doc
Documentation
¶
There is no documentation for this package.
Source Files