Crash on Jumpstart when unconfirmed user tries to log in

Hi  Chris Oliver  
Would love your help with this.

I need my users to confirm their email (because I plan on giving away free trials).  So I have commented out the #skip_confirmation! in app/controllers/users/registrations_controller.rb line #9 and in app/models/user.rb line #65. 

Once I do that, if a user who has signed up, but has not yet confirmed their email, they get a crash. (below)

To reproduce, you can just pull down Jumpstart, comment out those 2 lines, and then try to log in with an unconfirmed email.

I believe this has something to do with the devise / AJAX request / turbolinks.  I've spent about 2 hours on it, but I'm not sure I'm going in the right direction.

Many posts from 2014 said you could just add `respond_to :json, :html` to application_controller.rb but that didn't work for me.

The best idea I had so far from the internet was to overload the sessions_controller so that it responded_to :html and :js

class Customized::SessionsController < Devise::SessionsController
    
  # GET /resource/sign_in
  def new
    self.resource = resource_class.new(sign_in_params)
    clean_up_passwords(resource)
    yield resource if block_given?
    respond_to do |format|
      format.js
      format.html
    end
  end
end

But this gave a different type of error
Here are the best articles I could find about it.
https://www.oarod.com/2017/01/29/turbolinks-with-devise/

https://blog.andrewray.me/how-to-set-up-devise-ajax-authentication-with-rails-4-0/

Thanks!

Interesting. Your url there is a JS request.

/users/sign_in.js

That probably shouldn't be the case, but forms in Jumpstart Pro all do submit with AJAX (for future mobile support!).

I'll have to reproduce this and see what is going on.

You could probably set the registration form to "local: true" so it doesn't submit with AJAX and that would probably fix it.

that worked!! thanks so much  Chris Oliver  

I also had this issue (and it was fixed by adding local:true to the sessions#new form). This came up as a search result when I searched from Google.

I also had this issue (and it was fixed as above by adding local:true to the sessions#new form). Should not this be fixed in the template?