WIP : New portal API to partially replace SSOwat

[alexAubin]

The problem

• SSOwat should be partially reworked to get rid of some lua madness (c.f. cookie management / authentication, ldap interfacing, ..) and allow for more flexibility regarding the portal front end, etc.
• Projects regarding password reset and user self-registration imply new authentication method, and ideally these operations should not rely on an API running as root

Solution / specs

• Create a new "user" or "portal API" meant to replace some routes of SSOwat such as login/logout, updating user info, etc.
• The API is also meant to handle password reset and user registration
• It' meant to run as an unprivileged user ... though because we need to update user's password or create brand new users, some sort of mecanism shall be designed to interface with a privileged program to order the password reset or user creation.
• Ideally SSOwat should be able to validate the authenticity of the new cookie even though it's delivered from a different process

PR Status

Very much work in progress

How to test

So far:

# Start the portal API as a non-root user (e.g. www-data, ideally we should create a yunohost-portal user probably)
su www-data -c "yunohost-portal-api --debug --host 0.0.0.0" -s /bin/bash

# (you may have to manually create the log file for now, or tweaks its permissions)

# In another shell, attempt to log in
# (cookiejar didn't seem to be working for some reason,
# so I manually grepped the Set-Cookie header)
curl -H "X-Requested-With: whatever" -F credentials=camille:SuperPassword 11.22.33.44:6788/login -v 2>&1 | grep Cookie

# And now try to hit one of the new routes:
curl -b 'session.yunohost.portal="theSuperLongCookieThingy"; HttpOnly; Secure' 11.22.33.44:6788/me

# .... aaaaand it's miserably failing because it can't write the lock#
# because it's not root :P (we probably don't want a lock for this API ... or at least not for GET operations ...)
# Gotta tweak the moulinette ... but at least the authentication works ;)