backend

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