You need to store a user in a database table; what do we need to know about them? (ie, email, password)
- To store a user in a databse we would need to know first and last name, email, passoword, and maybe a phone number.
- Depening on the application using the database it might require a mailing address, age, or other important attributes.
How can we store a password in a secure way? (ie, if our database is compromised, how can we protect their passwords from prying eyes)
- One way is by encrypting stored passwords with a nonreversible cryptographic function so an attacker could not solve the encryprion logic(if it were reversible).
- The use of salt, which generates two random hashes for a password, and increases the chances of the generated hash being unique to itslef. Salt forces password breaking software to restart everytime (for every password) a code is broken.
- Pepper, Hashes, and Rainbow tables are other forms of password protection.
- I think we can do this by storing client data through the use of cookies, and caches.
- Through a series of checks and balances with Authenticaiton through the JSON respones.
- Validate username
- Validate password
- Encode all output.
- Keep password obscured/doens't show on the page. Maintain password security
- Don't be too specific in your error messages, so attackers aren't able to sort out what is correct/incorrect.
- Hash and/or Salt your passwords. Combination of Password protection tools.
- I think you could tell if a user is logged in by requiring pages to check the login status from the response on every page as a conditional before loading the page.
- I think you would have to store the user data somehow, and have a way to reference it later.
- Through the use of cookies, and encrypting what data is stored in that cookie. Store the cookie itself for a time that has a maximum limit, and during that time frame if the user logs in again the cookie will automatically be loaded, and pass the encrypted log in information through all of the same checks and balances of the login process to make sure it matches up with the login credentials in the database. If it does match then it would automatically open/load the application again-otherwise it would have the user sign in again.
\
- Two kinds of params are possible in a web application:
- String Query Params which are passed in the URL after the "?" (Query Tag)
- POST Data which is passed in through the HTML and has been passed in by the user. Can only be used with an HTTP POST request.
Rails does not make any distinction between the two and both are available in the params hash in your controller.
- The params hash is noot limited to single keys and values. It can also contain nested hashes and arrays as the values. Rails will automatically decode the HTML encoded array brackets using modulos, and 5b/5d.
- Symbols and Strings are interchangeable.
- JSON Parameters can also be accepted. You Can wrap paramters to omit the outer hash layer and access the params hash a normal in the controller.
- Using private params allows us to return a 400 Bad Request Error if not all of the attributes are included in the params. This also allows us to sanitize data for each individual user checking for permissable attributes in the params.
- This method can also be considered "Strong Params".
- We can use permit, as a means to check for the scalar value of a params key. We can check if params[:id] is a value type like a hash or an array by using params.permit(id: [])
- We can also permit nested params keys, when there are nested params being passed in.
- We have the ability to permit entire param hash objects that are stored or nested with permit! however we need to take caution when using this because it permits everything and can permit arbitrary information, if not damaging information to be permitted.