Hot answers tagged

11

Refer to the Stack Exchange API, Authentication docs. It looks like you are trying to authenticate using either a server you do not control, or a local server that is not on the public internet. Crucial Points: Do not specify a redirect_uri to any server that you do not control. When you use something like redirect_uri=https://www.yahoo.com/, then a third ...


7

The fix for me was unchecking "Enable Client Side OAuth Flow"


7

Your value for channelUrl is nominally correct. If I set up my XAMPP server, via httpd.conf to use port 8000, then this HTML page works perfectly fine for me: <!DOCTYPE html> <html><head> <title>StackApps SDK auth test</title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head><...


7

The OAuth Domain is either: A valid domain that you own and control, and that is hosted somewhere the client can reach. Say, for example that you owned unicorns.mil. See this answer and this answer for more information on how to configure the app registration settings. (This is "Explicit" or server-side OAuth) OR: Use stackexchange.com. This is a ...


6

You got that error because you set the OAuth Domain like example.com:8080, not the redirect_uri. That's not how you configure non-standard ports; see below. The redirect uri, with port, feature now works (it didn't once upon a time). To use, adjust your app settings: Go to https://stackapps.com/apps/oauth and click on your desired app. Click the "Edit ...


6

Go to your profile: https://stackapps.com/users/current Click the "Edit Profile & Settings" tab: https://stackapps.com/users/edit/current Click "Applications" on the left sidebar (no handy universal link for this, but it'll take you to a URL like https://stackapps.com/users/apps/53175 where 53175 is your user ID) And there you'll have your list of ...


5

Yes, it can be annoying that the API docs, the javascript SDK, and the settings pages use the terms: "Explicit" "Implicit" "Server side" "Client side" a little interchangeably. (The first 2 are roughly synonymous with the last two.) From the javascript SDK docs: Your application must have the client side OAuth flow enabled, and must not have the ...


4

Your second call must be https:. You actually got an error like: "error_id":406, "error_message":"Access token sent over non-HTTPS request, it has been invalidated", "error_name":"access_token_compromised" On the first attempt. Only subsequent attempts, with the same token, would yield the 'key' is not valid for passed 'access_token' error. When I ...


4

Dealing with token expiration is pretty simple. When a token is/goes bad then, when you make an API call that uses the token, you will get a JSON response like this: { "error_id": 403, "error_message": "`key` is not valid for passed `access_token`, token not found.", "error_name": "access_denied" } At that point, just re-authenticate. You can ...


3

No, you can't get the access_token in the query/search part of the URL. This would be a security leak that would allow 3rd parties to see your access_tokens on the web. Reference: OAuth2.0 Implicit Grant flow. Why use url hash fragments? RFC 6749 If your app is running on a server, use the explicit OAuth flow. This returns a one-time code to your server -...


3

Turns out this is completely my fault :/ I overlooked the expiry aspect of the access token which meant that I got the default 86399 seconds (~24 hours), which meant my users had to get a new access token every day. Because this is a userscript which is used daily, it makes sense to have a no_expiry scope so that the user doesn't have to repeatedly ...


3

That error means either that you've misconfigured the app or that the authentication call is incorrect. Note that stackexchange.com/oauth/login_success is not a valid redirect_uri irregardless. You probably want/need to use Client side (Implicit) authentication, in which case the redirect_uri would be:           https://...


3

This was fixed in the latest deploy.


3

We moved from nginx to HAProxy for our SSL provider this weekend as part of a larger rollout. In the move, we shifted our header checks to the now de-facto standard SSL protocol header. While I thought I fixed all the apps relying on the old header and standardized everything internally, stackexchange.com was left out and thought your auth requests weren't ...


3

Yes, calls to /access-tokens/{accessTokens} use API quota. You can see that by repeatedly running /2.2/access-tokens/XBWL0stf*YIOCl7WpJHqYA)) for example. With each call, the quota_remaining value will decrease. However, there is no reason that the token check has to use the same key as your main app. The token check and your main app would then use ...


3

Of course as soon as I finally break down and ask a question I see my mistake: Applications that have the client side flow enabled can use https://stackexchange.com/oauth/login_success as their redirect_uri by default. I had "Desktop OAuth Redirect Uri" disabled which the javascript SDK uses. (Note the url posted in the question) Leaving this up here in ...


3

Yes, I always get 86399 too. And, no, you can't specify an interval other than no_expiry. But you can call /access-tokens/{accessTokens}/invalidateDoc at whatever interval you wish. So, for less user annoyance, set no_expiry but then call /invalidate every, say, 8 days, for example.


3

There have been no reported changes to the API, officially for many years, (unofficially since January). But, frankly that script's approach should have never worked. OAuth credentials are sent to:     https://stackapps.com/a/7936#access_token=y6rVASxxxxxxxxxRO2R9Bg)) (for example) But this is immediately 302 redirected to:     https://...


3

Yes, you can find out if the user has received the association bonus using the API. It's a bit clunky though. However, as we discovered, "association bonus rights" are rather meaningless at the moment. Otherwise, you'd be able to edit wikis, upvote, comment, and flag on Information Security Stack Exchange right now, despite currently only having 1 rep ...


3

If you need something for personal use, it doesn't really matter. You can even use example.com, as long as the site doesn't redirect and change the URL. You'll need a browser and a tool like curl. Insert the client ID of the application in the URL below: https://stackoverflow.com/oauth?client_id=[CLIENT ID]&scope=read_inbox,no_expiry,write_access,...


2

The authentication process is described in the API docs: http://api.stackexchange.com/docs/authentication.


2

So, this was a fun one. :) We apparently broke several different things over the course of a year that went unnoticed until Google turned off OpenID support. In no particular order but for fun and posterity: Facebook OAuth authentication just straight up didn't work. It broke back in January of 2014 when the code was accidentally changed from function ...


2

Yes, each time you invoke stackexchange.com/oauth/ you will get a fresh access token, even though old ones may still be valid. For example: Go to /me/inboxLivedoc and hit Get Token twice, recording the token value each time (It will always be different). Then go to /access-tokens/{accessTokens}Livedoc and check each token. They will both still be valid! (...


2

The question is not clear enough. You appear to be trying to use jQuery to do explicit OAuth from a web page. If so, this is not allowed. Explicit OAuth is for servers. You are not running that code in node.js are you? Anything that runs in the user's browser, like javascript, needs to use "implicit" (Client side) OAuth. Implicit OAuth was developed ...


2

For read requests, you must send the token (and key) in the URL. For example: https://api.stackexchange.com/2.2/me?site=stackoverflow&key=dp55hR5Wr9UhOJReA6F2gg((&access_token=26nor26ZCVN4y5vn94Zg(w)) For write operations (EG answers/{id}/upvote), you must use use HTTPS POST and then the key, access_token, and other parameters need to be form ...


2

This is what the /apps/{accessTokens}/de-authenticate route does. Passing valid access_tokens to this method causes the application that created them to be de-authorized by the user associated with each access_token. This will remove the application from their apps tab, and cause all other existing access_tokens to be destroyed. (Emphasis added) So if ...


2

I don't think that's a bug, for implicit OAuth. Anyway, if I understand RFC 6749 correctly, that is not how you are supposed to do such extra checks. Use the state parameter. And this works. For example, a call to:   /oauth/dialog?...&state=robfoo&redirect_uri=https://stackexchange.com/oauth/login_success (Click the link and try it.) Yields ...


2

I don't know about that Ruby/Gem, but your app registration is not correct. You need to configure your app for explicit OAuth2, per this other answer, except enter localhost instead of example.com. (The localhost is based on the original version of the question. If you have a registered domain, use that.) Then, in your ruby code: config.omniauth: ...


1

Unpack response content with $response->getBody()->getContents(). use GuzzleHttp\Client; Route::get('/approve', function () { header('Location: https://stackexchange.com/oauth?client_id=12345&scope=write_access&redirect_uri=https://mysite.com/approved'); }); Route::get('/approved', function (Request $request) { $client = new Client(); ...


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