Admin panel refactoring: Electric Boogaloo

[ddavness]

This is a deeper refactor on the admin panel. The main goals of this PR are:

• Get rid of dead code;
• Modernize all the code so that it conforms to some styling guide;
• Make code more readable and uniform (i.e. for same thing, use the same libraries);
• Improve the security and privacy of the panel;

There won't be many changes (if any) to the aesthetics of the panel on this PR.

[ddavness]

Code Guide in a nutshell for the management daemon

• Identation done via tabs (hard tabs)
• For the backend (Python):
• • Follow PEP8 (except the identation part)
• • Revert to using a cookie as an authentication ticket (so that we don't need to handle authentication on our own code);
• • Review the API interface - try to make it as consistent as possible;
• For the frontend (HTML):
• • Keep everything reasonably idented;
• • let over var. Always.
• • No inline HTML in jQuery (e.g. no something.html("<p>Some html</p>")). Use templates instead;
• • .text() over .html() and you're not risking a XSS vulnerability;
• • Try using and abusing jQuery as much as possible (instead of the much more verbose document.getElementById() blah blah blah;
• • Id's must be unique. Use classes when you're creating templates;
• • Don't perform cross requests to other sites (client-side);

[ddavness]

The current authentication model of the admin panel can be done in three ways:

• Session token sent via the Authentication header (this token is visible to JavaScript);
• Username + PW combo (used for external API requests like dynamic DNS);
• Specifically for Munin, authentication is done by issuing a short-lived cookie;

I'll be looking to overhaul this to make stuff more consistent (and likely more secure too):

• Username + PW (+ 2FA when applicable) will now be only used for tokens to be issued (i.e. login only);
• All tokens will take the shape of cookies (with the respective CSFR mitigations, of course);
• In the future: Folks will be able to generate API keys specifically for external use;

[ddavness]

The new authentication model and flow seem to be working nicely so far :)

[ddavness]

Right now I'd be surprised if things work at this state :upside_down_face:

[ddavness]

Oh hey, it's working surprisingly well so far! I'm suspicious now

[ddavness]

Further looks at the code tell me that we probably can do some optimizations on the API we're exposing - however this will create breaking changes as certain API endpoints will be removed. Some immediate examples include:

• POST /mail/users/quota
• POST /mail/users/password
• POST /mail/users/privileges/add
• POST /mail/users/privileges/remove
• • --> PATCH /mail/users/;
• POST /mail/aliases/add
• • --> POST /mail/aliases;
• POST /mail/aliases/remove
• • --> DELETE /mail/aliases;

There might be something for the DNS endpoints, too. Bottom line - Both due to this refactor and due to the refactor on the authentication system, software interfacing with the Mail-in-a-Box admin API WILL break with this version of Power Mail-in-a-Box;

[ddavness]

There won't be many changes (if any) to the aesthetics of the panel on this PR.

Ok, I might have lied a bit when I said that. There will be some changes to the layout to make the user experience more consistent. But nothing too much out of the ordinary.

[ddavness]

One of the things also being worked on is a much more extensive form validation process. Forms will be validated client-side before any data is sent to the server (the data will of course be checked again server-side).

If any issues pop-up during validation, they'll be presented to the user like this:

The server should also provide it's own information in case server-side checks do fail.

[ddavness]

That's aliases done. On to (checks notes) DNS!