I'm lost! Login via JWT is blocked for missing session[:account_id]?

[pboling]

I am trying to get a setup which allows both the HTML/REST authentication and auth via JWT. Once authenticated I hope to protect some Rails routes with this authentication. Authentication is working fine as long as I stick to the standard Rodauth routes for account management.
When I send a request to a Rails route, protected by constraints Rodauth::Rails.authenticate do it is routing there properly, and via a plethora of breakpoints throughout the rodauth and rodauth-rails code I've pinpointed the exact point where the middleware throws back the 401 error.

require_authentication

This is the method that triggers the 401. The chain from there is:
require_authentication => require_login => login_required unless logged_in?

login_required is throwing the 401 response, but why? The request has a valid JWT as a Bearer token Authorization header, extracted from the previous response to the verify-account request, so it seems to me like logged_in? should work, since I have the jwt feature turned on (and JWT fully works within all of roadauth's auth protected routes).

But when I look at the definition of logged_in?: it is aliased to:

    def session_value
      session[session_key]
    end

and from my debug session:

(ruby) session[session_key]
nil
(ruby) session_key
:account_id

I can't find anywhere that this key would be set, and I don't understand why JWT would be looking at sessions, and more, only looking at sessions, to determine logged_in?.

[pboling]

Additionally, why does the JWT feature deal with a Session at all?

    def session
      return @session if defined?(@session)
      return super unless use_jwt?

      s = {}
      if jwt_token
        unless session_data = jwt_payload
          json_response[json_response_error_key] ||= invalid_jwt_format_error_message
          _return_json_response
        end

        if jwt_session_key
          session_data = session_data[jwt_session_key]
        end

        if session_data
          if jwt_symbolize_deeply?
            s = JSON.parse(JSON.fast_generate(session_data), :symbolize_names=>true)
          elsif scope.opts[:sessions_convert_symbols]
            s = session_data
          else
            session_data.each{|k,v| s[k.to_sym] = v}
          end
        end
      end
      @session = s
    end

    def clear_session
      super
      if use_jwt?
        session.clear
        set_jwt
      end
    end

And how critical is using cookie store for rodauth-rails? The documentation shows usage of Cookies as the session store, but this doesn't work for me, as the app is using :redis_store for sessions. Is there any way to make this work?

[janko]

Rodauth operates with the session object as a hash, which should support all Rails session stores (cookie, redis, Active Record etc). In what way does the Redis session store not work you?

JWT mode doesn't actually use Rails session, as you can see from the implementation. It stores session data in a plain hash, which ends up in the JWT token payload. This enables it to work exactly the same way as with Rails session, just with the JWT token acting as session data storage.

I couldn't reproduce the routing constraint not working with JWTs. I made the below changes to the demo app, and accessing an authenticated route worked. Can you reproduce the issue in a fresh Rails app with a failing integration test?

Changes

diff --git a/app/controllers/posts_controller.rb b/app/controllers/posts_controller.rb
index c4360a0..7d2d4a6 100644
--- a/app/controllers/posts_controller.rb
+++ b/app/controllers/posts_controller.rb
@@ -1,10 +1,15 @@
 class PostsController < ApplicationController
-  before_action :authenticate
+  # before_action :authenticate
   before_action :set_post, only: [:show, :edit, :update, :destroy]
 
   # GET /posts
   def index
     @posts = current_account.posts.all
+
+    respond_to do |format|
+      format.html
+      format.json { render json: @posts }
+    end
   end
 
   # GET /posts/1
diff --git a/config/routes.rb b/config/routes.rb
index d33e301..8e96fb0 100644
--- a/config/routes.rb
+++ b/config/routes.rb
@@ -1,6 +1,8 @@
 Rails.application.routes.draw do
   root to: "home#index"
-  resources :posts
+  constraints Rodauth::Rails.authenticate do
+    resources :posts
+  end
 
   namespace :admin do
     root to: "home#index"
diff --git a/test/controllers/posts_controller_test.rb b/test/controllers/posts_controller_test.rb
index dde4dab..46dc0cf 100644
--- a/test/controllers/posts_controller_test.rb
+++ b/test/controllers/posts_controller_test.rb
@@ -2,13 +2,13 @@ require "test_helper"
 
 class PostsControllerTest < ActionDispatch::IntegrationTest
   test "should require authentication" do
-    get posts_url
+    get posts_url, as: :json
 
-    assert_redirected_to "/login"
+    assert_response :unauthorized
 
     login
 
-    get posts_url
+    get posts_url, as: :json, env: { "HTTP_AUTHORIZATION" => response.headers["Authorization"] }
 
     assert_response :success
   end
@@ -16,16 +16,9 @@ class PostsControllerTest < ActionDispatch::IntegrationTest
   private
 
   def login(login: "[email protected]", password: "secret123")
-    post "/create-account", params: {
-      "name"             => "Janko",
-      "email"            => login,
-      "password"         => password,
-      "password-confirm" => password,
-    }
-
     post "/login", params: {
-      "email"    => login,
-      "password" => password,
-    }
+      "email"    => "[email protected]",
+      "password" => "password",
+    }, as: :json
   end
 end

[pboling]

I saw some things I was doing wrong based on your changes above, and fixed my code. I now have it nearly all working. The one, very strange thing that still doesn't work, though I did have it working at some point previously, is create-account, but only when called via JSON. When I access it via GET and use the views to create the account it works perfectly.

When I send a JSON request for create-account I get a 200 status response, with an {} json. It has a valid JWT in the header, but it doesn't actually create the account.

Oh wow. Figured it out before I submitted this comment. If I am already logged in, and my request (Postman) accidentally picks up the prior JWT, then create-account spins out into a really weird place. It doesn't even get handled as a create-account (I had a breakpoint set that was never hit), but there are no errors.