railsadminteam / rails_admin

RailsAdmin is a Rails engine that provides an easy-to-use interface for managing your data
MIT License
7.87k stars 2.25k forks source link

Devise integration not workig #3599

Closed gabrieletassoni closed 1 year ago

gabrieletassoni commented 1 year ago

Describe the bug Using a newly created rails 7 app, I tried Devise for authentication of the rails_admin application. Whenever I login with a valid username and password, I always got redirected to the users/sign_in action. Looking at the logs I can clearly see that the user's session is ok after the login, but I see that after the redirection to http://localhost:3000/app/, the current_user becomes null. Example of relevant log:

I, [2023-02-07T23:20:10.942198 #39912]  INFO -- : Started POST "/users/sign_in" for 127.0.0.1 at 2023-02-07 23:20:10 +0000
I, [2023-02-07T23:20:10.944436 #39912]  INFO -- : Processing by Devise::SessionsController#create as HTML
I, [2023-02-07T23:20:10.946015 #39912]  INFO -- :   Parameters: {"authenticity_token"=>"[FILTERED]", "user"=>{"login"=>"admin@example.com", "password"=>"[FILTERED]", "remember_me"=>"0"}, "commit"=>"Accedi"}
D, [2023-02-07T23:20:10.954484 #39912] DEBUG -- :   User Load (2.0ms)  SELECT "users".* FROM "users" WHERE (lower(username) = 'admin@example.com' OR lower(email) = 'admin@example.com') ORDER BY "users"."id" ASC LIMIT $1  [["LIMIT", 1]]
D, [2023-02-07T23:20:11.064313 #39912] DEBUG -- :   TRANSACTION (0.2ms)  BEGIN
D, [2023-02-07T23:20:11.064996 #39912] DEBUG -- :   User Update (0.4ms)  UPDATE "users" SET "sign_in_count" = $1, "current_sign_in_at" = $2, "last_sign_in_at" = $3, "updated_at" = $4, "lock_version" = $5 WHERE "users"."id" = $6 AND "users"."lock_version" = $7  [["sign_in_count", 25], ["current_sign_in_at", "2023-02-07 23:20:11.062636"], ["last_sign_in_at", "2023-02-07 23:16:14.289203"], ["updated_at", "2023-02-07 23:20:11.062950"], ["lock_version", 26], ["id", 1], ["lock_version", 25]]
D, [2023-02-07T23:20:11.068061 #39912] DEBUG -- :   TRANSACTION (2.6ms)  COMMIT
reject_locked #<User:0x00007f0d2ce4c128>
D, [2023-02-07T23:20:11.082076 #39912] DEBUG -- :   Permission Load (1.1ms)  SELECT "permissions".* FROM "permissions" INNER JOIN "permission_roles" ON "permission_roles"."permission_id" = "permissions"."id" INNER JOIN "roles" ON "roles"."id" = "permission_roles"."role_id" INNER JOIN "role_users" ON "role_users"."role_id" = "roles"."id" INNER JOIN "users" ON "users"."id" = "role_users"."user_id" WHERE "users"."id" = $1 ORDER BY "permissions"."id" ASC  [["id", 1]]
D, [2023-02-07T23:20:11.083262 #39912] DEBUG -- :   ThecoreSettings::Setting Load (0.3ms)  SELECT "thecore_settings".* FROM "thecore_settings" WHERE "thecore_settings"."ns" = $1  [["ns", "main"]]
I, [2023-02-07T23:20:11.086029 #39912]  INFO -- : Redirected to http://localhost:3000/app/
I, [2023-02-07T23:20:11.086167 #39912]  INFO -- : Completed 302 Found in 139ms (ActiveRecord: 12.0ms | Allocations: 7840)
I, [2023-02-07T23:20:11.090215 #39912]  INFO -- : Started GET "/app/" for 127.0.0.1 at 2023-02-07 23:20:11 +0000
I, [2023-02-07T23:20:11.091013 #39912]  INFO -- : Processing by RailsAdmin::MainController#dashboard as HTML
I, [2023-02-07T23:20:11.091739 #39912]  INFO -- : Completed 401 Unauthorized in 1ms (ActiveRecord: 0.0ms | Allocations: 368)
I, [2023-02-07T23:20:11.097291 #39912]  INFO -- : Started GET "/users/sign_in" for 127.0.0.1 at 2023-02-07 23:20:11 +0000
I, [2023-02-07T23:20:11.098119 #39912]  INFO -- : Processing by Devise::SessionsController#new as HTML
reject_locked 

As you can see, I print the current_user.inspect as a before_action of ApplicationController, the rows starting with "reject_locked", after the actual login it states reject_locked #<User:0x00007f0d2ce4c128> after the unauthorized 401, the line just states reject_locked. Maybe this is normal, since comes after a 401 Unathorized, but the bug is here: why it throws an Unauthorized but the sign_in is ok?

Reproduction steps

rails new . --database=postgresql --asset-pipeline=sprockets --skip-git
rails g rails_admin:install --asset=sprockets
rails generate devise:install
rails generate devise User
rails active_storage:install
rails action_text:install
rails action_mailbox:install
rails db:migrate

Enable by uncomment the Devise part in the rails_admin.rb initializer. then rails s Sign In and the problem is there.

Expected behavior The current_user must be there also after the succesfull login in the Rails Admin routes.

Additional context

codealchemy commented 1 year ago

I was unable to reproduce this following the steps provided (needed to add a couple steps to specify the rails_admin and devise gems in the Gemfile - and I used SQLite instead of PG - but otherwise followed these exactly and am able to login without issue).

I see a couple queries to models not covered in your repro steps (eg. Permissions, which I'm guessing that's where the issue stems from) - please include your rails_admin initializer and any additional configuration needed, or reproduce the issue in a separate repo.

gabrieletassoni commented 1 year ago

I see a couple queries to models not covered in your repro steps (eg. Permissions, which I'm guessing that's where the issue stems from) - please include your rails_admin initializer and any additional configuration needed, or reproduce the issue in a separate repo.

Yes, you are right, starting completely from scratch, without any added Gem, it works flawlessy. I need to add gems one by one to understand what's going on. The thing was completely working for years in different projects from rails 5 to rails 6.1 and I made some gems that helped me bootstrapping an application in a fast way, but with rails 7 and ruby 3.1 something has changed and I need to port all the gems I maintain to the new setup (latest rails_admin, rails and ruby), one by one.

Thank you for the hint, closing this.