Authorization System Merge

backend/Cargo.toml

@@ -6,6 +6,7 @@ edition = "2018"
 
 [dependencies]
 rouille = "3.0.0"
+google-signin = "0.3.0"
 diesel = { version = "1.3.3", features = ["mysql"] }
 diesel_migrations = "1.4.0"
 dotenv = "0.13.0"

backend/README.md

@@ -4,12 +4,43 @@ Coded in Rust, manages database manipulation using AJAX requests from frontend.
 ### Dependencies:
 * [Rouille 3.0.0](https://github.com/tomaka/rouille)
 * [Diesel 1.3.3](https://github.com/diesel-rs/diesel)
+* [Google Sign-In 0.3.0](https://github.com/wyyerd/google-signin-rs)
 * [dotenv 0.13.0](https://github.com/sgrif/rust-dotenv)
 * [serde 1.0](https://github.com/serde-rs/serde)
 * [serde_json 1.0](https://github.com/serde-rs/json)
 * [log 0.4](https://github.com/rust-lang-nursery/log)
 * [simplelog](https://github.com/drakulix/simplelog.rs)
 
+### Authentication and Authorization
+
+#### Authentication and Authorization Flow
+1. On the frontend, a sign-in button that redirects to Google sign-in calls `onSignIn()` afterwards to set a cookie for the `id_token` of the logged in user.
+  * That cookie has an expire date, and will delete itself from the browser once that date has passed.
+  * If a user on the frontend prompts an action that attempts to access the `id_token` cookie and it is not present, a login is automatically prompted.
+2. The frontend generates an xmlHTTP request over HTTPS with `id_token` in the header.
+  * Sending the ID token over HTTP exposes the user's token to packet sniffing vulnerabilities, allowing sniffers to impersonate the user by submitting unauthentic requests with the unencrypted token.
+3. The backend attempts authentication before processing the requests (some requests might need authorization, some might not).
+  * The token is sent back to Google's servers with our services information, Google does their own verification and sends back valid user data.
+4. The email is taken from the Google user's data and cross checked with the `users` database.
+  * NOTE: AN EMAIL IS NECESSARY FOR AUTHORIZED REQUESTS
+5. The request is processed and just before execution of the request, the backend checks for authorization on the found user if needed.
+  * A `user_access` request is made to verify authorization
+
+#### Making Authorized API Calls
+
+To make an authorized API call, a valid ID token from Google's sign-in services must be present in the HTTPS request.
+
+Add the following script imports to HTML pages that make requests. 
+
+`<script src="https://apis.google.com/js/platform.js" async defer></script>`
+
+`<script type="text/javascript" src="/access/google_signin.js"></script>`
+
+
+And add the following to JavaScript functions that make xmlHTTP requests
+
+`mlhttp.setRequestHeader("id_token", getID_Token());`
+
 ### API Calls
 
 `GET /users`

backend/diesel.toml

@@ -3,4 +3,4 @@
 # see diesel.rs/guides/configuring-diesel-cli
 
 [print_schema]
-file = "src/schema.rs
+file = "src/schema.rs"

backend/migrations/2019-01-13-203149_create_users/down.sql

@@ -1,2 +1,2 @@
 -- This file should undo anything in `up.sql`
-DROP TABLE users
+DROP TABLE users;

backend/migrations/2019-01-13-203149_create_users/up.sql

@@ -5,4 +5,11 @@ CREATE TABLE users (
   last_name VARCHAR(255) NOT NULL,
   banner_id INT(9) UNSIGNED NOT NULL,
   email VARCHAR(255)
-)
+);
+
+INSERT INTO users (first_name, last_name, banner_id) VALUES ("root", "root", 0);
+UPDATE users
+SET
+  id = 0
+WHERE
+  first_name="root" AND last_name="root" AND banner_id=0 AND id != 0;

backend/migrations/2019-03-08-171503_create_access/down.sql

@@ -0,0 +1,3 @@
+-- This file should undo anything in `up.sql`
+DROP TABLE user_access;
+DROP TABLE access;

backend/migrations/2019-03-08-171503_create_access/up.sql

@@ -0,0 +1,53 @@
+-- Your SQL goes here
+CREATE TABLE access (
+  id SERIAL PRIMARY KEY,
+  access_name VARCHAR(255) NOT NULL
+);
+
+INSERT INTO access (access_name) VALUES
+  ("RootAccess"),
+
+  ("GetUsers"),
+  ("CreateUsers"),
+  ("UpdateUsers"),
+  ("DeleteUsers"),
+
+  ("GetAccess"),
+  ("CreateAccess"),
+  ("UpdateAccess"),
+  ("DeleteAccess"),
+
+  ("GetUserAccess"),
+  ("CreateUserAccess"),
+  ("UpdateUserAccess"),
+  ("DeleteUserAccess"),
+
+  ("GetChemical"),
+  ("CreateChemical"),
+  ("UpdateChemical"),
+  ("DeleteChemical"),
+
+  ("GetChemicalInventory"),
+  ("CreateChemicalInventory"),
+  ("UpdateChemicalInventory"),
+  ("DeleteChemicalInventory");
+
+CREATE TABLE user_access (
+  permission_id SERIAL PRIMARY KEY,
+  access_id BIGINT UNSIGNED NOT NULL,
+  user_id BIGINT UNSIGNED NOT NULL,
+  FOREIGN KEY (access_id)
+    REFERENCES access(id)
+    ON DELETE CASCADE
+    ON UPDATE CASCADE,
+  FOREIGN KEY (user_id)
+    REFERENCES users(id)
+    ON DELETE CASCADE
+    ON UPDATE CASCADE,
+  permission_level VARCHAR(255)
+);
+
+INSERT INTO user_access(access_id, user_id, permission_level)
+    SELECT (select access.id as access_id from access where access.name = "RootAccess"),
+           (select users.id as user_id from users where user.id = 0),
+           (select "RootAccess" as permission_level);

backend/migrations/2019-04-15-150025_chemicals/down.sql

@@ -0,0 +1,3 @@
+-- This file should undo anything in `up.sql`
+DROP chemical_inventory;
+DROP chemical;