GitLab

 - metadata is specific to web, move it there
 - create Web_serializable, and also move randomness there
 - metadata is not optional (but its components can be)
 - rename user_type into user_domain
 - serializable version of ACLs

 - store the service itself
 - move closer to site services

The signature is split into:
 - SITE_SERVICES: site-wide services, with single instances
 - ELECTION_SERVICES: per-unarchived-election services
 - VOTING_SERVICES: per-open-election services

For the moment, per-election services are still site-wide with single
instances.

Other changes:
 - the "global continuation" getter is renamed to "cont", so that its
   container module can be directly cast into CONT_SERVICE
 - move remaining service declarations out of Services
 - move service registration code close to service declarations,
   following the same Services/Register pattern as in Auth_common
 - various simplifications in Registration

There were 3 phases: configuration parsing, service definition and
service registration. The last two can be merged, since there is no
direct external reference to the service of a specific auth system. As
a consequence, there is no need for a Register sub-fonctor in
AUTH_INSTANCE: service definition and registration occur directly in
the Make function, called by instantiate.

Summary:
 - move rewrite_prefix to Web_common
 - each auth system now has an $init function that registers its
   configuration spec and an $exec function to Auth_common
 - an auth system may support multiple instances via configuration;
   user_type is specific to each instance
 - when parsing is done, each $exec is called with an $instantiate
   callback; $exec is supposed to call $instantiate for each instance

TODO:
 - default fallback when there are several instances
 - generic login should do security_log
 - auth system instances should not set user_type themselves
 - it should not be possible to login twice
 - admin login
 - update doc

We want to be able to share private variables between service
definition time and registration time, so we put both as submodules of
the Make functor.

For now, it is no longer possible to log in as an admin...

As in "continuation". This is more generic than just logging out...

Auth systems are wrapped into a module (with signature AUTH_SYSTEM) to
cope with polymorphism.

This prefix is not in the CAS spec and seems specific to some
instances. People can add "/cas" to the server path in their config if
needed.

This revision should be bisimilar to the previous one.

Summary:
 - each auth system registers $name and $service
 - $service stores a logout handler in Auth_common.user
 - the generic login service redirects to $service if its parameter
   matches $name
 - the generic logout service clears out Auth_common.user and invokes
   the stored logout handler
 - the default auth system is the one registered last
 - Templates directly query Auth_common for available auth systems

TODO:
 - enforce user_type = $name (currently not the case for CAS)
 - export Auth_common.register_auth_system
 - move existing auth systems out of Auth_common
 - integrate with config parsing
 - rework CAS
 - generic login should do security_log
 - do admin login

Currently, it takes the auth_system name as an optional parameter, and
redirects to the existing services. This revision should have the same
behaviour as the previous one, except for login links and the
associated additional redirections.

Summary:
 - Auth_common.Make is now split in two functors: one for declaring
   services (Make) and one for registering them (Register)
 - auth_systems moved to its own signature
 - login and logout are in their own signature
 - new signature ALL_SERVICES

This is preliminary work to make the authentication system more
flexible. This big refactoring should be semantically equivalent to
the previous commit.

Summary:
 - create Auth_common and Web_signatures
 - split Web_election out of Web_common (to cut dep cycle)
 - move service definitions out of Services
 - functorize Templates

It is used for ballots as well as records...

A record (i.e. who voted, when and with which credential in the
context of the web server) is a notion that does not exist in the
cryptographic protocol and does not really make sense in the context
of the command-line tool.

By the way, we add the notion of receipt which, in the context of the
web server, is the ballot hash computed by the server.

Bonus: when a ballot is accepted, we compute its hash only once.

We assume the election URL is $PREFIX/elections/$UUID/election.json,
and we use URLs relative to $PREFIX elsewhere. For compatibility with
reverse-proxies.

The CAS protocol requires passing around absolute URLs, which cannot
be computed correctly by Eliom if it is behind a reverse proxy. This
option allows one to specify how to post-process URLs computed by
Eliom to match reverse-proxy configuration.

The credential is taken from the file given to --privkey (if any).