Sign in through GitHub

Please read for an updated status on RailsCasts:

Learn more or hide this

Suzi's Profile

GitHub User: suzi2000

Comments by Suzi

Avatar

though i forgot, rails takes care of the forms validity with the authenticity token, however its probably still safer to have a time check in the update action.

Avatar

Having a check in the edit action makes it more convenient.

However you should NOT remove the check from the update action, as attackers can now try outdated activation codes forever with forged PUT requests.

Avatar

i have the same concern, since it is quite possible to brute force many ids in password_resets/id/edit and then set the users password AND email to your own pw & email.

If you could not assign an email via the password_resets_controller, then it would be much harder to figure out which email was assigned to the updated password.

Avatar

for anybody having the same problem with testing, when switching from session to cookies. You need to use request.cookies to assign the cookie.

ruby
RSpec.configure do |config|
  def test_sign_in(user)
    request.cookies[:auth_token] = @user.auth_token
  end
end

and in your normal specs where you use test_sign_in

ruby
request.cookies[:auth_token].should == @user.auth_token

in specs where you dont use test_sign_in but rather post :create, :email => "user@example.com", :password => "somepassword"

ruby
cookies[:auth_token].should == @user.auth_token

its really confusing me

Avatar
SET "password_digest = '$2a$10erAAjsAfskv...' 

appears unfiltered in the log files (Rails 3.1.rc4) Is this a security issue ?

Avatar

Check this out:
You can easily get associated model data into Jason

http://stackoverflow.com/questions/4764954/getting-value-from-associated-model

Then within token-field you can add a function to manipulate your entries

javascript
onResult: function (results) {
      $.each(results, function (index, value) {
        value.name = value.quantity + ': ' + value.name;
      });
      return results;
    }
Avatar

Very nice solution, but is there a specific reason to not use Boolean tables within the user model for each role ? (user.amin, user.moderator etc.) It seems to be easier this way to delete roles and all the corresponding data through migrations.