Auth isolation

Summary
-------------
Lower the coupling between the main application and authentication, account, and session management. In particular, decouple the identity service from any particular session implementation used by either an identity provider or consumer.

Motivation
--------------
In order to be able to adapt to different authentication environments it needs to be possible to easily override the dialogs we show during identity authorization and account management. For our identity module to be generically useful, it should define a provider interface where we can configure it for different environments. For instance, the identity service can have a differently configured provider depending on whether our application is doubling as an authentication client or if authentication, and potentially session management, are handled by a separate application.

Goals
--------
- [x] Don't reference account or auth directly in app.pt
  - [x] Share a single dialog sheet
  - [x] Get rid of the show-account directive
  - [x] Make it possible to override both dialogs together
- [x] Make account and auth part of the same optional bundle
- [x] Separate the identity service from the session service
The one not marked has never been in a release, which is why the bw compat
is still needed for another cycle.

I could also simply rename it in the front end if that's preferable.
On Sep 30, 2014 1:28 AM, "Nick Stenning" <notifications@github.com> wrote:

> In h/auth/local/views.py:
>
> >      session = {k: v for k, v in request.session.items() if k[0] != '_'}
> > -    session['csrf_token'] = request.session.get_csrf_token()  # bw compat
> > -    session['csrf'] = request.session.get_csrf_token()
> > -    if request.cookies.get('XSRF-TOKEN') != session['csrf']:
> > -        request.response.set_cookie('XSRF-TOKEN', session['csrf'])
> > +    session['csrf_token'] = csrf_token  # bw compat
> > +    session['certificate'] = csrf_token
>
> Notably, session['csrf_token'] remains for backwards compatibility, but
> you've just changed the name of the session key from csrf to certificate
> without similarly keeping csrf around for backwards compatibility.
>
> Either we should nuke csrf_token as well (my preference, absent other
> context), or csrf should also be kept for backwards compatibility.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/hypothesis/h/pull/1539/files#r18204533>.
>