Download as PDF, PPTX
More Related Content
Similar to Startup Institute NY - Authentication, Validation, and Basic Testing
![Lect 1 Number systems and base conversions. [Autosaved].pptx](https://cdn.slidesharecdn.com/ss_thumbnails/lect1numbersystemsandbaseconversions-260111134109-67c2d865-thumbnail.jpg?width=640&height=640&fit=bounds)
Startup Institute NY - Authentication, Validation, and Basic Testing
- 1. Curriculum: Authentication, Validation &Basic Testing Spring, 2016
- 2. Authentication, Validation, &Testing PART 1 1.) Authentication (~ 60 minutes) 2.) Validation (~ 30 minutes) 3.) Pairing (~30 minutes) Agenda
- 3.
- 4. Matthew Gerrior Devpost, Headof 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 insidelook 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 forunder-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
- 7.
- 8.
- 9.
- 10. - Key-value datapairs - Stored in the user’s browser - Stored until they reach their specified expiration data. Cookies
- 11.
- 12. Good for: - Storingtemporary 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 itbad 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.
- 15. Cookie Jars Rails alsoprovides 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.
- 17.
- 18. Session How can wetell 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.
- 20.
- 21. That looks likethe 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 reallya 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.
- 24. Which Session Storeshould 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 Iuse 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 youaccidentally 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 ituseful for besides knowing which user is currently logged in? Session
- 28.
- 29.
- 30.
- 31. Special “hash” thatpersists 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.
- 33.
- 34.
- 35. Why can’t Ijust 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’mnot 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.
- 38. Devise Flexible authentication solutionfor Rails with Warden. https://github.com/plataformatec/devise
- 39. Authenticating users iseasy. I’ll just build a SessionsController with some CRUD actions and store the user id in the cookie. Problem solved. Devise
- 40. No. Authenticating usersis 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 gettingpaid 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 storesa password in the database to validate the authenticity of a user while signing in. Devise Database Authenticatable
- 43. Adds OmniAuth (signin with Twitter/Facebook/GitHub/whatever) support. Devise Omniauthable
- 44. Sends emails withconfirmation instructions and verifies whether an account is already confirmed during sign in. Devise Confirmable
- 45. Resets the userpassword and sends reset instructions. Devise Recoverable
- 46. Handles signing upusers through a registration process, also allowing them to edit and destroy their account. Devise Registerable
- 47. Manages generating andclearing a token for remembering the user from a saved cookie. Devise Rememberable
- 48. Tracks sign incount, timestamps and IP address. Devise Trackable
- 49. Expires sessions thathave not been active in a specified period of time. Devise Timeoutable
- 50. Provides validations ofemail and password. It's optional and can be customized, so you're able to define your own validations. Devise Validatable
- 51. Locks an accountafter a specified number of failed sign-in attempts. Can unlock via email or after a specified time period. Devise Lockable
- 52. Should I alwaysuse 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 Ilearn 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.
- 55. Validation - Make testing/maintenancemore difficult - Beneficial when multiple applications access database - Can handle some constraints more efficiently than application-level code Database-level Validation
- 56. - Convenient wayto 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 touse and difficult to test/maintain - Goes against the Skinny Controller/Fat Model design paradigm of Rails Validation Controller-level Validation
- 58. - Best wayto 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 toensure 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.
- 61.
- 62.
- 63.
- 64.
- 65.
- 66.
- 67.
- 68.
- 69.
- 70.
- 71.
- 72.
- 73.
- 74.
- 75.
- 76.
- 77.
- 78.
- 79.
- 80.
- 81.
- 82.
- 83.
- 84. Testing TDD - TestDriven Development
- 85.
- 86.
- 87.
- 88.
- 89.
- 90.
- 91. Testing - Earliest phaseof 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 thatmodel validations are present - Ensure that relationships exist with correct options - Ensure helper methods perform as expected Testing Unit Testing
- 93.
- 94.
- 95. Testing combinations ofseparate components/modules that have been independently unit tested already. Testing Integration Testing
- 96.
- 97.
- 98.
- 99. Testing Verifying that allof the product/business needs have been met and that end users have the desired experience. Acceptance
- 100.
- 101.
- 102.
- 103.
- 104.
- 105.
- 106.
- 107.
- 108.
- 109.