view release on metacpan or  search on metacpan

devdata/https_mojolicious.io_blog_2017_12_05_day-5-your-apps-built-in-commands  view on Meta::CPAN

<p>You can fetch the Perl headlines from reddit.
To do so we fetch the url (following redirects with <code>-r</code>), then we give it a <a href="http://mojolicious.org/perldoc/Mojo/DOM/CSS">CSS3 selector</a>, and finally extract the text from each found element.</p>

<pre><code>mojo get -r reddit.com/r/perl &#39;p.title &gt; a.title&#39; text
</code></pre>

<p>How fun is that?!</p>

<ul>
<li>You can POST or PUT or DELETE data.</li>
<li>It handles HTTP basic authentication using <code>username:password@</code> in the URL.</li>
<li>You can submit forms, even with file uploads using the standard <code>@filename</code> syntax.</li>
<li>You can pipe data to the command if you just want to send the raw contents of a file rather than url-encode it.</li>
<li>See lots more examples in the <a href="http://mojolicious.org/perldoc/Mojolicious/Command/get#SYNOPSIS">documentation</a>.</li>
</ul>

<p>But I haven&#39;t even touched on its coolest feature yet.
This command also works on your application when you request a relative url.
This is so handy for debugging requests during rapid development; you don&#39;t even need a browser!</p>

<pre><code>perl santa.pl get /meet/rudolph &#39;p&#39; text

devdata/https_mojolicious.io_blog_2017_12_16_day-16-the-secret-life-of-sessions  view on Meta::CPAN

</code></pre>

<p>So why isn&#39;t this recommended?
Because it would mean that each time you started the server you would get a new secret.
As with the case of changing your secret intentionally above, all existing sessions would be invalidated any time you wanted to reboot a server or restart the server process.
Additionally you could only use one server, any load balancing scenario would result in different secrets on different hosts, your users would randomly invalidate their sessions depending on which server they hit!</p>

<h2>Forward Secrecy</h2>

<p>Just as you have to change application passwords from time to time, so too you need to change your secret.
In a brute force scenario, a nefarious user could take one of their cookies and try to reverse engineer the secret that was used to generate it.</p>

<p>But wait!
You just said that changing the secret to prevent brute forcing will invalidate all of our sessions!</p>

<p>Remember when I pointed out that rather than being a single value, <code>secrets</code> was an array reference?
Well when Mojolicious generates a session cookie, it does so using the first value in the array reference.
However, when it validates session signatures, it will check them against each secret in the array.</p>

<p>So, say the time has come to rotate our secrets so we generate another</p>