I customized devise email templates under
views/devise/mailer/ and everything worked fine in development mode.
When I switched to production mode, devise sends email with the default email templates instead of the ones I customized.
Anything that might cause this?
Thanks!
I solved this by restarting my sidekiq. Apparently sidekiq had a cache of the original email template.
Related
I am running a Rails app inside of Vagrant. I am trying to run my app in QA mode to reflect my deployment environment. I am doing SSL termination at the load balancer in my QA environment, so I'd like to be able to run my Rails app only over http, no https anywhere.
I am using Devise for user authentication. I can load my app just fine, but when I log in, devise always wants to redirect onto https. I can't seem to get it to behave differently. I've pinged the devise maintainers for help but they didn't have any insight to share.
I've tried setting config.force_ssl = false but that doesn't seem to make a difference.
I am running the app under Unicorn, proxying to nginx. Any insight would be appreciated!
I think adding something like thi to application.rb this might prevent the issue:
[
config.action_controller.default_url_options,
config.action_mailer.default_url_options,
Rails.application.routes.default_url_options,
Devise::Engine.routes.default_url_options,
Devise::Engine.config.action_controller.default_url_options
].each do |config|
config[:protocol] = "http#{'s' if Rails.env.production}"
end
In addition, you can override a variety of Devise controller methods, by subclassing them. So if you identify the cuplrit method, you can either a) solve the root cause, or b) subclass the controller, to use a workaround instead.
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.
I am using devise 2.0.4 in my rails 3.2 application. I am using the built in devise action mailer to send welcome and password reset emails. One thing I noticed is that devise does not log the email headers to the log file in production environment but does it in the development environment, in production it just logs a line "Sent mail to XXXXXX". I am trying to figure out two things:
How do I give devise my own logger with a log level set?
Is there a way to change the log level that is set in devise, it looks like it is set to INFO now, so can I set it to debug.
Thank you
I'm using custom devise views created by the rails-prelaunch template - https://github.com/RailsApps/rails-prelaunch-signup
In development, everything works fine. I see the devise views I'm expecting (from the views/devise folder).
However, as soon as I switch to production, the app starts using the default devise gem views.
Any ideas as to what might be going on?
Thanks!
I re-created the app, and things just worked. It turns out that there was a problem accessing the template.
I still don't know why the common solutions didn't work, as things seemed to be setup correctly.
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.