Tag Info

Hot answers tagged

4

There is none in version 1.1 of the API: all the information in the API is public. This is status-planned for version 2, however. Read more.


4

I had a similar issue a few months ago ago, and I came up with a couple of suggestions, one exactly like how you suggested: Ask the user for the email associated with their account, MD5 it, and compare it to the value provided by the API. This works, provided it isn't essential that the user is who he says he is - a users email may be publicly available, ...


2

I've updated the documentation with a section about errors. This behavior is defined more by the OAuth 2.0 spec than by me, so it's naturally a little out of sync with the rest of the API. Authentication is also just... weird when compared to pure data queries. The answer is, it depends. In no case during implicit authentication is a 400 possible, sine ...


2

This is relatively easy - just make him give you the same email address that he provided for his Stack Exchange account and then calculate the MD5 hash of the email address. Then compare that to the email_hash member of his account data. If the two hashes match, then the user is indeed who they claim to be. If not, they either provided a different email ...


2

I found answer myself and posted in my blog post StackAlert Firefox Extension error key is not valid for passed access_token Solution in brief When you remove the application from StackExchange apps, and even after uninstalling the extension from Firefox, you will still have traces of that extension in Firefox. To make this extension work again, we have ...


2

key is your app key, access_token identifies a user (and a set of permissions) and is what you get at the end of an authentication flow. Keys are not secret, for example here's what the Documentation Console's registration looks like: You can find your app key by going to Manage Your Applications (in the Stack Apps homepage sidebar) and selecting one of ...


1

If a user has any authorized applications, the apps tab appears on their profile pages. From the page linked a user can see their authorized applications, and de-authorize any of them. That link probably won't be conditionally displayed forever, but we haven't got anything to show in the "emtpy" case just yet.


1

This isn't possible, for simplicity reasons. Right now there are a few states a user can get into w.r.t. authentication: logged in, app not authorized need to authorize app app not in app tab logged in, app authorized no prompt app in app tab not logged in, app not authorized need to login, then authorize app app not in app tab not logged in, app ...


1

You shouldn't get prompted when acquiring an access token if you've previously authorized the app and have not explicitly removed it. That is by design. I can't reproduce access tokens remaining valid after removing the app, though there is a natural race there. It's entirely possible that an access token will remain valid for a small period after ...


1

This is just how OAuth 2.0 indicates rejection, you get different values on the redirect (either in the hash for the implicit client side flow, or in proper query string parameters for the explicit server side flow). Instead of code or access_token (depending on the flow the app is using) you get error and error_description. When a user rejects you get ...



Only top voted, non community-wiki answers of a minimum length are eligible