Api: WebAuthRequired error?

[HittmanA]

I'm trying to access a protected resource (/User/GetMembershipsForCurrentUser/) with OAuth and I keep getting:
{"ErrorCode":99,"ThrottleSeconds":0,"ErrorStatus":"WebAuthRequired","Message":"Please sign-in to continue.","MessageData":{}}
I am sending

var headers = {
        'User-Agent':       'Super Agent/0.0.1',
        'Authorization': 'Bearer' + token,
        'X-API-Key': 'myKey'
    }

as my headers and I am sure the token is a valid token. Why do I keep getting WebAuthRequired?

[HittmanA]

I have confirmed I am going to https://www.bungie.net/Platform/User/GetMembershipsForCurrentUser/ and not https://bungie.net/Platform/User/GetMembershipsForCurrentUser/ so why the WebAuthRequired?

[HittmanA]

If I look at the request this is being sent:

"headers": {
    "User-Agent": "Super Agent/0.0.1",
    "Authorization": "BearerTOKEN",
    "X-API-Key": "KEY"
}

[vthornheart-bng]

Ah, shoot - I don't see a way to message people privately here, d'oh. Just as a heads up, you edited that most recent post but an email still got sent to people watching that had your info. :( You'll want to de-auth your API key and grab a new one, and if that auth token was yours, log out and back into the app so no one uses your auth credentials.

[HittmanA]

Very sorry about that. I disabled and deleted the api key and logged out. Still, how do I fix this problem though?

[vthornheart-bng]

No worries! I've done that myself before, it's unfortunately easy to do... and with these email notifications, it makes it a pain-in-the-butt mistake. Glad that key wasn't too painful to remove.

Ah, let me get some clarification just to make sure I'm able to assist - which URL was it you were hitting? Can you give the specific one - it looks like you said https://bungie.net/Platform/User/GetMembershipsForCurrentUser/ twice (that you were hitting that URL and not that URL, and that one does indeed require auth because that's how we know who the current user is.

Were you trying to hit Platform/User/GetMembershipsById/{membershipId}/{membershipType}/ ? That one should not require auth... let me know what URL you're hitting if you're running into that, and if you can provide the full URL of an example that's failing (no need to pass credentials, just the URL with membership ID + Type of an example that's failing)

[HittmanA]

I am hitting https://www.bungie.net/Platform/User/GetMembershipsForCurrentUser/ to get the users membership. I have added a header that has my api key and auth token but it is saying webauth is required.

[vthornheart-bng]

Ohhh, I see - I misunderstood, got caught up in worrying about the exposed credentials! My bad!

Ah, I think I see what's up - so you'll want to take any cookies that have been sent to you by our server during the authentication process and pass those up. They include the credentials that we use for user authentication - in particular, all the ones prefixed with "bungle", but ideally anything that was sent your way in the set-cookie headers of the response.

(For future readers - ignore this, I was thinking about the auth mechanism we use on BNet itself and not oauth)

[vthornheart-bng]

(note that, after the initial login process where you receive these cookies, you'll want to not continue sending the Authorization header: that's just for the initial login process)

(again, me thinking about entirely the wrong auth process)

[HittmanA]

Ok, I'm using NodeJS and am unsure how to do that. How do I grab the cookies and then send them to pages that require auth?

[vthornheart-bng]

Ooh, unfortunately that I don't know about! I'm ashamed to admit I've not actually used NodeJS, so I don't know about how its libraries work in particular. Perhaps someone in the community who does use NodeJS could chime in? I'll ask around and see if anyone can provide assist.

[HittmanA]

Ok, thanks!

[HittmanA]

Side note: when I look in the response from the server (on the failure) I see this:

"set-cookie": ["__cfduid=de9f2f272bcb9c64cceb62286e01b14bf1508955854; expires=Thu, 25-Oct-18 18:24:14 GMT; path=/; domain=.bungie.net; HttpOnly", "bungled=102434843366385104; expires=Sun, 25-Oct-2020 18:24:15 GMT; path=/", "bungledid=ByaVO99Xr29GuXPofKCDlmnNKXKZ1RvVCAAA; expires=Mon, 25-Oct-2027 18:24:15 GMT; path=/; HttpOnly", "sto-id-sg_live.bungie.net=EIAKHPAK; Expires=Wed, 25-Oct-2017 19:24:15 GMT; Path=/"],

are these the correct cookies or do I still need to pass the cookies in?

[joshhunt]

I spotted a minor error in your headers - there should be a space between "Bearer" and your token. The header that's sent should look like Authorization: Bearer abc123

With the missing space the token would be invalid and you wouldnt be able to return the details for the user the token is for 😃

[dad2cl3]

@HittmanA how recently did you obtain your token?

[vthornheart-bng]

Oh, you know what - discard my message about cookies, I was thinking about how our site does it! Ignore all of that that I said before.

[HittmanA]

Within minutes. I have refreshed it several times, but same result every time @dad2cl3

[HittmanA]

Ok @vthornheart-bng

[dad2cl3]

Another basic question so bare with me. What scope did you request for your API key?

[HittmanA]

All

[HittmanA]

@joshhunt
I tried that but when I do that I get:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
<title>401 - Unauthorized: Access is denied due to invalid credentials.</title>
<style type="text/css">
<!--
body{margin:0;font-size:.7em;font-family:Verdana, Arial, Helvetica, sans-serif;background:#EEEEEE;}
fieldset{padding:0 15px 10px 15px;} 
h1{font-size:2.4em;margin:0;color:#FFF;}
h2{font-size:1.7em;margin:0;color:#CC0000;} 
h3{font-size:1.2em;margin:10px 0 0 0;color:#000000;} 
#header{width:96%;margin:0 0 0 0;padding:6px 2% 6px 2%;font-family:"trebuchet MS", Verdana, sans-serif;color:#FFF;
background-color:#555555;}
#content{margin:0 0 0 2%;position:relative;}
.content-container{background:#FFF;width:96%;margin-top:8px;padding:10px;position:relative;}
-->
</style>
</head>
<body>
<div id="header"><h1>Server Error</h1></div>
<div id="content">
 <div class="content-container"><fieldset>
  <h2>401 - Unauthorized: Access is denied due to invalid credentials.</h2>
  <h3>You do not have permission to view this directory or page using the credentials that you supplied.</h3>
 </fieldset></div>
</div>
</body>
</html>

[joshhunt]

So the HTML 401 - Unauthorized: Access is denied due to invalid credentials is the error you would get from passing an invalid an Authorization header in the correct format, but with an invalid token. It's my guess that you're using the wrong token?

I would take a look at this page which can be helpful in getting the auth flow down correctly https://lowlidev.com.au/destiny/authentication-2

For what it's worth, this is working code that, when provided with a correct accessToken value will return properly

const axios = require('axios');

// access token from GetOAuthAccessToken
const accessToken = 'abc-123';

const headers = {
    Authorization: 'Bearer ' + accessToken,
    'X-API-Key': 'api-key'
};

const url = 'https://www.bungie.net/Platform/User/GetMembershipsForCurrentUser/';

axios
    .get(url, { headers })
    .then(resp => {
        console.log(resp.data);
    })
    .catch(err => {
        console.log('error:', err.response.data);
    });

[floatingatoll]

Thorn, it would be invaluable if the auth header validation error could distinguish “Auth header is not structured correctly” from “Provided key is not valid”.

On Oct 25, 2017, at 11:43, Josh Hunt [e-mail] wrote:

I spotted a minor error in your headers - there should be a space between "Bearer" and your token. The header that's sent should look like Authorization : Bearer abc123

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[SunburnedGoose]

My thought is he's using the Authorization Code instead of the Access Token for the Bearer.

[HittmanA]

No I am not. I logged both and what I send in the Authorization header is much longer and different than the auth code.

[HittmanA]

Hmmm, I revoked my apps access, refreshed everything, got a new token, and tried again. Now it works for some reason.

[HittmanA]

How long do tokens last @vthornheart-bng ?

[Tetron-bng]

The response that returns the access token tells you how long it will last. You should note that and be prepared to get a new token when the one you are working with expires. The access tokens are currently issued for one hour.

[HittmanA]

Ok, so I need to use confidential and use the refresh token to update it, right?

[Tetron-bng]

You can use confidential if your client qualifies as confidential. In that case you get a refresh token that is good for 90 days and can be used without the user's web browser being present to get a new access token. If you use 'public' then you can redirect the user to the auth path, get a new code, and get a new access token that way.

[vthornheart-bng]

@floatingatoll Aye, I agree with that - let's spin that off into a separate issue for tracking and link it to this!

[SunburnedGoose]

60m I believe.

[HittmanA]

For my application it would be extremely difficult, not to mention extremely annoying, for users to have to log in continually (even every 90 days). What should I do?

[maciek134]

@HittmanA it's not a new log in, if they don't revoke your app's access there will be just a small redirect chain when you request a new token when the old one expires.

[HittmanA]

Hmmm. Not sure if that would work with my application @maciek134. I'm using an Amazon Lambda function.

[maciek134]

Ok, but to get any token you have to redirect the end user to the bungie auth page, right? Do the same when the token expires. The user won't see a new authorization screen, but instead will be immediately redirected to your auth callback endpoint.

[HittmanA]

Well, the application is an Alexa skill. So users only go to the Bungie auth page once during the account linking. After that, I suppose I could just send a card to the Alexa app with a link on it to refresh the token when it expires.

[joshhunt]

I would imagine an Alexa skill would qualify as the the confidential skill, since you're doing everything server side.

[HittmanA]

Yeah problably

[elviswolcott]

If you’re having any issues let me know. I have successfully gotten account linking working on Alexa with Bungie.
You shouldn’t have to managed anything on your side, just use Alexa’s built in account linking. If you need any help let me know 👍

[HittmanA]

Hey, @elviswolcott do you have discord? If so let me know your id and I'll add you.

[Tetron-bng]

@joshhunt Alexa does qualify as confidential.

[elviswolcott]

@HittmanA i'm so sorry, i didn't check my notifications and just realized you replied. I'm Elvis Wolcott#6985