Authentication (Tue Oct 31, lecture 25)

Homework due for today

Legend: : Participation | : Early | : PDF | : Portfolio | : Zipped

  1. Read: Security in Rails * Read Rails Security Guide * Read about: Brakeman Gem * Deliverable: Submit a post (pdf) with some specific things that you will be able to use in your product from these two readings. This is an individual deliverable.
  2. Teams: You should be up to around steps DB, UNITTEST, ACCTS, AUTHENT of the Project Roadmap

Leftover from last week!

Conceptual

  • You need a form whenever the browser needs to send data to the server
  • <form> tag begins the group of fields. It declares the URL that payload is sent to
    • There are zero or more fields
    • There’s always a “submit” link or button that triggers the sending
    • </form> terminates the group
  • Sending always is done via some kind of HTTP request
    • Payload is always name=value pairs, value is always text over the wire

Rails

  • There are always TWO controller actions:
    • one to display the form
    • one to accept the data from the form
    • Where can I find them for items?
    • Two controller actions means TWO urls!
  • Display the form
    • Let’s look at what the HTML should look like
    • Difference between form_for and form_tag: let’s look at two examples
    • Why is there an Item.new in the form display action (new)?
  • Accept data from the form
    • What URL is requested to send the data? What http verb? Why?
    • How does the data come back from the form?
    • What can the controller do with that data?
  • Security issues
    • What if the form payload is not coming from your form?
    • What if your form has been modified inside the browser?
    • Explain params.require()
More complicated case
  • Nested resources
    • A comment always belongs to an item
    • What should the URL look like to display the form to create a comment (THINK!) What is the verb?
    • Does the form display to add a comment work differently?
      • Using form_for vs. form_tag in this situation
    • What would the URL look like to accept the data of the new comment?
      • Let’s read the action and understand what it does
    • How do you create a nested resource, i.e. a comment for item 3?
Making Views DRY
  • When you see yourself writing the same html over and over again
    • write a helper: let’s do an example!
    • write a partial: And let’s do another example!

Summary

  • Routes
    • Understand the urls and verbs and how they map to controller actions
    • Use rake routes to verify your understanding
    • Make changes to routes.rb to get the urls and verbs you intend
  • Forms
    • Two actions, one to display the form, one to send the payload to the server
    • form_for and form_tag are equally good. In real cases you end up with form_tag often
    • Understand params and params.require
    • Forms for nested resources
  • Other tools
    • helpers to generate repetitive html
    • parials to build repetitive html
    • rake db:migrate:reset and rake db:seeds

Let me demonstrate…

Review Review: resources in Rails

  • Automatic wiring of plumbing between urls, routing, models, and controllers
  • Takes advantage of standardized patterns
    • Nesting model in the URLs
    • CRUD operations as actions
    • Path naming (path_to_user instead of “”)
    • Controller naming
  • Huge time saver and bug saver!
Controller Actions
  • Who calls the controller action?
  • What parameters are supplied automatically by the controller action?
  • Sessions, why they are needed and how they work
  • Why does it take two separate actions to implement “create”?
  • URL - Uniform Resource Locator

Authentication and Authorization

Terminology

  • Beware: this is hairy
  • Authentication: As an app runs, need to know “who is logged in”
  • Authorization: For anyone who is logged in: What is s/he allowed to do

Key Concepts

  • True of more or less any approach to authorization and authentication
  • User record
    • There is some kind of User record corresponding to
    • User is designated internally by a User (or Account, or similar concept)
  • A globally accessible method “current_user”
    • Can be called anywhere to see who is logged in
    • Decide what it returns if no-one is logged in
  • For Authorization, some choices:
    • Access control lists: List of people who are allowed to do operation X
    • User Capabilities: Each user has a series of CAN_xxx flags in the user database
    • User Types: Admin, Operator, Guest, etc.
  • Sessions
    • User “state” across requests
    • May store, for example, whether they are logged in, what’s in their shopping cart, what their access level is, etc.
Complications that have to be considered
  • What does the product do when user is not logged in?
    • Sometimes you have an artificial (“seed”) user to be the non-logged-in user
  • How to store the password
    • Never ever in free text
    • At minimum hashed
  • Dealing with Social Media log in
    • Facebook
    • Google
  • What to use for user id
    • A made up id (pitosalas) or just an email (pitosalas@gmail.com)
Mechanics
  • Authentication support has to:
    • Present a log in page
    • Present a account creation page
    • Check the “credentials”
    • Make the identity of the logged in user ‘globally available’ within your app
    • What is the ‘identify of the logged in user?’, it’s just a method called ‘logged_in_user’ that when called returns an instance of the User model.
  • But should not:
    • Decide what operations that user may do or not. Conceptually and architecturally, should be kept separately
    • Store the user’s password in a database. How do you authenticate then?
  • Authorization
    • Can “the currently logged in user” do this operation?
    • Often implemented with a list of “user types” (e.g. admin, professor, student)
    • And with a list of “operation types” (e.g. “administration”, “read-write”, “read-only”)
    • Guard code in each controller/action

Possible implementation strategies in Rails

Demos

Look at next class