view release on metacpan or  search on metacpan

devdata/https_mojolicious.io_blog_2017_12_10_day-10-give-the-customer-what-they-want  view on Meta::CPAN

Perhaps the dot character is needed to indicate other things or perhaps it just looks weird for some requests.
In that case there is yet another mechanism.
For requests bearing a <code>format</code> query parameter, that value will be used.
A request to &#39;GET <code>/santa?format=json</code> will result in the same stash values as the previous example.</p>

<h3>How It Works</h3>

<p>By now you probably suspect, correctly, that the <code>format</code> stash value is the driver of Content Negotiation.
Other methods, which you will see later, will check that value in order to determine what should be rendered.</p>

<p>With that knowledge therefore this way you might guess, correctly, that if you&#39;d like to force a route to have a certain default format you can just put it into the route default stash values</p>

<pre><code>get &#39;/:name&#39; =&gt; {format =&gt; &#39;json&#39;} ...
</code></pre>

<p>In Mojolicious the overall <a href="http://mojolicious.org/perldoc/Mojolicious/Renderer#default_format">default format</a> is html, but of course can be changed.</p>

<pre><code>app-&gt;renderer-&gt;default_format(&#39;json&#39;);
</code></pre>

<p>There are also mechanisms to limit the format detection, but those are beyond the scope of this article.

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

<p>This happens because you are using the default secret for the application.
This default is just the name of the script, as you can see via the <a href="/blog/2017/12/05/day-5-your-apps-built-in-commands">eval command</a></p>

<pre><code>$ perl myapp.pl eval -V &#39;app-&gt;secrets&#39;
[
  &quot;myapp&quot;
]
</code></pre>

<p>This secret is not secure both because it is short and because it is easy to guess.
With a trivial application like this you might not need to worry about forgery, as you would with say a session that tracks user logins.
But who knows, perhaps you are going to award a prize to the user for the most requests made!
Let&#39;s play it safe.</p>

<p>The secret isn&#39;t something you need to remember, it just has to be hard to guess.
So I suggest you pick a random one.
You could generate 12 characters of random text using</p>

<pre><code>$ &lt;/dev/urandom base64 | head -c 12
yuIB7m88wS07
</code></pre>

<p>Once you have that you have to tell the app to use it.
Create a file called <code>myapp.conf</code> and set it up like so</p>

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

};

app->start;

</code></pre>

<p>If it finds a <code>secrets</code> parameter in your configuration, it will set it as the <code>secrets</code> on your application.
Since you have one in your new configuration file, it should set that property and the warning should go away.
Congratulations, you have a safer application already!</p>

<p>If sometime later, you suspect that someone has guessed your secret, or if your secret leaks out, you can change that secret and restart your application.
This will protect your application from malicious users.</p>

<p>For your clients, this will have the jarring effect that all existing sessions will be invalidated.
In the example application the counter would be reset.
If instead the session were being used to keep users logged in, they would suddenly be logged out.
If it was for tracking a shopping cart ... no more shopping cart.</p>

<p>This can actually be useful even if your secret is safe but you want to force-invalidate sessions for some other reason, like say your application was generating corrupt data or worse.
Generally, however, this is something you&#39;d like to avoid.</p>