From a61d08ec602443f60c4e1a44470b0b7ddf0a67bf Mon Sep 17 00:00:00 2001 From: Soumya Ray Date: Sat, 2 Jun 2018 13:51:20 +0800 Subject: [PATCH] Update validation and policies --- README.md | 2 +- descriptions/070_policies_validation.md | 50 ++++++++++++------------- 2 files changed, 26 insertions(+), 26 deletions(-) diff --git a/README.md b/README.md index 08608e0..82794de 100644 --- a/README.md +++ b/README.md @@ -14,7 +14,7 @@ Follow the activities below as the semester progresses. - [F: User Authentication and Sessions](descriptions/050_authenticate_sessions.md) - [G: Secure Session](descriptions/055_secure_sessions.md) - [H: Token Based Authorization](descriptions/060_token_authorization.md) -- [I: Policies and Validation](descriptions/070_policies_validation_ssl.md) +- [I: Policies and Validation](descriptions/070_policies_validation.md) - [J: OAuth Protocol and Single-Table Inheritance](descriptions/090_oauth_protocol.md) - [K: Signed Clients and XSS Prevention](descriptions/100_client_side_security.md) - [L: Final Presentations](descriptions/110_final_presentation.md) diff --git a/descriptions/070_policies_validation.md b/descriptions/070_policies_validation.md index de59b1b..1d166f3 100644 --- a/descriptions/070_policies_validation.md +++ b/descriptions/070_policies_validation.md @@ -1,30 +1,30 @@ # Policies and Validation This week we will create centralized resource policies, and validate user input coming from web forms. See the latest version of our demo project: -- [Web API: auth_policy](https://github.com/ISS-Security/configshare-api/tree/6_auth_policy) -- [Web App: authorized_access](https://github.com/ISS-Security/configshare-app/tree/4_policy_validation) +1. Web App: Start creating "models" in your web application +- The `models/` folder can hold objects that convert incoming API data (arrays/hashes) back into native objects +- The demo app in class creates models for `Project`, `Projects`, `Document`, `User`, and `Session` +1. Web App: Validating Form input +- Use the `dry-validation` gem to create validation schema for your views + - Every view should have a unique schema defined by a *form object* in a new `/forms` directory + - Create custom rules if you need to compare two or more input fields + - Choose between using `dry-validation`'s messages and creating custom error messages +- Use form objects in your controllers + - Pass your `params` directly to your form objects + - Check if form validation is a `success?` + - Pass form object (not params) to service object if needed 1. Formal Policies - - API: Create policy objects in a `/policies` folder of your API - - Create at least one policy object per resource (e.g., 'ProjectPolicy', 'ConfigFilePolicy', etc.) - - Initialize policy objects with appropriate model objects (e.g., account seeking to access resource, particular resource) - - Create true/false predicate methods check for key actions (creation/deletion/updating/viewing, etc.) - - Make your predicate methods readable by using descriptive private helper methods - - Use your policy objects in each API resource route to check authorization of agent - - API: Create policy scope objects - - Scope objects should return lists of all relevant objects for a given action (e.g., `viewable`) and agents (e.g., `current_account`) - - Scope objects could evaluate permission of account requesting access - - Use your policy scope objects to retrieve list of objects to return on index routes (e.g., `/api/v1/accounts/:id/projects`) - - API + Web App: Policy summaries - - API: Create a `summary` method for each policy object that returns a hash of all predicate names and results - - API: Routes that return a resource should return a jsonified summary of its policy for the given account - - Web App: Forms should determine authorization to show links/buttons/resources based on policy summaries returned by API -3. Web App: Validating Form input - - Use the `dry-validation` gem to create validation schema for your views - - Every view should have a unique schema defined by a *form object* - - Put your form objects in a new `/forms` directory - - Create custom rules for rules that use multiple input fields - - Choose between using `dry-validation`'s messages and creating custom error messages - - Use form objects in your controllers - - Pass your `params` directly to your form objects - - See that your controllers are now using only form objects and service objects to handle all non-routing logic +- API: Create policy objects in a `/policies` + - Create at least one policy object per resource (e.g., 'ProjectPolicy', 'DocumentPolicy', etc.) + - Initialize policy objects with appropriate models (subject and object of policy) + - Create true/false predicate methods check for key actions (creation/deletion/updating/viewing, etc.) + - Make your predicate methods readable by using descriptive private predictes + - Use your policy objects in resource request routes to check authorization of account and resource +- API: Create policy scope objects + - Scope objects should return lists of all relevant objects for a given action (e.g., `viewable`) and agents (e.g., `current_account`) + - Use your policy scopes to retrieve lists of objects to return on index routes (e.g., `/api/v1/projects`) +- API + Web App: Policy summaries + - API: Create a `summary` method for each policy object that returns a hash of all predicate names and results + - API: Routes that return a resource should return a jsonified summary of its policy for the given account + - Web App: Forms should determine authorization to show links/buttons/resources based on policy summaries returned by API