Most apps need to be able to store some data about a user. Maybe itâ€™s a user id, or a preferred language. session is the perfect place to put this kind of data. Little bits of data you want to keep around for more than one request.
Sessions are easy to use:
What is a session?
A session is just a place to store data during one request that you can read during later requests.
You can set some data in a controller action:
And read it in another:
It might not seem that interesting.
But it takes coordination between your userâ€™s browser and
your Rails app to make everything connect up.
And it all starts with
When you request a webpage, the server can set a cookie when it responds back.
Your browser will store those cookies. And until the cookie expires, every time you make a request, your browser will send the cookies back to the server. This cookie contains your rails session you have been using.
Cross-Site Request Forgery
Lets say you are logged in on gmail.com and in another tab you have opened a hackerâ€™s website. Which is urging you to click a image saying you will get 100 coins. But actually it will send a request to gmail.com deleting all mails. This request will be successful because browser will send cookie along with the request and in this cookie your current gmail session exists.
How to prevent CSRF?
Synchronizer token pattern (STP) is a technique where a token, secret and unique value for each request, is embedded by the web application in all HTML forms and verified on the server side.
How does the token look like?
The token will be added automatically to every form like this:
<input name="authenticity_token" type="hidden" value="OXuQV+9Q1hi5YkeynLQgVddCRfdUwl0huvqSjoqf4mE=" />.
The same token is in user’s session. On every request the token in session and the token in HTML form are compared on the server side and if they match only then the request is completed.The purpose of the token is that an attacker doesnâ€™t know the victimâ€™s token and thus a CSRF attack without that token would be refused.
Protect CSRF in Rails app
The CSRF protection can be turned on with the
protect_from_forgery controller method and is included in the
ApplicationController by default.
So for every non-GET (and non-HEAD) action Rails will check the authenticity token.
- 13 Nov 2017 Sheet, Comparison of frontend js frameworks.
- 11 Nov 2017 Why is it so hard to develop good software?
- 04 Sep 2017 Is Graphql here to replace REST Api
- 05 Jun 2017 My awesome list of english songs
- 29 May 2017 Troll software intern
- 17 May 2017 What is icon font and why use it over png.
- 16 May 2017 Philosophical difference between ruby and python.
- 15 May 2017 Given an array, find number of subsets with k elements, where absolute difference between the maximum and mininmum element is at most x
- 15 May 2017 Automated testing of google autocomplete using cucumber and capybara
- 15 May 2017 How to manage assets in rails, difference between app, vendor and lib assets, what is asset pipeline?
- 15 May 2017 Swap elements in dom by drag and drop.
- 15 May 2017 What are the options with which protect_with_forgery is called?
- 15 May 2017 How to add csrf in ember app.
- 15 May 2017 Sessions and csrf in rails.
- 15 May 2017 Best practices while using ooor gem for making rpc calls to odoo(openerp) from ruby framework
- 09 May 2017 Integrate paytm payment with rails app
- 08 May 2017 Automated deployment on github pages using jekyll themes.
- 01 May 2017 How to add inline image in gmail.
- 01 May 2017 Undefined method `user_confirmation_path' error with devise rails.