sec results from the CPAN

Acme-CPANModulesBundle-Import-PerlDancerAdvent-2018

Welcome to the Twelve Days of Dancer!</p>
<p>This year's calendar features twelve posts that cover a wide range of topics.
We feature several new authors, cover some new ground (for us!) with an
article on accessibility, and even have a crossover post showing how Dancer
can be used with other frameworks.</p>
<p>Without further ado, let's dance!</p>
<h2><a name="state_of_the_dancer"></a>State of the Dancer</h2>

<p>In 2017 and 2018, we saw fewer but more significant updates to Dancer and 
Dancer2. With Dancer (1) being in maintenance mode, updates come only when
significant bugs are found, security vulnerabilities are found, or when a 
change is proposed that greatly improve the lives of Dancer developers. 
David Precious has been the light that guides Dancer(1) through the night,
and has been an excellent resource for both the Dancer and Dancer2 communities
on IRC and email.</p>
<p>Meanwhile, Dancer2 continues to grow and evolve, though at a less frantic rate
than earlier in its lifetime. Throughout the last two years, we've seen a 
growing list of contributions from our community, through documentation 
improvements, bug fixes, and new features.</p>
<p>At the end of 2017, the Dancer Core Team ran a survey of Dancer developers to
get community input on the Dancer project. We received an excellent response

devdata/http_advent.perldancer.org_2018_13 view on Meta::CPAN

from scratch. The current docs lack a good description of why Dancer does 
things a certain way, and doesn't give new users a good grounding in web 
application design to know how and why some things should be done the way
we've recommended. The new doc project aims to address this by detailing 
important concepts in a clear and simple way.</p>
<h2><a name="performance_improvements"></a>Performance Improvements</h2>

<p>Several important performance improvements were made to Dancer2, the most
important of which being the migration from <code>MooX::Types</code> to <code>Type::Tiny</code>. 
When <code>Type::Tiny::XS</code> is used, the boost is even more significant.</p>
<h2><a name="security_improvements"></a>Security Improvements</h2>

<p>Two important security features were added:</p>
<p>The session engine now requires a <code>validate_id()</code> method to be implemented in
the various session engines. This requirement shuts down an attack vector by
making session IDs conform to a known format.</p>
<p>SysPete implemented a <code>change_session_id</code> keyword to easily change the 
current session ID. This is a common (and recommended) security practice,
especially when privilege level changes within an application.</p>
<h2><a name="author"></a>Author</h2>

<p>This article has been written by Jason Crome (CromeDome) for the Perl Dancer 
Advent Calendar 2018.</p>
<h2><a name="copyright"></a>Copyright</h2>

<p>No copyright retained. Enjoy.</p>
<p>Jason A. Crome</p>
</div>

devdata/http_advent.perldancer.org_2018_16 view on Meta::CPAN


    if( exists $minion_config-&gt;{ $hostname }) {
        return $minion_config-&gt;{ $hostname };
    } else {
        return $minion_config-&gt;{ default };
    }
}</pre>

<h2><a name="monitoring_the_workers"></a>Monitoring the Workers</h2>

<p>Our Minion dashboard was virtually identical to the one that @preaction posted in <a href="https://mojolicious.io/blog/2018/12/11/who-watches-the-minions/#section-2">Who Watches the Minions?</a>.
If you'd like to know more, I highly recommend reading his article.</p>
<h2><a name="outcome"></a>Outcome</h2>

<p>Within about a two-week timespan, we went from having zero practical knowledge of Minion to having things up and running. We've made some refinements and improvements along the way, but the quick turnaround
is a true testament to the simplicity of working with Minion.</p>
<p>We now have all the necessary pieces in place to scale our XML rendering both horizontally and vertically: thanks to Minion, we can easily run XML jobs across multiple boxes, and can more efficiently run 
more jobs concurrently on the same hardware as before. This setup allows us to grow as quickly as our customer base does.</p>
<h2><a name="author"></a>Author</h2>

<p>This article has been written by Jason Crome (CromeDome) for the Perl Dancer

devdata/http_advent.perldancer.org_2018_19 view on Meta::CPAN

log4perl.appender.LOG1           = Log::Log4perl::Appender::File
log4perl.appender.LOG1.filename  = logs/mylog.log
log4perl.appender.LOG1.mode      = append
log4perl.appender.LOG1.layout    = Log::Log4perl::Layout::PatternLayout
log4perl.appender.LOG1.layout.ConversionPattern = %d %p %m %n</pre>

<p>The first one defines our root application logger. The first parameter after the equals sign says
what is the minimum level we should log. Since we are saying the minimum log level should be <code>DEBUG</code>,
any messages from Dancer2 itself, and anything logged at the <code>core</code> level will be ignored.</p>
<p>After the minimum log level is a comma-separated list of appenders to write to. For now, we will create a
single appender named <code>LOG1</code> (we will see how to add a second appender below).  This will write
to a file in the <i>logs/</i> directory named <i>mylog.log</i>, using the <a href="https://metacpan.org/pod/Log::Log4perl::Appender::File">Log::Log4perl::Appender::File</a>
appender. When the app is started, it will append to an existing log file of that name (or create the file
if necessary), and will write to it with a format specified by <a href="https://metacpan.org/pod/Log::Log4perl::Layout::PatternLayout">Log::Log4perl::Layout::PatternLayout</a>.</p>
<p>Each appender can have its own configuration directives. Please consult the pod for each appender for a list
of its configuration parameters.</p>
<p>Next, we have to tell our application that we are using <code>Dancer2::Logger::Log4perl</code> as our preferred logger.
Edit your <i>environments/development.yml</i> file, and comment out the <code>logger: "console"</code> line. Replace it
with the following:</p>
<pre class="prettyprint">logger: log4perl
log: core

devdata/http_advent.perldancer.org_2018_19 view on Meta::CPAN

    debug "I'M IN UR INDEX";
    template 'index' =&gt; { 'title' =&gt; 'TestLog4perl' };
};</pre>

<p>Start your application and visit <code>http://localhost:5000/</code>. You will see the following in your <i>logs/mylog.log</i> file:</p>
<pre class="prettyprint">2018/12/18 21:36:02 DEBUG I'M IN UR INDEX</pre>

<h2><a name="hey__i_can_t_see_my_log_messages_on_the_screen_"></a>Hey, I can't see my log messages on the screen!</h2>

<p>That's because we didn't add a screen appender! With Log4perl, adding another appender is easy. Let's
add another section to our <i>log4perl.conf</i> file:</p>
<pre class="prettyprint">log4perl.appender.SCREEN         = Log::Log4perl::Appender::Screen
log4perl.appender.SCREEN.stderr  = 0
log4perl.appender.SCREEN.layout  = Log::Log4perl::Layout::PatternLayout
log4perl.appender.SCREEN.layout.ConversionPattern = %m %n</pre>

<p>This creates another appender named <code>SCREEN</code>. We then need to tell our root logger to use this appender
as well:</p>
<pre class="prettyprint">log4perl.rootLogger = DEBUG, LOG1, SCREEN</pre>

<p>Now, restart your application, and visit a route that has logging installed, and you will see your log

devdata/http_advent.perldancer.org_2018_21 view on Meta::CPAN

    border: 0;
    clip: rect(0 0 0 0);
    height: 1px;
    margin: -1px;
    overflow: hidden;
    padding: 0;
    position: absolute;
    width: 1px;
}</pre>

<p>The second preventative measure simply puts a hidden field on the page:</p>
<pre class="prettyprint">&lt;input type="hidden" name="spam_two"&gt;</pre>

<p>Screen readers know to ignore this because it's hidden, and because it's hidden, the page won't show this field.
As a user, you won't ever have to fill it in.</p>
<p>Thankfully, a lot of spam bots are stupid, and blindly fill in any form field they see. They can't parse the CSS
in such a way that they can tell one of the fields is unusably hidden, and they often don't pay attention to
the hidden attribute... so they fall right into our trap. Enjoy your free education, spambot!</p>
<h2><a name="final_thoughts"></a>Final thoughts</h2>

<p>Is it foolproof? No, not by a longshot. Anyone who really wants to is going to find a way to spam you anyhow,

devdata/http_advent.perldancer.org_2018_23 view on Meta::CPAN


<p>The <code>colored_levels</code> are the log levels themselves.</p>
<pre class="prettyprint">[main:28764] debug @2018-12-19 20:31:06&gt; Hello World in test.pl l. 6
             ^^^^^</pre>

<p>And the <code>colored_messages</code> refer to the actual message.</p>
<pre class="prettyprint">[main:28764] debug @2018-12-19 20:31:06&gt; Hello World in test.pl l. 6
                                         ^^^^^^^^^^^</pre>

<p>The colors are the same kind of color strings used by <a href="https://metacpan.org/module/Term::ANSIColor">Term::ANSIColor</a>. The first
color refers to the foreground, and the second one to the background. You can add an optional <code>bold</code>.</p>
<pre class="prettyprint">[bold] [foreground] [on_background]</pre>

<h2><a name="changing_the_log_message"></a>Changing the log message</h2>

<p>If you don't like the default log format, you can change it with the <code>log_format</code> setting, which is
documented in detail in <a href="https://metacpan.org/module/Dancer2::Core::Role::Logger">Dancer2::Core::Role::Logger</a>. You can just stick it in with the other configuration.</p>
<pre class="prettyprint"># config.yml (this is the default)
engines:
  logger:
    Console::Colored:

( run in 0.989 second using v1.01-cache-2.11-cpan-39bf76dae61 )