Devise: After a unsuccessful registration, clicking refresh raises a no route found error

[Hates]

On a new Rails app (5.0.2) with Devise (4.2.1) submitting the new registration form with invalid data renders the registrations/new.html.erb form with the relevant errors but with the URL /users as opposed to the initial /users/sign_up URL. Pressing the browser's refresh button then causes an error to be raised:

No route matches [GET] "/users"

I have created a base Rails app that shows this: https://github.com/Hates/devise_refresh_error

[azeezahmed]

• Hi, I Scaffolded a user CRUD to check this and was not able to reproduce the issue.

• Checked up with the attached repository and didn't find an users-controller.

• /users would require a users controller with index action (which by default you should have if you have run scaffold)

• Please try scaffolding a users controller and adding root route as devise installation guide describes.

[Hates]

@azeezahmed There's no need to have a UsersController as that's essentially what devise_for :users in routes.rb does. You can see from the rake routes output that it does give you the user paths. There is just no GET path for /users which is what the refresh expects.

                  Prefix Verb   URI Pattern                    Controller#Action
        new_user_session GET    /users/sign_in(.:format)       devise/sessions#new
            user_session POST   /users/sign_in(.:format)       devise/sessions#create
    destroy_user_session DELETE /users/sign_out(.:format)      devise/sessions#destroy
       new_user_password GET    /users/password/new(.:format)  devise/passwords#new
      edit_user_password GET    /users/password/edit(.:format) devise/passwords#edit
           user_password PATCH  /users/password(.:format)      devise/passwords#update
                         PUT    /users/password(.:format)      devise/passwords#update
                         POST   /users/password(.:format)      devise/passwords#create
cancel_user_registration GET    /users/cancel(.:format)        devise/registrations#cancel
   new_user_registration GET    /users/sign_up(.:format)       devise/registrations#new
  edit_user_registration GET    /users/edit(.:format)          devise/registrations#edit
       user_registration PATCH  /users(.:format)               devise/registrations#update
                         PUT    /users(.:format)               devise/registrations#update
                         DELETE /users(.:format)               devise/registrations#destroy
                         POST   /users(.:format)               devise/registrations#create

[azeezahmed]

Yes, GET for /users is missing here.
However, an already present users controller would fill the gap for the missing route.

a possible solution would be

• add note/warning message (when "rails g devise: install" is run) to already have an existing controller so that the fallback URL (/users) will be made available.

or we override devise controllers and add behaviors that suit our need of implementation.

[Hates]

Turns out this is actually an issue with using Turbolinks + Devise. I checked out our projects (Of which none have UsersControllers BTW) and they all worked, the difference being none have Turbolinks enabled.

Would probably be worth adding that to the docs somewhere.

[humphreybc]

@Hates I am running into the exact same problem. Did you end up solving it?

[Hates]

@humphreybc Yeah, turned out to be Turbolinks. I just removed it for the time being, as I haven't got around to looking up how to disable it on that page.

[Elisebassett]

I had the same issue. I just redirected my users index to the new_user_registration_path... a bit of a work around. but it works.

[GinoChiffi]

Removing turbolinks solved the issue for me

[hraynaud]

I have this issue but I'm not using turbolinks? In my case I'm overriding the devise registrations controller but otherwise not doing anything special? Any update on this?

[tegon]

@hraynaud it looks like your issue is the same as https://github.com/plataformatec/devise/issues/4573. Unfortunately, we're not sure yet what's the best solution for this.