Debugging RouteCsrf::InvalidToken in Rodauth form submissions

[JonMidhir]

I have a small project using Rodauth within a Sinatra application and I'm seeing something really strange. Locally (using Puma) the account creation and login flow works fine but in production (a small server running nginx + Puma) any Rodauth-related actions fail because of a CSRF Token mismatch.

I've tried almost every combination of use_request_specific_csrf_tokens/require_request_specific_tokens and csrf_tag, with and without method and path.

The error I get every time is:

Roda::RodaPlugins::RouteCsrf::InvalidToken: decoded token is not valid for request method and path

Current setup looks like this:

# app.rb
require 'sinatra'

# ... 
                                              
enable :sessions                                                                
                                                                                
class RodauthApp < Roda   
  include Sinatra::ContentFor                   
  include AuthenticationHelpers                                                                                                                                 
  plugin :middleware
  plugin :render, engine: 'haml'
  plugin :route_csrf 

  secret = ENV.delete('RODAUTH_SESSION_SECRET') || SecureRandom.random_bytes(64) 
  plugin :sessions, secret: secret, key: 'auth-session'
  plugin :rodauth, csrf: :route_csrf do
    enable :login, :logout, :create_account
    require_login_confirmation? false  
    require_password_confirmation? false  
    logout_redirect '/'  
    hmac_secret secret 
        
  route do |r| 
    env['rodauth'] = rodauth
    r.rodauth
  end 
end 

use RodauthApp             

get '/' do                               
  # ...

# views/create-account.haml

# ... 
%form.pure-form.pure-form-stacked.authentication{ action: '/create-account', method: 'POST' }
        = rodauth.login_additional_form_tags
        = csrf_tag('/create-account', 'POST')
        %fieldset
          .profile-component
            %label{ for: 'name' } Username
            %input#name{ type: 'text', name: 'name', placeholder: 'Username' }
# ...

The code to generate tokens to be compared is in the route_csrf plugin:

        def csrf_hmac(random_data, method, path)
          OpenSSL::HMAC.digest(OpenSSL::Digest::SHA256.new, csrf_secret, "#{method.to_s.upcase}#{path}#{random_data}")
        end

Since I can't get the csrf_secret from the session I can't back-engineer this and try to figure out which part of the data is different between the two tokens being compared.

Are there any thoughts about how to debug this? Perhaps something I missed in the docs or something else to try besides changing the requirement for path/method?

[janko]

I believe the issue is that you're loading both the sessions roda plugin and Sinatra's sessions, which are two different implementations of sessions, and are probably competing with each other. I don't think you need to load the sessions roda plugin, it should automatically use Sinatra's sessions implementation, since it's stored in rack.session.

[JonMidhir]

@janko The thing is I added the Rodauth session plugin only because I wanted to eliminate Sinatra's session management as being a contributing factor. So if I remove that I see the same effect.

I wonder if solely using Rodauth's session plugin and removing Sinatra sessions would make a difference though. I'll try that.

[jeremyevans]

Note that if you remove the sinatra session support, you won't have session support in sinatra. Roda's session plugin only makes the session information available to the Roda app, not to middleware.

Roda ships with roda/session_middleware, which is a generic session middleware (RodaSessionMiddleware) that can be used by other frameworks. It uses Roda's sessions plugin internally.

[JonMidhir]

I wonder if solely using Rodauth's session plugin and removing Sinatra sessions would make a difference though. I'll try that.

I expected it would break a few things but tried it anyway to no avail. Same error.

Really stumped by this one. I don't see anything in the code that would cause an issue and the only real difference between the environments is the use of nginx and SSL.

I think I'll try deploying a bare-bones app with just Rodauth implemented to see if there's some other library interfering.

[JonMidhir]

OK it's fixed and nothing to do with Rodauth really.

By methods I'm not proud of and which I won't detail here I was able to figure out that the CSRF secret was being cleared out of the session and regenerated in the course of the POST request. Having the CSRF token and both the old and new CSRF secrets I was able to run the HMAC function and compare the hashes. The one generated with the old secret matched, the new one didn't.

A bit of digging turned up this StackOverflow post.

TL:DR; Sinatra's Rack::Protection library clears the session on POST if the HTTP_ORIGIN header is missing. The fix was to set it in the nginx config, .e.g with proxy_set_header Origin http://$host;.

Thanks for all your help @janko @jeremyevans. The princess was in another castle.