I have an export of the users table from a Rails 3.0/Devise 1.1.8 app. I would like to seed these into a Rails 3.1/Devise 2.0 app. I imported that data via CSV and configured Devise with the same pepper value as the old app, however users are not able to log in. Bcrypt is/was used in both cases.
I think what I'm missing is that Devise 1 stored the salt in a separate field, but 2.0 puts it in the encrypted password string. Is there a way to migrate my data into the new app properly?
The best idea is to follow this: https://github.com/plataformatec/devise/wiki/How-To:-Upgrade-to-Devise-2.0, which basically recommends that you upgrade to 1.5 first, then upgrade all the way to 2.0. I think its pretty straight forward from that wiki explanation.
Related
I am connecting to DocuSign via oauth with Rails 6 and Omniauth - it seems I have it configured correctly since visiting /auth/docusign takes me to the DocuSign login screen. After logging in, it takes me to the callback. The callback is failing because the omniauth-docusign gem is failing with the user_info hash. Where it should be getting user_info['accounts'] it is getting this:
user_info #=> {"error"=>"internal_server_error", "reference_id"=>"a0f0e8c9-2faa-4b70-90b8-875ae40f13cf"}
My API Dashboard for the App shows no log or request info. 0 total requests. Is there a log area for oauth attempts, or where to use this reference ID?
Can someone at DocuSign help with this? Your developer support page seems to say to ask here on S/O.
It appears that you didn't configure everything correctly for your Integration Key (IK which is like clientId) as well as clientSecret and the rest of the configuration that you can do for your IK.
I would suggest that you can get a pre-built Ruby application that already had this all done for you and save you some work by going to the Quickstart. This would enable you to go get a ZIP file pre-configurated with all the required gems and everything needed for auth already set based on your own developer account.
Update: if you then want to take this code into your own app, you need to also get the authentication code supplied lib/docusign.rb instead of a gem like omniauth-docusign.
As Inbar Gazit said, it's important to use the Quickstart app, which I was doing. However, not only do I already have my own existing rails app, even if I didn't, I wouldn't want to have to clean out all the extra stuff in the quickstart app that I don't need. It would be nice to have a minimal script for installing just the bare minimum into an existing rails app to get authenticated and start using the API.
In the end, the solution for me was to notice and copy the lib/docusign.rb file from the Quickstart app, instead of using an omniauth-docusign gem. The base omniauth gem had advised me to find and install that gem because there was no strategy defined for docusign. The quickstart lib file is what I needed.
I want to migrate Rails 2 app to Rails 4. I have successfully migrated in Rails 3. Now I have a big problem with restful-authentication. It's not working for rails 4 so I need to migrate in devise but I don't want any changes with thousands of existing users.
Is it better to migrate in devise or is there some other alternative for restful-authentication?
restful_authentication is no longer being maintained so I recommend migrating to an alternative like devise. With a bit of configuration you can set up devise to work with the passwords that have been encrypted through restful_authentication. There's guide on their github page on how to do it: https://github.com/plataformatec/devise/wiki/How-To:-Migrate-from-restful_authentication-to-Devise
So I've set up a new authentication process within my website using rails (rails version '4.2.0', sqlite3 database manager, ruby 2.1.1p76) on OSX Mavericks (yes, I still haven't updated yet!). The website as yet is still only local as I'm learning rails.
I have modified the user authentication to utilise a cookies remember me function, but old users can not login, i.e. error Couldn't find User (ActiveRecord::RecordNotFound in WelcomeController#homepage)
Newly created users can.
I was just wondering what the terminal command is to somehow to delete all records of users from the database, so that all new users need to sign up to obtain the remember me functionality...? I can't seem to find the exact answer and I don't want to start messing too much with the database.
Start a rails console by typing
rails c
in the terminal, in your rails application folder (not the app subfolder).
type
User.destroy_all
I have installed the latest version of the Brakeman gem to help me with Rails application security.
I have several Rails applications that I have on two servers, one for development and the other for production. When I ran the Brakeman reports on my applications, most of them flagged config/initializers/secret_token.rb with the following high security vulnerability.
Session secret should not be included in version control near line 7
This is the first time I have seen this error since I ran an older version of Brakeman months ago.
From what I have researched so far Rails automatically generated the secret token when rails new appname is executed. I was not aware of it until now. Apparently Rails does not protect this file where if I decided to move any of my applications to Github the information would be available to anyone at Github accessing the application. At this time I am not uploading to GitHub but I want information on how to move the secure_token from config/initializers/secret_token.rb in order to close the security hole in my applications.
One blog post I read suggested that I inject the secret token into an ENV variable. Will moving the statement from config/initializers/secret_token.rb to config/environment.rb solve the problem? If so I will add this task to my list of tasks in Rails development.
Any help would be appreciated.
That particular message in Brakeman was silenced for me when I put secret information into ENV variables, as you mentioned. Personally, I like to use the Figaro gem for this, but I think dotenv is popular as well.
Some other resources that may be of interest to you regarding this are:
Code Climate blog entry: Rails Insecure Defaults blog entry on Code Climate
StackOverflow thread: What should be removed from public source control in Ruby on Rails?
I'm not sure how moving the session secret to a different file would make a difference. Essentially, the secret token should be treated just like a password.
This blog post from Phusion explores a few different options for providing the session key at deploy time.
I am working on a project where the live site is now using
Devise 1.0.6 with Rails 2.3.8.
There, its not using pepper (as this is switched off by default in 1.0.6 with sha1 as default I guess..(don't know what is default alg. in 1.0.6))
In my latest code, I have updated the devise version from its git repo, so my current snapshot of code uses
Devise 1.2.rc with Rails 3.0.1
Here in my current code, devise uses a default pepper value written in my devise.rb and it uses sha512 as its encryption algorithm I guess (don't know what is default alg. in 1.2.rc).
In both the old code and new code, in devise.rb, a custom alogirthm for encryption is not set. So devise uses its default encryption algorithms in live site( devise 1.0.6) and in my current latest code ( 1.2.rc)
I don't know which is the default encryption algorithm in Devise 1.0.6 and Devise 1.2.4c. Can you please tell me how to check this default algorithm.
Live site uses no pepper and my current code uses a default pepper given by Devise. which means that my old users will not be able to login if I start using the new default pepper give in 1.2.rc. How do I handle this. Shall I turn off the pepper option in my new code ? Please advise.
I could use the same devise version 1.0.6 but a lot of functionalities like open auth are available in the new devise version - so I am using the new one. Please advise on what to do.
thanks