gae-init/gae-init-auth — pull request #46 by mdxs (2014-09-17 09:29:47+00:00)
Title: Fixed authentication using StackOverflow

Fixed authentication using StackOverflow as reported in https://github.com/gae-init/gae-init-auth/issues/34 - also updated to v2.2 of the StackExchange API, see http://api.stackexchange.com/ for details.

Note however that there is some weirdness in how the end-user clicking on "our" StackOverflow (SO) button is shown a StackExchange (SE) page to authenticate and approve *"To know what your accounts are on the Stack Exchange network"* permissions. In my opinion that is confusing enough... *"didn't I click on StackOverflow?"* is what I thought first myself. On the http://api.stackexchange.com/docs/authentication page I couldn't find a way to have SE show some SO flavour to the end-user.

So, I considered renaming everything SO to SE and hope that end-users know that they want SE if they mostly (only?) use SO... but then the API bites: you need to provide the `site` to get the `/me` details of the user authenticated.

Digging further showed that you can call `/me/associated` (see https://api.stackexchange.com/docs/me-associated-users) and get a list of user-account-per-site for the SE end-user, which however lacks the `display_name` detail (note: can be different per site; see http://stackapps.com/q/3400/28533 for someone else bothered with this...). It does have an `account_id` though (next to a `user_id` per site). That `account_id` seems to be stable across SE sites (see http://stackapps.com/q/4303/28533), so it would be a candidate for a `stackexchange_ACCOUNT_ID` auth id to go into our `gae-init-auth` stored users (versus the `stackoverflow_USER_ID` one used now).

However, then another problem pops-up: so the user wants to login/sign-in to `gae-init-auth` via SE, fine they see the SE web page and do their magic, then we need to figure out dynamically which of the accounts (if there are more) to use. However, unless showing something to the user (and breaking our normal flow), best we could do is pick the account with highest reputation (as suggested at http://stackapps.com/a/3449/28533) or some other way of deciding... we could for example use a list of preferred `site`s (but... and now it gets crazy: the list from `/me/associated` also lacks the `api_site_parameter` which AFAIK would be the input to `site` when calling upon the `/me` end-point to get the `display_name`... now the determined developer could use `/sites` and deal with multiple pages as the list is freaking long, somehow store stuff and associate (via strings I'm afraid as there doesn't seem to be a site key...) and deal with changes.

Ouch... let's KISS and just fix our StackOverflow as-is, leaving the SE stuff in the middle for end-users to deal with (read: they need to understand that clicking on `Sign in with SO` will show them a SE authentication page). Thus this PR ;-)