Onedrive-api-docs: Incorrect access_token for v7.2 SDK

Created on 18 Jul 2018  路  21Comments  路  Source: OneDrive/onedrive-api-docs

Hi,
We are integrating v7.2 Javascript file picker SDK into our app. However, when opening the file picker, the outh call made to get the access_token is returning a non-LWT format access token which contains equals (=) sign in it. Because of this, the file picker doesn't open up at all. Can you please let me know why the callback URL is returning an additional equals. Here is the oauth call I am seeing being made from the SDK

https://login.live.com/oauth20_authorize.srf?client_id=3cdcad16-b7d9-4776-bd10-478950d7e9c5&scope=profile openid https://graph.microsoft.com/User.Read https://graph.microsoft.com/Files.ReadWrite.All&redirect_uri=http://localhost:9080/community/home&response_type=token id_token&state=http://localhost:9080_80gyX&response_mode=fragment&nonce=BT2Qm&uaid=40c512b7234e43118f22ec1051b57c4c&msproxy=1&issuer=mso&tenant=common&ui_locales=en-US&swu=1&contextid=08CEFB9494633747&mkt=EN-US&lc=1033&bk=1531866668

Callback URL with access_token is http://localhost:9080/community/home#access_token=EwCAA8l6BAAURSN/FHlDW5xN74t6GzbtsBBeBUYAASva5GioVokg22TeMF7F+eS+nzug/zW5d/31WQU7+FUKNev65MuEU2bd++cWnySiz2SxELV1H1azqTkLkWta7I2DMkL8l6Mf65gDIBcAiMFBBf9XYbfjE1G6tFflQaDrkczCHHNfXu5yk6kpr7UVgxXZrw3VL9ETC+6+T/H2ab5rEqPeICZC0VGPMpuAr8qosWkrrjrPVJT8kjcEoZnkhR1++SlcbI6F26snUFI7KIwdRcdC+1A1Bm7bAISuvtCHnu9A+qlsctCzF9iYfjcQgl/Ygsg+DMipxcDw44djOFxmwwfeJFtfh5LLkETq+lqYPzp5hzD5AT+jdJWEJKv+6J4DZgAACKM7LAdKmu8CUAJotT2ePXCJVLdxMcuZkxfnG6NbYwjD+7Aqqs4rgP9Lxqr5RBIFl2J1s2y8dbw7jybPhlSH6KxTvlGO608VDyOq01VgHiHyob0Iass2rhA8CJG0mHVAkJWHU/J/+PS53cd4taQcLVQ7HXACmvtfcT4QfxQNCUP9cGUsS7ZxiySHp1KlqEp6cDJPh9Y2k6OTomGpDTYrbB8lEZYuDkNNirdjyg2nacKSUat/h7Im83uyvJbttLRMpoWIQB4mH6E/T+wgJg8VouXn/ELAWFkS35p3IbOKCrZwPiEFPdHeKwOSQYtrCvH8Vuq3FzIFyxIYorfpYF4KEulhNscj9zZjNL45wmnG5Km7eeT4tuI0uCR9X+1RwXsJTz+Phu/3iPUxvzu5MXOLdGARL9nv0yTxZPNlcZwz6vlEzFe01UgtEZoLYRREncAiZ+ExcUMU9su8chXoGbzc5Xt7HszlG3T5kHj5A4Zfxa8qHW8Njc8Ygi+PLYLb5F/+PUIyZJStCt2eiRihQITI+dz3cs3O5pD0Py8dGMn4HpMwb9c1oTLmZGrrJNnh2vTR70fa5117oIl3Cmr8BB6xfcqLeIgVJFlD4XOd0+XgnHuKAnBwDOBGW5Za3ahKqh/BT/dKuUwrcdnKc/Oh+Ea+VUCi/PzBqWuNUqrezb0CqDQOHmLOsyzl46DNTppKYXjJ7v2TrkPbsqC6aIA9NeVbGPUnVdvAHy5xie2X/G3Hu/seggTNB/koertOVXeEWPKywf8wzxq3RsuzX575KSIQDDEXVWtqNDrhEkcPkAI=&token_type=bearer&expires_in=3600&scope=profile openid https://graph.microsoft.com/User.Read https://graph.microsoft.com/Files.ReadWrite.All https://graph.microsoft.com/Files.Read.All https://graph.microsoft.com/Files.ReadWrite&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjFMVE16YWtpaGlSbGFfOHoyQkVKVlhlV01xbyJ9.eyJ2ZXIiOiIyLjAiLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vOTE4ODA0MGQtNmM2Ny00YzViLWIxMTItMzZhMzA0YjY2ZGFkL3YyLjAiLCJzdWIiOiJBQUFBQUFBQUFBQUFBQUFBQUFBQUFPNUhVRVp2bFBuUGhBLXVpTkdUamNBIiwiYXVkIjoiM2NkY2FkMTYtYjdkOS00Nzc2LWJkMTAtNDc4OTUwZDdlOWM1IiwiZXhwIjoxNTMxOTUzMDcyLCJpYXQiOjE1MzE4NjYzNzIsIm5iZiI6MTUzMTg2NjM3MiwibmFtZSI6IlByYWRlZXAgS3VtYXIiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJwcmFkZWVwLnNoYXN0cnk4NUBnbWFpbC5jb20iLCJvaWQiOiIwMDAwMDAwMC0wMDAwLTAwMDAtMjlhOC0yZDA4MDZjNjk0NTQiLCJ0aWQiOiI5MTg4MDQwZC02YzY3LTRjNWItYjExMi0zNmEzMDRiNjZkYWQiLCJhdF9oYXNoIjoiMDZNT0lRU3dDM2cxMFNlLS1uNjViQSIsIm5vbmNlIjoiQlQyUW0iLCJhaW8iOiJEUmlwc0lTMktmWW51bHp2VGFSVHNFZncwTDdTUWVWYlFycjhuMHZ0cW9SOHk3NEt4djdaSzRLTVJCSm90aEJEVnplQzBadExFdXFZa0VwTXVlaFgwdUZ3cGQ0MDdJRVdmNG9MaXFpd3pnSFAifQ.Abtmpo8hQAka_u1XS4HtfNhjFMJ9bJOZF4Z8GTGZL1m6JRZ0RwHAZHMAztLL-o5nxZdLDZMXGmQE9rQIKt0T4Qmvhtwd5BMCEjb_bN75HRk1mmesHD2WN56Ft5oXLUjtVVDt7fwMymuyJ5K6OXhBVadwlESa_kNunvTDV7mx4mRtXruAMG9vk4P4vpLWOnbkhA5vJFa6muPUAFMvb1j-ezjXsLVRwz4XBeOaEvgZmCG4agDd1hIhoE1vkz1tjg2BmkWFW3Vt276_H47PzT-CKOqdJQ777TYDH_dnChPy2jnvWdaoloo7eVX_pbmX98pFu59uaTdKjCcjnIZr5f8qfg&state=http://localhost:9080_80gyX

Please note that we will see an additional = in the access_token

Quick response is highly appreciated.

bug

All 21 comments

Hi,
Would appreciate a quick response on this as we have a release and we are running out of time to fix this. Any leads is highly appreciated.

I believe the tokens returned by login.live.com are straight base64 encoded, in which case the trailing = is standard base64 padding and is valid. Unfortunately I'm not familiar enough with the picker to take a guess at why it would not accept such a token.

Thanks @ificator for your response. I wonder how the access_token is generated with an = in it. Here is the code from the SDK which is causing the issue
function deserializeParameters(query, queryParameters) { var properties = query.split('&'); for (var i = 0; i < properties.length; i++) { var property = properties[i].split('='); if (property.length === 2) { queryParameters[decodeURIComponent(property[0])] = decodeURIComponent(property[1]); } } }

Since the query param is being split with and = separator, the length of the property is always > 2 and the access_token is not added to the queryParameters.

This is really frustrating to see no help at all from Microsoft. We have been struggling with this simple integration and are getting no support at all with the SDK. We have a release and this feature is blocking us from a smooth release. Can somebody please help us out here. There really isn't anything we can do to solve this from our end

It looks like a bug in the query string parsing - it should not be using split on =, but rather a combination of indexOf and substr.

Thanks @ificator . But is there a reason why the access_token has and = in it? This works fine sometimes in our app and works always fine in my POC (https://pradeepshastry.github.io/onedrive/app/index.html) . I don't see any difference in the app portal configurations either. Here are the configurations we have in the app portal

  • Platform - Web
  • Allow Implicit Flow - Checked
  • Redirect URLs - Home page URL
  • Microsoft Graph Permissions

    • Delegated Permissions



      • Files.Read.All


      • Files.ReadWrite.All


      • openId


      • User.Read



  • Home Page URl - Same as redirect URL
  • Live SDK support - Checked

Also, when can we expect a fix for the query string parsing fix?

Highly appreciate your time and response.

Thanks for the report and helpful debug info @pradeepshastry & @ificator. I'm confirming that the = splitting is the issue (it looks to be) and fixing the function. Apologies for the delay, I just returned from leave. Will report back shortly.

I've confirmed that the = splitting logic is faulty with the Base64 tokens (thanks again for the tip)... something closer to the below function should address the issue:

function deserializeParameters(query, queryParameters) {
    const properties = query.split("&");

    for (let i = 0; i < properties.length; i++) {
        const qp = properties[i];
        const idx = qp.indexOf('=');

        const key = qp.substr(0, idx);
        const value = qp.substr(idx + 1);

        queryParameters[key] = decodeURIComponent(value);
    }
}

Will engage folks in getting a patch published. Will follow-up once I hear back.

Follow-up: I have a fix in PR and am working to get it approved. Once approved, will follow the steps to publish a new version and will provide the URL here tho its likely to be 7.3.

Thanks @KevinTCoughlin for working on fixing this. Do we have a timeline when this will be fixed as we have a dependency on this for our release and your inputs will help us plan it better.

Earliest is next week. I'm trying to get proper access to unblock a build that's gating my fix. Once that's done will raise the changes to publish, get sign-off, and publish. Sorry for the delay, but I recently inherited this so there are some growing pains. If sooner you'll be the first to know.

I've got the build passing. I'm going to verify locally and then raise a PR to publish a new version of File Picker.

Publish PRs are raised, hoping to have this on the CDN tomorrow if not Thursday. The fix will be part of v7.2.

@pradeepshastry have you seen an issue similar to #900 recently?

@KevinTCoughlin Nope, I haven't came across this issue.

The library fix is merged, but given the cache headers expire in 24hr on Friday we've decided to deploy first thing Monday morning PST in-case of regression. I will follow-up once the deployment is complete on Monday. It also gives us time to see what is going on with non-blocking #900.

Sorry for the slight delay, but I do appreciate the report and your patience @pradeepshastry.

Thanks for the update and quick fix @KevinTCoughlin .

@KevinTCoughlin Do we have the fix deployed. I checked it this morning and I still don't see it

@pradeepshastry deployment finished this morning, can you try the updated scripts?

<script type="text/javascript" src="https://js.live.net/v7.2/OneDrive.debug.js"></script>
Or
<script type="text/javascript" src="https://js.live.net/v7.2/OneDrive.js"></script>

Thanks @KevinTCoughlin I am able to see the fix and it is working fine. Thanks a lot for your support. Will let you know if we see any other issues.

Glad to hear that @pradeepshastry -- I'm going to close this issue as I consider it fixed. If you see this problem resurface please re-open.

Was this page helpful?
0 / 5 - 0 ratings