Devise in rails giving error on heroku - ruby-on-rails

I am using devise with mongoid. App has two devise models users and investors. When I sign-up for each in localhost it works fine but on heroku when I submit form the page get redirects to app/users or app/investors and I got 500 service internal error. In the app the views directory of users and investors are separately defined.
Any guesses?

Finally solved the issue was the mongodb service, they actually reset the password, so I have to change that in mongoid.yml. My advice for people working with service:
1) Start your debugging with config files the username and password before jumping to plugin code. I spend 5 hours in debugging devise internal code and problem was somewhere else.

Related

CSRF Detection fix provider_ignores_state: true not saving session after successful Devise Omniauth-Facebook Authentication

My application was working ok, and then I updated to Rails 5.0.1. After this my app no longer authenticated with Facebook and came up with the following error in the logs:
Authentication failure! csrf_detected:
OmniAuth::Strategies::OAuth2::CallbackError, csrf_detected | CSRF detected
So, in accordance to what people on StackOverflow suggested, I changed my omniauth config to include the provider_ignores_state: true setting, which suppressed that error.
config.omniauth :facebook, 'xxx', 'xxxxxxxxxxxxx',{
scope: 'public_profile,email,user_birthday,etc...',
info_fields: 'name,first_name,etc...',
provider_ignores_state: true
}
This made everything work just fine; at least in development running locally, but when I pushed the code to my staging server, the app successfully authenticates with Facebook, supposedly "signs" the user in and redirects to root_path() - and then fails authentication and redirects back to users/sign_in.
To help diagnose the problem i put a logging line above the relevant call (to see if it was being executed) such as:
logger.debug " (OmniauthCallbacksController#facebook) about to sign_in_and_redirect with id: #{#user.id} email: #{#user.email} uid: #{#user.provider_uid}"
sign_in_and_redirect #user, event: :authentication
My OmniauthCallbacksController handler for the Facebook provider there for does seem to reach 'sign_in_and_redirect' - but for reasons I cannot determine on my staging environment, it never actually saves the session to a cookie. There are no errors in the logs (in debug mode) to demonstrate there was any kind of exception thrown - except that the query to increment the log_in_count on the user doesn't actually run any query:
(2.4ms) COMMIT
(0.2ms) BEGIN
(0.2ms) COMMIT
Which looks weird (no actual update query, whereas in development i can see the log_in_count etc be incremented). But its the only other indication that something goes wrong. After that, it fails the authenticate_user! check and redirects back to the sign_in_url.
This is sending me mad - Is this a bug, or is there a fix for this issue?
We had the same error come up for omniauth-github. What fixed it for us (aside from the provider_ignores_state: true hack) was the URL in the link to github's authentication site. Originally we'd entered the entire URL for github OAuth (https://github.com/login/oauth/authorize?client_id=#{ENV["GITHUB_CLIENT_ID"]}&scope=repo), but changing it to the omniauth format of just /auth/github fixed this CSRF error (as well as a no route found error when we tried mocking out / testing our OAuth). Leaving this here in case anyone else has a similar issue in the future!
I was finally able to solve this issue, but I still don't understand WHAT went wrong. Basically, created a "empty" Rails 5 project and setup a brand new devise using the omniauth-facebook gem and settings for my main app - deployed to a cloned instance of the staging server and it worked! Most of the code was the same; but when I replaced the devise.rb initializer with the one from the new app, the old code proceeded to work on the stagingg server again. Interestingly, I coped the Omniauth config from the old one to the new app, so it must have been something wrong with another of Devise's modules...and not with Omniauth itself.
In either case, it's working now. So I will put this to bed and leave this here in case another person encounters the same problem; and while I cant say what was specifically wrong, these are the steps I used to debug/fix my particular problem.

Rails 4 Heroku Multi-tenancy app redirecting to heroku homepage

Ok so im really lost and not even too sure what to post here for information.
I am Brand new to multi tenancy, i have followed a tutorial on using the apartment gem. Everything is working perfectly on lvh.me:3000, however when I push the app to Heroku, it pushes up fine no errors, but when i attrmpt to go to my domain pv-development#herokuapp.com it redirects me to the heroku home page???
Please help here.. Let me know what i need to post here for a possible solution.. I dont even know where this could be stemming from!
Thanks in advance for you patients!
EDIT #1
This is what my log just gave me from heroku:
Apartment::Tenant Not Found (One of the following schema(s) is invalid:
This error might occur when you don't have the tenant in your database. Try after creating it.
Similar issue in Github
This was occuring for several reasons, At the end of the day it was resolved by using a DNS Manager that actually supports wildcard domains ie. Zerigo DNS. i was initially using cloudflare however they only support wildcard domains on the enterprise lvl account.
I also added:
def set_mailer_host
if Rails.env.development?
subdomain = current_account ? "#{current_account.subdomain}." : ""
ActionMailer::Base.default_url_options[:host] = "#{subdomain}lvh.me:3000"
else
subdomain = current_account ? "#{current_account.subdomain}." : ""
ActionMailer::Base.default_url_options[:host] = "#{subdomain}patrolvault.co"
end
end
to my application controller and preloaded the postgresql addon into my heroku addons before I pushed the app up.
adding rails_12factor also cleaned things up a bit.
Thanks to #Jayaprakash for his assistance in troubleshooting this and providing links to reference.

Database attribute saving in Development but not in Production

I'm getting a database error in production. But in development no error.
ActiveModel::MissingAttributeError (can't write unknown attribute `invited_by_id`):
invited_by_id is a column added by the Devise Invitable gem to my User table. I encountered this error after pushing my Devise Invitable implementation to production for the first time and then attempting to invite a new user.
I have confirmed that invited_by_id IS present in both my development and production tables. I have checked this multiple times via Rails console for each environment. I have also done rake db:migrate twice for good measure (in production) with the first time adding the Devise Invitable columns and the second time, of course, having no new migrations to run since the columns were already added. There are also numerous other columns added by Devise Invitable to the same User table that were successfully migrated and are not creating errors. I have successfully edited one as well. (Google Searches, Devise Invitable Github issues, and a thorough review of my development and production environment fields have yielded nothing but encouragement to check that the column is present -- which it is.)
Is there something to be aware of with Devise Invitable, User tables, or with development versus production databases for a situation like this? For some additional context, I am using Devise Invitable 1.5.5, Rails 4.2.4, and my production database is on Heroku.
Thank you!
ActiveModel::MissingAttributeError (can't write unknown attribute `invited_by_id`)
Looking at this error message, you are missing invited_by_id column in your production database. Make sure you run your migrations on production environment and try again. That should fix your problem.
Here is the same issue reported on the gem's github page.
You can also try restarting your heroku app which seems to fix this type of issues many times :)

Devise: how to migrate users from one project to another

Wondering if anyone tried this before, I'm trying to migrate devise users from one project(postgres) to another(mongoid).
I've created a script with takes users from sql table and create mongo inserts out of it, all was running fine, but for some reason devise on new project not able to auth migrated users.
encrytpted_password field looks ok.
Can someone please advise if I've missed something?

Rails 3.2 has_secure_password fails silently when deployed to Heroku

I upgraded the authentication in my application to use Rails 3.1's has_secure_password facility. In the process, I created a page to allow users to change their passwords. I tested it and it works on my development machine, both in development and production environments.
When I deployed the application to Heroku, I went to try it and it seemed to work, except when I logged out and logged back in, my password was unchanged. I tried changing the password manually in the console and that works fine. If I try to enter different text for the password and confirmation, it shows the validation it is supposed to, which means the password is getting sent to the app correctly.
Here is the relevant change to my controller: https://github.com/mjm/sis-lunch/commit/930ced467a0e23ad48f4497999183112c5f846b1#diff-2
Is there something I'm missing? What could be wrong with it in production on Heroku that could cause this to silently fail?
I'm not sure how you are testing it on your development machine, since PeopleControllerTest is empty, but the password field is protected against mass assignment. It shouldn't work in PeopleController the way it is written. (that's a good thing!)
You will need to explicitly call Person#password= in your controller.
The relevant Rails source code for ActiveModel::SecurePassword can show you exactly what happens when you use has_secure_password.
I believe I figured it out. I deployed the app to Heroku, then ran the migrations. The app was not fully aware of the new password_digest column, but new consoles were, so they worked fine. Restarting the app using heroku restart fixed it.

Resources