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

Dancer2: What is the right way to design a reusable web component?
by vijayvithal jahagirdar 07 Apr '17

07 Apr '17

I would like to use some components across multiple websites and am looking for the best way to package them for reuse. For e.g. say a login page or an admin page will have some static component, some views and some routes +logic. My first thought was to package them into a plugin, but then how do I instruct my main app to pick up the component related views and static files from the plugin folder instead of the views and public folder of my app folder? What is the right way to do this? -- https://www.facebook.com/vijayvithal.jahagirdar https://twitter.com/jahagirdar_vs http://democracies-janitor.blogspot.in/

1 0

Fwd: DPAE and reset passwords (Dancer2::Plugin::Auth::Extensible)
by Nathan Bailey 05 Apr '17

05 Apr '17

On 3 April 2017 at 19:38, Andrew Beverley <andy(a)andybev.com> wrote: > On Mon, 3 Apr 2017 19:15:31 +1000 Nathan Bailey wrote: > > but then clicking the 'Reset password' button doesn't seem to do > > anything. > > As in does a POST request and forwards back to the same page, or > nothing at all? > Back to the same page. > > The "$app->log(...)" statements don't seem to be appearing anywhere, > > is there a 'debug' mode I need to turn on or a config setting to > > direct the logging to a file/Log::Report? > > Yes, you can configure that per-dispatcher (with the mode changed to > DEBUG) but probably easier just to do: > > use Dancer2::Plugin::LogReport mode => 'DEBUG'; > That's in my Main and Extensible.pm but still doesn't seem to give me joy (other logging is working fine, but nothing from Extensible.pm) I've put my own 'warn' statements in each subroutine to see the flow (see below). DPAEPD lacked a 'get_user_by_code' function; I've added the following and now the reset password process is happy. sub get_user_by_code { my ($self, $code) = @_; croak "code must be defined" unless defined $code; # Get our database handle and find out the table and column names: my $database = $self->database; # Get just the username of the user with the matching pw_reset_code my $user = $database->quick_lookup( $self->users_table, { 'pw_reset_code' => $code }, 'username' ); if (!$user) { $self->plugin->app->log("debug", "No such code $code"); return; } else { return $user; } } However, when I try to log in with my reset password, I'm stuck in a loop at https://metacpan.org/source/HORNBURG/Dancer2- Plugin-Auth-Extensible-0.703/lib/Dancer2/Plugin/Auth/Extensible.pm#L266; my home page doesn't seem to want to load. I have a 'get' route for '/' but perhaps something is missing somewhere logged_in_user at /Library/Perl/5.18/Dancer2/Plugin/Auth/Extensible.pm line 593. get_user_details at /Library/Perl/5.18/Dancer2/Plugin/Auth/Extensible.pm line 571. plugin-get_user_details at /Library/Perl/5.18/Dancer2/ Plugin/Auth/Extensible/Provider/Database.pm line 375. Use of uninitialized value in concatenation (.) or string at /Library/Perl/5.18/Dancer2/Plugin/Auth/Extensible.pm line 265. Get here, return_url='', home page='/' at /Library/Perl/5.18/Dancer2/Plugin/Auth/Extensible.pm line 265. thanks, Nathan

2 2

DPAE and reset passwords (Dancer2::Plugin::Auth::Extensible)
by Nathan Bailey 03 Apr '17

03 Apr '17

I'm trying to set up resetting passwords with DPAE (Dancer2::Plugin::Auth::Extensible). When I get a "please follow the link below" email, and click on the link, I'm directed to the standard login page, with "You need to log in to continue" (username/password or password reset). I would expect to be directed to a page asking me for the token, or asking me for a new password, or ...? thanks, Nathan PS: My config is below: Auth::Extensible: # After /logout: If no return_url is given: land here (no default) exit_page: '/' # Mailer options for reset password and welcome emails mailer: module: Mail::Message # Email module to use options: # Options for module via: sendmail # Options passed to $msg->send mail_from: 'example <me(a)example.com>' # From email address # Set to true to enable password reset code in the default handlers reset_password_handler: 1 #password_generator: eAlpaca::User::random_pw # Optional random password generator # Set to a true value to enable recording of successful last login times record_lastlogin: 1 realms: users: provider: 'Database' users_table: 'my_user_table' roles_table: 'user_roles' user_roles_table: 'my_user_roles_table' # roles_id_column: 'id' # roles_role_column: 'role' user_roles_user_id_column: 'my_id' # user_roles_role_id_column: 'roles_id'

2 5

Less granularity from Log::Report than default logging (Was: RESOLUTION: Dancer2::Plugin::LogReport - basic setup)
by Nathan Bailey 03 Apr '17

03 Apr '17

The original issue (in email below) is definitely fixed (I get a nice Log::Report error from it). In a similar vein, however, there is a difference in feedback to the browser with Dancer2::Plugin::Auth::Extensible (trying to get my customised login page working). 1. With Log::Report turned on: Internal Server Error Can't call method "uri" on an undefined value at /Library/Perl/5.18/Dancer2/Plugin/LogReport.pm line 228. 2. Without Log::Report turned on: *Error 500 - Internal Server Error* *Runtime Error* Undefined subroutine &Dancer2::Plugin::Auth::Extensible::login called at /Library/Perl/5.18/Dancer2/Plugin/Auth/Extensible.pm line 282. /Library/Perl/5.18/Dancer2/Plugin/Auth/Extensible.pm around line 282 277 { 278 $app->request->parameters->set('password_code_valid' => 1), 279 } 280 281 no strict 'refs'; 282 return &{ $weak_plugin->login_page_handler }($weak_plugin); 283 }, 284 ); 285 286 $app->add_route( 287 method => 'get', Note that the log file does contain the full report (ie. this is a workable problem, in that I can just go to the log file for the full detail of the issue). cheers, Nathan On 10 February 2017 at 04:08, Andrew Beverley <andy(a)andybev.com> wrote: > On Tue, 7 Feb 2017 Andrew Beverley <andy(a)andybev.com> wrote: > > On Thu, 5 Jan 2017 Nathan Bailey <web(a)polynate.net> wrote: > > > Hi all (especially Andy :-) > > > > Sorry for the delay on this Nathan. > > > > > What are you supposed to put in your non-main route handlers? > > > use Dancer2::Plugin::LogReport mode => 'DEBUG'; (like main route > > > handler); OR > > > use Log::Report; (like other modules) > > > > I can now say that it /should/ be the same as any other route > > handlers. So wherever you have: > > > > use Dancer2; > > > > You should also have: > > > > use Dancer2::Plugin::LogReport ... > > > > Although if you're using the same appname (appname => ...) then you > > only need to use Log::Report. > > > > The reason being that otherwise the required logging hook isn't > > inserted into that particular app. > > > > However, there is a problem with the way the current version of the > > plugin works, which means that the correct DSL isn't always available > > to it. This will cause some unexpected behaviour. I'm working on a fix > > at the moment. > > Fix included in aforementioned v1.19 Log::Report release. Let me know > if you run into any other problems. > > Regards, > > Andy > _______________________________________________ > dancer-users mailing list > dancer-users(a)dancer.pm > http://lists.preshweb.co.uk/mailman/listinfo/dancer-users >

2 1

Dancer2 0.205000 improves application speed, deprecates request->dispatch_path
by Jason A. Crome 10 Mar '17

10 Mar '17

Dancer2 0.205000 is on it's way to CPAN, and brings with it a number of bug fixes, documentation improvements, and enhancements. The changes with the most potential impact to your existing applications include: - Migrating from `MooX::Types` to `Type::Tiny`. This will improve the speed of any Dancer2 application automatically. - Deprecating `request->dispatch_path`. This was originally introduced to fix a buggy `request->path` implementation; fixing `request->path` caused `dispatch_path` to incorrectly fail a route match when `SCRIPT_NAME` was also a prefix of the `PATH_INFO`. `request->path` now functions as intended, and is the preferred method of dispatch. `request->dispatch_path` will throw a warning if used, and will call `request->path` instead. The method will be removed entirely two releases from now. - A new method is being added to Dancer2 applications, `prepare_app()`. This method will eventually get called automatically when `to_app()` is invoked. In preparation of this, any application that may already contain a `prepare_app()` method will complain - loudly - that implementation of this method is coming. Expect to see the final implementation of `prepare_app()` two releases from now. The full release announcement can be seen at http://blogs.perl.org/users/jason_a_crome/2017/03/dancer2-0205000-improves-… Happy Dancing! Jason A. Crome / CromeDome

1 0

Template::Toolkit indentation
by Alex Mestiashvili 28 Feb '17

28 Feb '17

Dear Dancer folks, I am looking for a way to properly indent TT files. Ideally would be a vim plugin, so I could run gg=G and be happy, but any other tool would be useful too. How do you maintain complicated TT templates with many nested if/esle statements? Thanks!

1 0

Problem with web service using dancer2
by Benjamins, John 22 Feb '17

22 Feb '17

Hi, We are using Dancer2 (version is 0.203001) to provide a web service, and this has been deployed in a Docker container. It is using Postgres as a database backend and perl DBI. We are having an issue were the service starts to return error 500 from database queries, even though it is returning what appears to be valid data. Any suggestions on where we should start looking? Restarting the pod running the web service fixes the issue for a while, but after a day or so of activity, the issue comes back. Please let me know if there is any additional information I can provide that would help describe the problem better. Thanks, This message is marked Public Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.

2 5

pass through route
by Alex Mestiashvili 16 Feb '17

16 Feb '17

I have too wide regexp in the route and it matches my javascript which is loaded from the main template the following way. <script type="text/javascript" src="<% request.uri_base %>/javascripts/imagesloaded.pkgd.min.js"></script> Can I create a pass through route which would filter out all /javascript matching ? I mean to filter in the sense that javascript will be parsed by the browser and not by dancer. Or may be I can achieve that with before hooks ? Thanks!

2 1

RESOLUTION: Dancer2::Plugin::LogReport - basic setup
by Nathan Bailey 09 Feb '17

09 Feb '17

Hi all, For the archive/record, see below - all working now. I'd mis-indented the yml config. cheers, Nathan ---------- Forwarded message ---------- Date: 4 January 2017 at 21:18 Subject: Re: [dancer-users] Dancer2::Plugin::LogReport - basic setup Nevermind, I see I indented the yml incorrectly: logger: "LogReport" engines: logger: LogReport: log_format: %a%i%m app_name: AppName dispatchers: logfile: # "default" dispatcher stays open as well type: FILE to: /path/filename.log charset: utf-8 mode: DEBUG now works! And I see that adding the dispatcher line in a test harness lets me write errors to a file rather than stderr too. Brilliant! thanks, Nathan On 4 January 2017 at 19:51, Nathan Bailey <web@ <web(a)polynate.net>...> wrote: > On 4 January 2017 at 19:12, Andrew Beverley <andy@ <andy(a)andybev.com>...> > wrote: > >> On Wed, 4 Jan 2017 Nathan Bailey wrote: >> > 1. Add logging information to my yml >> >> Yes, although if you just want to test it initially, then you don't >> need any config and any messages will go to STDERR (I think). >> > > They happily print to STDERR, they just don't print to the log file :-) > > I have: > # The log level for this environment. Log warning and error messages* [ > presumably this doesn't conflict with the LogReport log levels? ]* > log: 'info' > > logger: "LogReport" > > engines: > logger: > LogReport: > log_format: %a%i%m > app_name: AppName > dispatchers: > logfile: # "default" dispatcher stays open as well > type: FILE > to: /path/filename.log > charset: utf-8 > mode: DEBUG > > >> > 2. Add use Log::Report (); >> >> This is no longer needed (sorry, I thought the docs had been updated). >> > > Okay, so I just have: > use Dancer2; > ... > use Dancer2::Plugin::LogReport mode => 'DEBUG'; # '3' or 'DEBUG' > > in my main route handler module. > > With this config, nothing is being written to my log file (ie. normal > 'info' messages that were getting written with: > logger: "File" > > engines: > logger: > File: > log_dir: "/path" > file_name: "filename.log" > (now removed and replaced with above) are no longer getting written. I > have a 'trace' and 'info' in a non-Dancer module that is writing to stderr. > > Log::Report maintains some global space that all messages go to. When a >> message is logged (regardless of where it is logged from) that will >> trigger the logging code in the Dancer plugin. The Dancer plugin knows >> your config, so it all Just Works. >> > > Nifty! Presumably module-based unit tests need to include Log::Report with > some suitable config/dispatcher? > > thanks, > Nathan >

2 4

Converting from Dancer2::Logger::Syslog to Dancer2::Logger::LogReport
by Clive Eisen 09 Feb '17

09 Feb '17

Hi I’m sure I’m being extremely stupid here but I have tried to read the docs ;-) using the former I get entries in syslog like URL: /getHids in /usr/local/openresty/api/bin/../lib/api.pm l. 47 With the latter I get URL: /getHids I assume I need to tweak the log_format I have tried this (only reference I could find to the format string is in Log4perl) LogReport: log_format: '%a%i%m in %F at %L' But it continues to just display as before - not even with the ‘in’ or the ‘at’ as indeed does commenting it out - so I assume %a%i%m is a default Are the log_format string options defined anywhere? What have I missed? TIA config I am using logger: LogReport: log_format: '%a%i%m in %F at %L' app_name: api dispatchers: default: type: SYSLOG identity: api facility: local0 flags: "pid ndelay nowait" mode: DEBUG logsocket: host: 172.16.101.16 port: 10010 type: udp — Clive Eisen

2 6