The dumb code festival - 4

Authentication and authorization is something every framework must manage. Because they're boring and frameworks exist to manage boring things.
When a user can be considered authenticated? The easiest way to check it it searching is its session for a user key with some interesting value. Is this secure? Enough, because we're talking about server-side session, something a user can't touch, we have to trust it well... until a new security flaw is found in one of the layer of our system.

The "auth" thing is a pattern well known in the web world and you can find many solutions for it, looking for "Dancer::Plugin::Auth" you'll find a lot of stuff. Unfortunately Dancer2 is still a young project so the only tool we have is the Dancer2::Plugin::Auth::Tiny from Golden.
We'll not use it. Ok, the plugin is a very good piece of software but its main purpose is define which routes need login to redirect on login page the not authenticated users. I think that this is made useless by the Dancer2 App scope.
In a situation where routes for logged users and routes for not-logged users are mixed up probably D2::P::A::Tiny is the right solution, but here we have an app where every route needs auth so we'll solve our problem just with a before hook defined in the app itself.

But we have to start from: how to open the doors to a logged user? Login went well, user and password were right, what the server will do? As I said before, it will write in the user session the username.

session 'user' => $the_username;

This is what our hook will check:


Yes, just this. The most common mistake is forgetting that the login route has to skip the check because is the only page allowed for not logged users. In every other case the hook does NOTHING for logged users and redirect to the login page the guests.

I made it more longer than what is needed because I like to talk and write and because sometimes I think that also obvious things need some explanation, somewhere. Conclusion is that using the snippets from the dump code festival you have the start situation for an admin tool you can use for every purpose. Probably, working on it, you'll find a lot o things to improve it or make it smarter. But this is just the first step, the dump step, so it's right as it is.

The dumb code festival - 2

Let us spend some more words about forms and HTML::FormFu. In the preview chapter we just scratched the surface of it, doing something too essential to be enough, even in a dumb code festival.

Form is a way to have a structured stream of input coming from a human being to a machine. Human beings are bad doing data input. They insert bad data, they're lazy, they use funny mysterious languages like english and they're often stupid. You can't trust them, you have to constraint them, filter their input, inflate it and validate. (you would also bring them all and in the darkness bind them but this is not a tutorial suited for that).

Keeping us near the little example we're working on, a login, box, what kind of bad input we should manage? Luckly, very little, the only bad thing a user could try is to submit the form with no data inside. We could ignore this case, obviously it will led to a bad login, but let us make HTML::FormFu manage it for us.

Very little code added, just a contraints field with an element. The element is defined by a type and a message to me thrown up when constraint is violeted.

An interesting thing about: where that "Requeired" word come from? How can I know which words can do this kind of magic? Is there a sort of grimorioum for them?
Obviously not, the keyword you put in the type is just the name of a perl package, in the HTML::FormFu::Constraint namespace. The one invoked here is this.
What does this mean? It means that you can look at the available constraints just surfing the CPAN for contrainst classes and that you can use constraints created by your own just giving them the HTML::FormFu::Constraint namespace and putting them in the configuration file as "official" ones.
And yes, filters, inflaters and validators follow the same logic!

Just updating the form configuration you have managed the empty fields case. HTML::FormFu will reject the submission and will display errors on screen if the user try to submit without writing anything (lazy, lazy human!).

Now two important downsides:

1. Validation is server-side. The form is submitted, POST data elaborated, page reloaded with errors. If you're aiming to a validation with no page refresh and client-side javascript magic you're looking in the wrong place.
2. HTML produced by FormFu is the HTML it likes. You could not like it. You could think is a little old-style, too rude and simple. For example, I hate it doesn't use the Label for attribute.
   You can decide to work "around it" knowing how it is and putting javascript and CSS to make it looks good. The harder way is going down in the HTML::FormFu classes and redefine the rendering. This thing is not enough dumb for this article.

But... probably after so many words you want to see your form, don't you?

Open your Dancer App and render it!

The any key to acquire GET and POST will come useful in the future. Remember that the login.yml will be searched in you app root, the same directory where the Dancer config.yml is placed. Subdirectories are allowed (and recommended).
Remember to have in your template a [% form %] token where the box will be displayed.

This piece of code is very stupid, nearly useless, because there's no logic. But it's just the second part and we have a lot of things to talk about.

The dumb code festival - 1

One thing I usually miss when I google things about Dancer2 (or other coding stuff) is examples of simple working code doing normal things. Every time you find just little snippets that do just a thing in a way that will be useless to you ore code doing wonderful, exciting things you don't need.
For Dancer2 we have this article from Sukrieh himself that is very useful to learn how Dancer2 works, but... just this.

I want to put in this blog all the things I don't find in internet so I decided to start some articles about an obvious, stupid thing you all do blind and tied up while singing Yellow Submarine. Just because I think that out there there's someone who's not singing loud enough.

Let's talk about a little adminitration panel for your website. I'm not interestend in what your website do, there're a lot of things an administration panel has to do anyway. The most important thing is that it has to keep out all the non-authorized people and let the authorized in.

Authorized people will enter somewhere username and password. There're a lot of ways to do this (and some plugin from Dancer that could be easly migrated to Dancer2) but we'll to it from scratch in the most obvious way: a login page.

A login page is just a form with you fields, a big red button and a lot of threatening messages when you do wrong things.

Talking about forms, perl and frameworks, you should learn about HTML::FormFu, one of the most used libraries for forms in perl.
Using it, you'll translate all the logic you want in the form in a configuration file, adding to it, eventually, some libraries for validation, filtering and so on, downloaded from CPAN or written by you.
You could think this is too much complex and without real gain for your coding, especially when you are dealing with little forms.
My advice is to always follow this design path for two important reasons:

1. If you don't use it with simple problems, you'll NEVER use it in complex one. Don't lie.
2. In every case templating the form is keep separated from coding is logic, something you must do if you want to write tidy code.

A login box using HTML::FormFu at his minimum potential has a config file (login.yml) like this:

You can make it a little more beautiful, but all the logic you need is here.

For this time we'll stop here, i wrote the introduction to this experiment, so the article is already long enough. Numbers near the title means that we'll go on. I hope that I'll create something useful with this, useful for the internet and also for me, to make my mind a little more clear about what I do.