The Issue

  • Currently, tracking yourself in an application is not that user friendly, you have to search for your username.
  • Usernames are not unique, there are many Jonathan's for example
  • When an application doesn't show the user's avatar it's impossible to choose between them
  • Applications designed for mobile or other devices which it is probable that there is low connection speed, so if an application does show avatars it takes a while to download all of them
  • An alternative is for the user to just enter their id for a particular site, but this is not streamlined and as simple as logging in.


  1. Ask the user which site they have an account on.
  2. Show an integrated web panel/browser giving them the login page of the site they selected.
  3. Optionally edit the login page using JavaScript to make it fit the application better (eg. size of the apps window)
  4. After the user has logged in parse the resulting HTML to get the user's id from the link at the top of the page.
  5. Get the user's Association ID from the "local" (ie. not StackAuth) API
  6. With the user's association ID get all the account they are linked to from StackAuth.

Downsides to this are:

  1. Not exactly official, will the user doubt putting their Open ID in
  2. User never gets asked to click "Allow this app to use my Open ID"
  3. Not simple as one login place, requires downloading HTML twice for a Stack Exchange site, using the site's API once, and then using the StackAuth. 4 "hits" when they could just be 2 basic ones.
  • We're expecting this in v2.0 of the API. Sep 4, 2010 at 8:28
  • 3
    So I'll come back in a few years then ;)
    – Jonathan.
    Sep 4, 2010 at 9:55

1 Answer 1


Jonathan, your request will most certainly be denied.

One thing that I have found useful in general is, when considering asking if something can be integrated, to try and present possible implementation ideas. This serves a few purposes:

  • brings you closer to the issue, close enough in some cases to see an existing solution
  • shows that you have actually put some thought and effort into the feature request
  • sometimes will expose impractical or illogical requests before they see light. ;-)
  • 1
    Is that any better?
    – Jonathan.
    Sep 5, 2010 at 7:30
  • @jonathan. much. but what you are asking for, with the current api, not really possible. SO uses open id and what you are describing does not fit into that paradigm. Users never give SO a password. They give it to the open id provider. The workflow is not one that lends itself to coopting. How they plan to handle this in 2.0 is anyone's guess but it will almost certainly require a lot of plumbing. And hijacking a Stackoverflow site is not likely to give you the results you want because, as I said, there is a multi-site workflow involved. But hey, if you have an idea, give it a shot! Sep 5, 2010 at 7:53
  • Sorry when i said password above I meant OpenID, Surely a webpage can created with a the simple login buttons (etc) of stacksite (which can then be styled/moved by javascript etc), and it just returns what the stackAuth/users/{id}/association does.
    – Jonathan.
    Sep 5, 2010 at 8:19
  • @jonathan - if you become familiar with the openid workflow, which I am barely, you will see that it is not as simple as that. The first issue I see is how do you get your javascript injected into a 'common logon' page, if there were one. Another is the non deterministic nature of user accounts. Not every account has an association. Some people have used different openid providers for different sites. some people have never even authenticated with openid and are existing by virtue of cookies. And those are the obvious issues. Ultimately the best experience for you and your users is a strategy Sep 5, 2010 at 17:59
  • as described elsewhere. e.g. accept a username and optionally a site, retrieve matching results and display them to the user for interactive selection. Sep 5, 2010 at 18:03
  • You mean people don't have to login, but surely that means they can only log in from the computer where they created the account? And isn't that ver fragile? With objective-c on iOS it is easy to run javascript on a UIwebView, I've just done and "created" a login page which is the right size. Sure I guess there will be some people with different open ids on different sites, but the majority will use one surely as that's why openID exists
    – Jonathan.
    Sep 5, 2010 at 18:27
  • @jon - for those who have not added an OpenId, yes, the account will be specific to not only the machine but a single browser and it is quite a common case. In this case 'fragile' is not really accurate, IMO. I think SO made a wise design decision there by reducing the friction in garnering new users. This is the first time you have mentioned a specific platform implementation and if your app is in a compiled language with tight control of a web viewport, sure, just provide a list of links to SO sites, let the user pick one and log in after you have manipulated the html via JS. maybe ;-) Sep 5, 2010 at 18:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .