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

UTF-8 in Dancer2
by Макс 27 Oct '18

27 Oct '18

Hi! I'm trying to get some non-unicode strings from SQLite DB using Dancer2::Plugin::DBIC and return it to user using Dancer2::Template::TemplateToolkit, but getting Latin1-encoded string (like this: Ð¢ÐµÑÑ) instead of normal text. I have charset: "UTF-8" in my config.yml.

1 1

Dancer2::Session::CHI released
by Jason A. Crome 19 Oct '18

19 Oct '18

I added a new session storage backend for Dancer2 today. Dancer2::Session::CHI is on its way to your local CPAN mirror. If you are currently using CHI in your Dancer2 applications, this will let you use CHI as your backing datastore for storage data. Please see the pod for details. Contact me with any issues you may have, or file them on the github bugtracker. Thanks! Happy Dancing! Jason / CromeDome

1 0

Dancer2 Dancer2::Plugin::Auth::Extensible::Provider::LDAP
by Attila Bárdi 11 Oct '18

11 Oct '18

Hey, I used Ldap with Dancer and it works pretty fine. Now I want to develop a new microsite, I thought it would be better with Dancer2(0.206000). But I cannot make the Ldap (0.702) authentication to work. I turned on the ldap logging. By the log It looks working, because it found the user, but the page says login failed. The second search for the groups has 0 match, the user doesn't member of any group. But I can log in with the user foo, and he is not a member of any group neither. The result is LOGIN FAILED. In the Dancer2 log says: Odd number of elements in anonymous hash at /usr/local/share/perl/5.24.1/Dancer2/Plugin/Auth/Extensible/Provider/LDAP.pm line 279. OpenLdap log: Oct 10 14:35:13 openldap01 slapd[991]: conn=674413 fd=106 ACCEPT from IP=a.b.c.d:47724 (IP=0.0.0.0:389) Oct 10 14:35:13 openldap01 slapd[991]: conn=674413 op=0 BIND dn="cn=Administrator,dc=gothamcity,dc=example,dc=com" method=128 Oct 10 14:35:13 openldap01 slapd[991]: conn=674413 op=0 BIND dn="cn=Administrator,dc=gothamcity,dc=example,dc=com" mech=SIMPLE ssf=0 Oct 10 14:35:13 openldap01 slapd[991]: conn=674413 op=0 RESULT tag=97 err=0 text= Oct 10 14:35:13 openldap01 slapd[991]: conn=674413 op=1 SRCH base="dc=example,dc=com" scope=2 deref=2 filter="(&(objectClass=inetOrgPerson)(uid=battila))" Oct 10 14:35:13 openldap01 slapd[991]: conn=674413 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 10 14:35:13 openldap01 slapd[991]: conn=674413 op=2 SRCH base="dc=example,dc=com" scope=2 deref=2 filter="(&(objectClass=groupOfNames)(member=uid=battila,ou=people,dc=gothamcity,dc=example,dc=com))" Oct 10 14:35:13 openldap01 slapd[991]: conn=674413 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text= Oct 10 14:35:13 openldap01 slapd[991]: conn=674413 op=3 UNBIND Oct 10 14:35:13 openldap01 slapd[991]: conn=674413 fd=106 closed User entry in the openldap: dn: uid=battila,ou=people,dc=gothamcity,dc=example,dc=com cn: Attila Bardi gidNumber: 1901 givenName: Attila loginShell: /bin/bash description: example objectClass: top objectClass: posixAccount objectClass: shadowAccount objectClass: inetOrgPerson shadowInactive: -1 shadowLastChange: 14284 shadowMax: 99999 shadowMin: 0 shadowWarning: 7 sn: Bardi uid: battila uidNumber: 43821 homeDirectory: /home/battila mail: battila(a)example.com structuralObjectClass: inetOrgPerson entryUUID: d3a89750-5a5e-1038-9b9a-dbf2c7148bb9 creatorsName: cn=Administrator,dc=gothamcity,dc=example,dc=com createTimestamp: 20181002071629Z userPassword:: e1e1ee1e1e1e1e1e1e1e1e1e1e1e1e1e1e1e1e1e1e1e entryCSN: 20181002075005.324787Z#000000#000#000000 modifiersName: uid=battila,ou=people,dc=gothamcity,dc=example,dc=com modifyTimestamp: 20181002075005Z Dancer2 config.yml plugins: Auth::Extensible: realms: config: provider: Config users: - user: 'foo' pass: 'secret' users: provider: LDAP host: 'openldap01' binddn: 'cn=Administrator,dc=gothamcity,dc=example,dc=com' bindpw: 'secret' basedn: 'dc=example,dc=com' user_filter: '(objectClass=inetOrgPerson)' username_attribute: "uid" I tried *disable_roles: 1 *after this but the result is still LOGIN FAILED. I tried to turn on debugging, as I saw the Dancer2::Plugin::Auth::Extensible::Provider::LDAP module has some messages sending with debug, but they haven't been displayed. log: 'core' startup_info: 1 show_errors: 1 logger: console What do I do wrong? Shall I go back to Dancer1? Thanks! Best regards, Attila

2 3

Dancer2::Logger::Log4perl released
by Jason Crome 06 Oct '18

06 Oct '18

We’ve been missing a Log4perl plugin for Dancer2 for, well, forever, and today I have released Dancer2::Logger::Log4perl. This was originally developed by Ryan Larscheidt and Jon Miner at the University of Wisconsin. I have added a minimal test, a little pod, and wrapped a release around it. The rest of this is their work, and I cannot thank them enough for their work on this. There are more tests needed still, but I wanted to get this out in the wild as soon as I could. If you notice any issues, please report them at https://github.com/cromedome/Dancer2-Logger-Log4perl/issues Thanks, and happy dancing! — cromedome Jason A. Crome / CromeDome CPAN: https://metacpan.org/author/CROMEDOME github: https://github.com/cromedome Twitter: https://twitter.com/cromedome

1 0

dancer2's send_error() from module
by icovnik 01 Oct '18

01 Oct '18

Hello, I'm using Dancer2 for some small apps and now I came across some difficulty when using Dancer2's send_error() function. This function is meant to be used to emit HTTP error to client (of course) and to stop processing current route at that point. It works OK if I use send_error() in route directly or in some subroutine in current module/package. But if I use send_error() from another module, it doesn't stop there. The same if Other module is in the same file or use'd from Other.pm. So the question: how to properly use send_error() from another module to finish the route right there on the spot? Thanks ico Example code: package Server; use Dancer2; get '/test' => sub { #send_error("err", 401); # 1: end of processing, error 401 #myfunc(); # 2: end of processing, error 402 Other::func(); # 3: processing continues, route returns 200 OK return "OK"; }; sub myfunc { send_error("err", 402); # never hits this spot } 1; package Other; use Dancer2; sub func { send_error("err", 403); # happily continues here } 1;

1 0

Get backtrace for stuck Dancer process
by Warren Young 29 Sep '18

29 Sep '18

I’ve got a long-running Dancer app which froze up today for no obvious reason, with no useful logs either at the Apache front-end proxy level or at the Dancer level. If this were a program written in a language that compiles to native code, I’d force a core dump and do a backtrace on the process in a debugger to find out where it got hung up, which would usually tell me how to avoid that problem. Is there a way to do that with Perl, and if not, can anyone suggest an alternative? My best alternative is to set up some kind of watchdog, but I’d rather avoid the problem in the first place, if possible.

4 7

Fwd: confirm 14905a77eeca3a4a80eff409487ffdee91d2ae0d
by Le cafe Pattaya 24 Sep '18

24 Sep '18

????????? Outlook for Android<https://aka.ms/ghei36> ________________________________ From: dancer-users <dancer-users-bounces(a)dancer.pm> on behalf of dancer-users-request(a)dancer.pm <dancer-users-request(a)dancer.pm> Sent: Monday, September 24, 2018 11:31:05 PM To: lecaferoyale(a)hotmail.com Subject: confirm 14905a77eeca3a4a80eff409487ffdee91d2ae0d Mailing list subscription confirmation notice for mailing list dancer-users We have received a request from 183.89.7.249 for subscription of your email address, "lecaferoyale(a)hotmail.com", to the dancer-users(a)dancer.pm mailing list. To confirm that you want to be added to this mailing list, simply reply to this message, keeping the Subject: header intact. Or visit this web page: http://lists.preshweb.co.uk/mailman/confirm/dancer-users/14905a77eeca3a4a80… Or include the following line -- and only the following line -- in a message to dancer-users-request(a)dancer.pm: confirm 14905a77eeca3a4a80eff409487ffdee91d2ae0d Note that simply sending a `reply' to this message should work from most mail readers, since that usually leaves the Subject: line in the right form (additional "Re:" text in the Subject: is okay). If you do not wish to be subscribed to this list, please simply disregard this message. If you think you are being maliciously subscribed to the list, or have any other questions, send them to dancer-users-owner(a)dancer.pm.

1 0

extends issue
by Zahir Lalani 20 Sep '18

20 Sep '18

Hi all Have a very odd problem. We are extending a class but getting this error when running from dancer as a web app: Can't locate package jobs::dom::job_base_dom for @job_dom::ISA If we mimic the same setup in a command line app, it works fine. We are doing extends 'jobs::dom::job_base_dom'; Any ideas about what this means? Z

2 1

How to bundle and use Plugin Specific views?
by vijayvithal jahagirdar 07 Sep '18

07 Sep '18

Hi, I am creating function specific modules that can be used across multiple applications. These modules has associated views/function/*.tt files. When Installed from CPAN these files will reside in the system-Perl folder... My reading of the document indicates that Dancer2 searches for the view files only in the $appdir/views. 1. How do I ensure that it also picks up the templates from the Perl install path? 2. Is there a module on CPAN which solves this problem? Regards Vijay -- https://www.facebook.com/vijayvithal.jahagirdar https://twitter.com/jahagirdar_vs http://democracies-janitor.blogspot.in/

2 1

Dancer 1.3400 released to CPAN - security fix, bugfixes and minor improvements
by David Precious 16 Jun '18

16 Jun '18

Hi all, I'm pleased to say Dancer 1.3400 has just been released to CPAN. it contains one security-related improvement, several bugfixes, and a couple of minor enhancements. Nothing groundbreaking, but the security update is worth updating for if you use a session engine where the session ID from the client is used in a way where injection is possible. One thing to be aware of is the changes to how request->body gets you the raw request. In the past, we used to keep a copy of the request body in RAM, which could of course be very inefficient for huge requests. In PR #1134, I stopped us doing so, replacing request->body with a convenience method which would read & return the body from the temp file that HTTP::Body writes it to, so if you need the raw body, you can still get it, but otherwise don't have the RAM overhead. *However*, that led to confusion, because HTTP::Body only keeps the raw request body in a temp file for certain types of request. So, now, we have a new setting, raw_request_body_in_ram, which controls the original "keep a copy of the request body as we parse it" behaviour. If it's true, then a copy is kept, you suffer the memory hit, but request->body will always return you the raw request body. If you don't need access to it, though, set that setting to false and enjoy lower memory usage. For more details see https://github.com/PerlDancer/Dancer/pull/1178 Summary of changes: [SECURITY] - Validate session IDs read from client - GH #1172 - potential security risk if the session provider in use passes the session ID in a way where injection is possible. [BUGFIXES] - Avoid accidental route matches if a previous successful match had left %+ populated (GH 1187, PR 1188, bigpresh, reported by skington) - Avoid request body truncation in hand-assembled requests in tests (PR 1148, skington) - require MIME::Types 2.17, as 2.16 has some funny ideas, like responding to a ZIP file with 'application/vnd.easykaraoke.cdgdownload' - Fix YAML-related test failures if YAML::XS not installed (GH 1184, PR 1189, bigpresh) - Avoid tests failing when "localhost" doesn't resolve (PR 1142, gbarco) - Avoid test failures due to race condition in selecting a port to listen on by using 127.0.0.10 instead (more of a hacky workaround than a fix, but should help (bigpresh) - Try to use 127.0.0.11 for listen tests, fall back to 127.0.0.1 on systems that don't have 127/8, e.g. FreeBSD (GH 1183, PR 1185, bigpresh) - More temp directory handling fixes (Issue #1147) - Fix YAML session handler under taint mode (chrisjrob) [ENHANCEMENTS] - Let Dancer::Test::dancer_response() handle supplying multiple params with the same name - Issue 1116 (bigpresh) - Add environment var hint to cookbook (PR 1161, castaway) - Make it possible to switch out YAML for YAML::XS for config parsing and serialisation (there was already an attempt at this in place, and it was documented as posisble, but didn't work) (PR 1164, 1nickt) - New test method response_redirect_like (PR 1159, 1nickt) - New config option raw_request_body_in_ram, which controls whether the raw request body is available via request->body or not. See Issue #1140 for the problems the previous approach, of getting it from the temp file that HTTP::Body might (or might not) have written it to. - Better doc for forward_for_address (PR 1146, Relequestual) Cheers Dave P

2 2