rename_column :table, :old_column, :new_column
You'll probably want to create a separate migration to do this. (Rename FixColumnName
as you will.):
script/generate migration FixColumnName
# creates db/migrate/xxxxxxxxxx_fix_column_name.rb
Then edit the migration to do your will:
# db/migrate/xxxxxxxxxx_fix_column_name.rb
class FixColumnName < ActiveRecord::Migration
def self.up
rename_column :table_name, :old_column, :new_column
end
def self.down
# rename back if you need or do something else or do nothing
end
end
For Rails 3.1 use:
While, the up
and down
methods still apply, Rails 3.1 receives a change
method that "knows how to migrate your database and reverse it when the migration is rolled back without the need to write a separate down method".
See "Active Record Migrations" for more information.
rails g migration FixColumnName
class FixColumnName < ActiveRecord::Migration
def change
rename_column :table_name, :old_column, :new_column
end
end
If you happen to have a whole bunch of columns to rename, or something that would have required repeating the table name over and over again:
rename_column :table_name, :old_column1, :new_column1
rename_column :table_name, :old_column2, :new_column2
...
You could use change_table
to keep things a little neater:
class FixColumnNames < ActiveRecord::Migration
def change
change_table :table_name do |t|
t.rename :old_column1, :new_column1
t.rename :old_column2, :new_column2
...
end
end
end
Then just db:migrate
as usual or however you go about your business.
For Rails 4:
While creating a Migration
for renaming a column, Rails 4 generates a change
method instead of up
and down
as mentioned in the above section. The generated change
method is:
$ > rails g migration ChangeColumnName
which will create a migration file similar to:
class ChangeColumnName < ActiveRecord::Migration
def change
rename_column :table_name, :old_column, :new_column
end
end
Cross-Site Request Forgery (CSRF) in simple words
- Assume you are currently logged into your online banking at
www.mybank.com
- Assume a money transfer from
mybank.com
will result in a request of (conceptually) the form http://www.mybank.com/transfer?to=<SomeAccountnumber>;amount=<SomeAmount>
. (Your account number is not needed, because it is implied by your login.)
- You visit
www.cute-cat-pictures.org
, not knowing that it is a malicious site.
- If the owner of that site knows the form of the above request (easy!) and correctly guesses you are logged into
mybank.com
(requires some luck!), they could include on their page a request like http://www.mybank.com/transfer?to=123456;amount=10000
(where 123456
is the number of their Cayman Islands account and 10000
is an amount that you previously thought you were glad to possess).
- You retrieved that
www.cute-cat-pictures.org
page, so your browser will make that request.
- Your bank cannot recognize this origin of the request: Your web browser will send the request along with your
www.mybank.com
cookie and it will look perfectly legitimate. There goes your money!
This is the world without CSRF tokens.
Now for the better one with CSRF tokens:
- The transfer request is extended with a third argument:
http://www.mybank.com/transfer?to=123456;amount=10000;token=31415926535897932384626433832795028841971
.
- That token is a huge, impossible-to-guess random number that
mybank.com
will include on their own web page when they serve it to you. It is different each time they serve any page to anybody.
- The attacker is not able to guess the token, is not able to convince your web browser to surrender it (if the browser works correctly...), and so the attacker will not be able to create a valid request, because requests with the wrong token (or no token) will be refused by
www.mybank.com
.
Result: You keep your 10000
monetary units. I suggest you donate some of that to Wikipedia.
(Your mileage may vary.)
EDIT from comment worth reading by SOFe:
It would be worthy to note that script from www.cute-cat-pictures.org
normally does not have access to your anti-CSRF token from www.mybank.com
because of HTTP access control. This note is important for some people who unreasonably send a header Access-Control-Allow-Origin: *
for every website response without knowing what it is for, just because they can't use the API from another website.
Best Answer
Jimbo did an awesome job explaining the "why" behind the issue you're running into. There are two approaches you can take to resolve the issue:
(As recommended by Jimbo) Override Devise::SessionsController to return the new csrf-token:
And create a success handler for your sign_out request on the client side (likely needs some tweaks based on your setup, e.g. GET vs DELETE):
This also assumes you're including the CSRF token automatically with all AJAX requests with something like this:
Much more simply, if it is appropriate for your application, you can simply override the
Devise::SessionsController
and override the token check withskip_before_filter :verify_authenticity_token
.