March 2019 - dancer-users - lists.preshweb.co.uk

Debugging sessions
by Nikola Mitev 29 Jun '23

29 Jun '23

Hi all, I have an annoyingly intermittent problem where on successful authentication the session info disappears and the user is endlessly redirected to the login page. It happens about once a month on a site with 10-20 logins daily. Once it happens to a user, it keeps happening for that user only. A restart of the app usually fixes the issue, and I am yet to see someone who had this problem to report it again at a later stage. Had about 10 cases so far in total. The cookie is generated on accessing the login page, stored in the browser and sent with the login POST request so I can verify cookies are enabled. The user is then authenticated, data added to the session including an 'authenticated' flag and they are redirected to their dashboard. Right before the redirection the session data is present. They make a request for the dashboard following the redirect, this triggers a session authenticated check which fails as no data is available for the session. They are then redirected for authentication and so on in a loop. If I restart the app the issue vanishes. hook before => sub { # <snip> if (!session('authenticated')) { forward '/login'; } } post '/login' => sub { # user authentication and session storage here, then the debug code and the redirecton: my $authenticated = session('authenticated'); $log->info("User authenticated ($authenticated), redirecting to $target_route"); return redirect $target_route; }; I don't have an explicit check on cookie size - not sure how to check it doesn't exceed 4K - but find it unlikely this is the issue. If that was the problem it should be happening persistently for a user regardless of restarts etc? Hope all this makes sense, I am looking for general advice on how to troubleshoot this but any ideas at all will be very much appreciated. Nik

4 11

Dancer crashing
by Hermann Calabria 24 May '19

24 May '19

I have a large Dancer application that crashes rarely with the attached stack trace. I haven’t yet identified any specific code or pattern that triggers the crash; if I restart (perl ./bin/app.pl) and repeat exactly what I was doing prior to the crash, it usually works just fine. Versions: Perl 5.26.2 Dancer 1.3500 Is this a known problem? Solutions? Stack trace: Use of uninitialized value in subroutine entry at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/HTTP/Server/Simple.pm line 397. HTTP::Server::Simple::__ANON__("Dancer::Handler::Standalone::NetServer0") called at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/HTTP/Server/Simple.pm line 342 HTTP::Server::Simple::__ANON__("Dancer::Handler::Standalone::NetServer0", "port", 8080) called at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/HTTP/Server/Simple.pm line 306 HTTP::Server::Simple::run(Dancer::Handler::Standalone=HASH(0x562484f61698)) called at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/Dancer/Handler/Standalone.pm line 38 Dancer::Handler::Standalone::start(Dancer::Handler::Standalone=HASH(0x56247b0cf578)) called at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/Dancer/Handler.pm line 209 Dancer::Handler::dance(Dancer::Handler::Standalone=HASH(0x56247b0cf578)) called at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/Dancer.pm line 496 Dancer::_start() called at ./bin/app.pl line 235 Bad arg length for Socket::sockaddr_family, length is 0, should be at least 2 at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/HTTP/Server/Simple.pm line 397. HTTP::Server::Simple::__ANON__("Dancer::Handler::Standalone::NetServer0") called at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/HTTP/Server/Simple.pm line 342 HTTP::Server::Simple::__ANON__("Dancer::Handler::Standalone::NetServer0", "port", 8080) called at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/HTTP/Server/Simple.pm line 306 HTTP::Server::Simple::run(Dancer::Handler::Standalone=HASH(0x562484f61698)) called at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/Dancer/Handler/Standalone.pm line 38 Dancer::Handler::Standalone::start(Dancer::Handler::Standalone=HASH(0x56247b0cf578)) called at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/Dancer/Handler.pm line 209 Dancer::Handler::dance(Dancer::Handler::Standalone=HASH(0x56247b0cf578)) called at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/Dancer.pm line 496 Dancer::_start() called at ./bin/app.pl line 235 Thanks in advance!

7 15

potential memory leak?
by Zahir Lalani 21 Mar '19

21 Mar '19

Hi All We have a weird issue and suspect its possibly a memory leak. I need some guidance as to how to debug this and solve it. We use Dancer2 and Starman, fronted by Apache Use Case: We have an image gallery where the user can browse images based on a variety of criteria. The gallery is page driven, and the user navigates using previous/next buttons. Each page displays 36 images. Although starman handles all routes, it does not handle the delivery of the images. We use an apache module called xsend which offloads the delivery to apache and allows starman to focus on data queries. We find that for certain clients who use the gallery heavily, after many page navigations some of the images on the page cause 302's and loses the session, so the user has to login again. We can run the image route in another browser session and its fine. The "break" does not happen at a consistent place. The code that does xsend relies on "halt" as follows: Sub send_the_file{ # do the queries to get the image details and physical path # now make the xsend request: header('Content-Type' => $mime); header("X-Sendfile" => $file); header('Content-Disposition' => "inline; filename=\"".encode_utf8($file_name)."\";"); debug('halting for xsend'); halt('xsend'); } This method is called through multiple code layers. From what I can tell, halt replace return, but it also says that it stops processing at the point of halt. We have been looking through logs and cannot see anything specific apart from the 302's and loss of session. Any guidance on how to proceed with this would be much appreciated Z

1 1