RodauthApp#call as TURBO_STREAM

[cgrepo]

ArgumentError (There was no default layout for RodauthController...

this happen when session expires and it does not redirect to login page, any comment?

[janko]

Could you post the full error message with backtrace? What does it mean "when session expires" exactly? Does it happen when you enter a URL into the browser, or just when you make a Turbo visit? Does it only happen with Turbo?

[cgrepo]

i have this app where manage session_expires, many of the interactions are turbo_stream actions, when the session expires the app does not do anything and does not send me to login page, im newbie and ill try to put as much information as posible here is the log of that kind of problem:

Started GET "/reports/people_searches" for ::1 at 2022-04-29 13:24:36 -0600
Redirected to /login
Started GET "/login" for ::1 at 2022-04-29 13:24:36 -0600
Processing by RodauthApp#call as HTML
Completed 500 Internal Server Error in 23ms (Views: 0.5ms | ActiveRecord: 0.0ms | Allocations: 7754)

ArgumentError (There was no default layout for RodauthController in #<ActionView::PathSet:0x00007f34ecf09650 @paths=[#<ActionView::FileSystemResolver:0x00007f34eeedda80 @unbound_templates=#<Concurrent::Map:0x00007f34eeedda58 entries=40 default_proc=nil>, @path_parser=#<ActionView::Resolver::PathParser:0x00007f34fc0399d0 @regex=/
          \A
          (?:(?<prefix>.*)\/)?
          (?<partial>_)?
          (?<action>.*?)
          (?:\.(?<locale>[a-z]{2}(?:-[A-Z]{2})?))??
          (?:\.(?<format>html|text|js|css|ics|csv|vcf|vtt|png|jpeg|gif|bmp|tiff|svg|mpeg|mp3|ogg|m4a|webm|mp4|otf|ttf|woff|woff2|xml|rss|atom|yaml|multipart_form|url_encoded_form|json|pdf|zip|gzip|turbo_stream))??
          (?:\+(?<variant>[^.]*))??
          (?:\.(?<handler>raw|erb|html|builder|ruby|jbuilder))?
          \z
        /x>, @path="/home/haisenberg/Documentos/src/RoR/7/7.0.2.3/SII/app/views">, #<ActionView::FileSystemResolver:0x00007f34eeeddc38 @unbound_templates=#<Concurrent::Map:0x00007f34eeeddc10 entries=23 default_proc=nil>, @path_parser=#<ActionView::Resolver::PathParser:0x00007f34fc0399a8>, @path="/home/haisenberg/.rbenv/versions/3.1.1/lib/ruby/gems/3.1.0/gems/actiontext-7.0.2.3/app/views">, #<ActionView::FileSystemResolver:0x00007f34eeeddf58 @unbound_templates=#<Concurrent::Map:0x00007f34eeeddee0 entries=23 default_proc=nil>, @path_parser=#<ActionView::Resolver::PathParser:0x00007f34fc039980>, @path="/home/haisenberg/.rbenv/versions/3.1.1/lib/ruby/gems/3.1.0/gems/actionmailbox-7.0.2.3/app/views">]>):

app/misc/rodauth_app.rb:12:in `block in <class:RodauthApp>'

[janko]

I wasn't able to reproduce this in the official demo app. I enabled Rodauth's session_expiration feature, set max_session_lifetime 5, and called rodauth.check_session_expiration in rodauth app's route block, then I logged in and after 5 seconds I clicked on a link, and I was redirected to the login page without any errors.

Are you using latest turbo-rails and rodauth-rails gem versions? Unless you're able to reproduce this issue in a new Rails app that I can access, I'm afraid I won't be able to help more.

[cgrepo]

using

ruby "3.1.1"
gem "rails", "~> 7.0.2", ">= 7.0.2.3"
gem "rodauth-rails", "~> 1.2"

demo site sii-demo.herokuapp.com janko@siidemo.net testonly click on "Personas" --> "Fisicas" any button after 30 sec and will get an error no redirect

[janko]

I got cleanly redirected to the login page 🤷🏻‍♂️ But even if I did get an error, I wouldn't be able to debug it without access to the code.

I'll close this now, because I still don't have sufficient information. Please reproduce this bug in a fresh new Rails app that you can share code to, like I previously requested. Without me being able to reproduce it on my side, there is nothing I can do.

[cgrepo]

SII-main.zip

[janko]

Thanks for sharing. I ended up finding a pretty important bug, where the Rodauth app would get called for asset requests when using Sprockets or Propshaft (this didn't happen with Webpacker). If authentication is required for all requests (like it was in your app), instead of responding with file contents, asset requests result in redirects. I just fixed this in version 1.4.0.

I don't know if this was related to your bug, though. I tried reproducing the issue with steps you've described, and still didn't get any error when the session expired. It would be best if you can reproduce the error in a system test, which I can run locally and get the same failure.