Recommended
Recommended
More Related Content
What's hot
What's hot (19)
Viewers also liked
Viewers also liked (20)
Similar to Startup Institute NY (Summer 2016) - Authentication, Validation, and Basic Testing
Similar to Startup Institute NY (Summer 2016) - Authentication, Validation, and Basic Testing (20)
Recently uploaded
Recently uploaded (20)
Startup Institute NY (Summer 2016) - Authentication, Validation, and Basic Testing
- 1. Curriculum: Authentication, Validation & Basic Testing Summer, 2016
- 2. Authentication, Validation, & Testing PART 1 1.) Authentication (~ 60 minutes) 2.) Validation (~ 30 minutes) 3.) Pairing (~30 minutes) Agenda
- 4. Matthew Gerrior Devpost, Head of Engineering ABOUT ME ● Grew up outside Boston ● Went to school upstate ● Worked in consulting for ~ 3.5 years ● Got tired of building other people’s products ● Moved to NYC to join Devpost (known as ChallengePost at the time) devpost.com/MGerrior
- 5. Devpost Get an inside look at Dev teams who are hiring ABOUT US ● Online Hackathons (Uber, Oculus, AT&T) ● In-Person Hackathons (PennApps, HackNY) ● Developer Portfolios to showcase skills, technologies, projects ● Team Pages give an inside look at hot startups in NYC (Blue Apron, Buzzfeed, Genius) devpost.com/teams
- 6. ScriptEd Coding Skills for under-resourced schools ScriptEd equips students in under-resourced schools with the fundamental coding skills and professional experiences that together create access to careers in technology. ● GitHub accounts from Day 1 ● Two hackathons every year ● Field trips to Tech Companies ● Summer internship opportunities
- 8. Cookies
- 9. Cookies
- 10. - Key-value data pairs - Stored in the user’s browser - Stored until they reach their specified expiration data. Cookies
- 11. Cookies
- 12. Good for: - Storing temporary data - Storing data that isn’t sensitive Bad for: - Storing permanent/persistent data - Storing sensitive data like passwords or shopping carts Cookies
- 13. Why is it bad to store sensitive data or persistent data in a cookie? - Very easy for users to delete cookies - Doesn’t persist across browser sessions/devices - Easy to steal/manipulate cookies Cookies
- 14. Cookies
- 15. Cookie Jars Rails also provides access to two cookie jars: - “Signed” cookies prevent tampering by the end user by signing the cookies with your applications “Secret Base Key” - “Encrypted” cookies are secured even further by first encrypting the values, and then signing them with the “Secret Base Key”
- 16. Cookie Jar
- 17. Session
- 18. Session How can we tell which user is making a request to our site if HTTP requests are stateless? Rails stores a cookie on the user’s browser containing their session hash. - Secure - Tamper-Proof - Expires when the browser is closed
- 19. Session
- 20. Session
- 21. That looks like the cookies you just taught us about, why do we need both? The session is an entire hash that gets stored in a secure cookie that expires when the browser is closed. Each value in the cookies hash is stored as an individual cookie, since they are key-value data pairs. Session
- 22. - Not really a hash, that’s just how Rails presents it to you to make it easier to work with. Cookies are not hashes either. - Size of an individual cookie is limited to roughly 4kb, which is sufficient for normal usage, but prevents them from acting as a database of any sort. Session
- 23. Session
- 24. Which Session Store should I choose? - Cookie store is the default, and recommended store. It’s lightweight and requires zero setup in a new application to use. Session
- 25. Why would I use a different store then? - You need more than 4kb of session data - You probably don’t, but sometimes you do - Cookies are sent along with every request you make - Bigger Cookies means bigger (and slower) requests Session
- 26. - If you accidentally expose your “secret_base_key”, users can change their session data - Since the key is used to sign/encrypt the cookie, exposing the key exposes the session - Storing the wrong kind of data is insecure - Vulnerable to attacks like the replay attack if sensitive data stored in cookie Session
- 27. What is it useful for besides knowing which user is currently logged in? Session
- 28. Session
- 29. Flash
- 30. Flash
- 31. Special “hash” that persists only from one request to the next. A self-destructing session hash. Commonly used for sending messages from the controllers to the view, because they persist across a redirect from a “New Object” form to the details page for that object. Flash
- 32. Flash
- 33. Flash
- 34. Flash
- 35. Why can’t I just use instance variables? Instance variables only exist for the current request, and are lost when a new request takes place such as when the user is redirected. Flash
- 36. What if I’m not redirecting the user and I’m just rendering a page? Make flash messages available to the current request using flash.now just like you would with a regular flash. Flash
- 37. Devise
- 38. Devise Flexible authentication solution for Rails with Warden. https://github.com/plataformatec/devise
- 39. Authenticating users is easy. I’ll just build a SessionsController with some CRUD actions and store the user id in the cookie. Problem solved. Devise
- 40. No. Authenticating users is not easy. What about: - Securely storing user passwords - Confirming email addresses? - Log in With Twitter/GitHub/Facebook? - Forgot Password email? - Remember me checkbox? Devise
- 41. You’re not getting paid to build an authentication system (unless you are), you’re getting paid to build a new and exciting product that no one has ever built before. Devise
- 42. Hashes and stores a password in the database to validate the authenticity of a user while signing in. Devise Database Authenticatable
- 43. Adds OmniAuth (sign in with Twitter/Facebook/GitHub/whatever) support. Devise Omniauthable
- 44. Sends emails with confirmation instructions and verifies whether an account is already confirmed during sign in. Devise Confirmable
- 45. Resets the user password and sends reset instructions. Devise Recoverable
- 46. Handles signing up users through a registration process, also allowing them to edit and destroy their account. Devise Registerable
- 47. Manages generating and clearing a token for remembering the user from a saved cookie. Devise Rememberable
- 48. Tracks sign in count, timestamps and IP address. Devise Trackable
- 49. Expires sessions that have not been active in a specified period of time. Devise Timeoutable
- 50. Provides validations of email and password. It's optional and can be customized, so you're able to define your own validations. Devise Validatable
- 51. Locks an account after a specified number of failed sign-in attempts. Can unlock via email or after a specified time period. Devise Lockable
- 52. Should I always use Devise? No, not always. There are other alternatives such as Sorcery that provide authentication. More importantly, it is a very enlightening exercise to try to build your own authentication system from scratch (just not for a production application). Devise
- 53. Where can I learn more about rolling my own authentication system? ● Michael Hartl's online book: https://www.railstutorial. org/book/modeling_users ● Ryan Bates' Railscast: http://railscasts.com/episodes/250-authentication- from-scratch ● Codecademy's Ruby on Rails: Authentication and Authorization: http: //www.codecademy.com/en/learn/rails-auth Devise
- 54. Validation
- 55. Validation - Make testing/maintenance more difficult - Beneficial when multiple applications access database - Can handle some constraints more efficiently than application-level code Database-level Validation
- 56. - Convenient way to provide immediate feedback without submitting form/performing request - Unreliable if used alone and implemented in JavaScript, as they can easily be bypassed. Validation Client-side Validation
- 57. - Unwieldy to use and difficult to test/maintain - Goes against the Skinny Controller/Fat Model design paradigm of Rails Validation Controller-level Validation
- 58. - Best way to ensure that only valid data is stored in the database - Database agnostic - Cannot be bypassed by end users - Convenient to test and maintain Validation Model-level validations
- 59. - Important to ensure consistency in your database - Easier to render things like user profiles if you know things like name are guaranteed to be present - Ensure proper functioning of application by enforcing things like uniqueness of screen names, or valid formats of email addresses. Validations
- 60. Validations
- 61. Validations
- 62. Validations
- 74. Validations
- 75. Validations
- 76. Validations
- 77. Validations
- 78. Validations
- 79. Validations
- 80. Validations
- 81. Validations
- 82. Validations
- 83. Testing
- 84. Testing TDD - Test Driven Development
- 85. Testing TDD
- 86. Testing RSpec
- 87. Testing RSpec
- 91. Testing - Earliest phase of testing - Focuses on individual unit or component - Best/Easiest phase to catch bugs in - Can have 100% passing unit tests but still have code that doesn’t work as intended Unit Testing
- 92. - Ensure that model validations are present - Ensure that relationships exist with correct options - Ensure helper methods perform as expected Testing Unit Testing
- 95. Testing combinations of separate components/modules that have been independently unit tested already. Testing Integration Testing
- 99. Testing Verifying that all of the product/business needs have been met and that end users have the desired experience. Acceptance
- 103. Testing Capybara
- 104. Testing Capybara
- 105. Testing