Legacy Dev Forum Posts

 View Only

Sign Up

Question About loginPKCEGrant Behavior in PureCloud Platform Client v2 JS SDK 211 version

  • 1.  Question About loginPKCEGrant Behavior in PureCloud Platform Client v2 JS SDK 211 version

    Posted 06-05-2025 18:33

    Bhavik_Shah | 2025-01-23 06:21:49 UTC | #1

    Hi Genesys Developers,

    I’m working with the purecloud-platform-client-v2 library in a custom Angular app, and I have a question regarding the behavior of loginPKCEGrant.

    Context:

    • I use platformClient.ApiClient.instance (referred to as client) for authentication in my app.
    • My AuthGuard (canActivate or canActivateChild) checks if the token exists with the client:
      • If not, I enforce an authCode login by calling client.loginPKCEGrant().

    Observed Behavior:

    1. Initial Login and Page Refresh:
      • loginPKCEGrant checks:
        • If the URL is a redirect and handles it.
        • If a token exists in localStorage and validates it via /api/v2/tokens/me.
        • If neither condition is met, it redirects the user to the login server.
      • After login, the accessToken is stored in localStorage using the _saveSettings method.
      • On page refresh, client.loginPKCEGrant() is called again, retrieving the token from localStorage, validating it, and resolving with the accessToken.
      • Even if I delete the token from localStorage, this works fine during a refresh because the !this.authentications['PureCloud OAuth'].accessToken check fails, and everything is re-initialized.

    This flow works perfectly.

    1. Navigating to Child Routes (No Page Refresh):
      • If I navigate to a child route and delete the token from localStorage during testing (no page refresh), I encounter the following:
        • loginPKCEGrant() is called again by the AuthGuard.
        • It checks localStorage (which is now empty) and validates with /api/v2/tokens/me.
        • However, while /api/v2/tokens/me is successfully called, the accessToken is not returned in the resolved promise of loginPKCEGrant().

    My Analysis:

    • _saveSettings and _loadSettings are methods within the ApiClient class from the JavaScript SDK, used to manage the token in localStorage.
    • _saveSettings stores the accessToken in this.authentications['PureCloud OAuth'].accessToken.
    • loadSettings (called internally by _testTokenAccess) loads the token from localStorage and assigns it to authData. If localStorage is empty, authData defaults to {}.
    • Once loadSettings completes, the !this.authentications['PureCloud OAuth'].accessToken condition in the testTokenAccess method passes (since the accessToken is not in this.authentications).
    • However, note that this is a child route navigation, and the page doesn’t refresh. The client is already initialized, and no re-initialization occurs, which may be why the accessToken is missing in the resolved promise of loginPKCEGrant().

    Questions:

    1. Is this the intended behavior of loginPKCEGrant() during child route navigation (without page refresh)?
    2. Shouldn’t loginPKCEGrant() return a valid accessToken if the client is already in possession of one?

    I’d appreciate any insights or suggestions on this!


    Jerome.Saint-Marc | 2025-01-23 13:07:01 UTC | #2

    Hello,

    Bhavik_Shah, post:1, topic:31361
    delete the token from localStorage during testing

    Is there a specific reason why you delete the token from localStorage?

    Regards,


    Bhavik_Shah | 2025-01-23 15:09:48 UTC | #3

    It is part of negative test scenario.

    The custom application does have localStorage manipulation for some data. This test case assumes issues with that logic deleting other imp data from local storage.

    This test case was a part of the test suite which checks that angular authGuard implemented is able to allow only users with accessToken to visit the component as component has usage of purecloud apis.

    This is isnt a blocker for my progress. The analysis I did showed that logicnPKCE grant , didn't return accessTOken in resolved promised even though the client instance had the token and the api call ' /api/v2/tokens/me' went through just fine.


    system | 2025-02-23 15:10:33 UTC | #4

    This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.


    This post was migrated from the old Developer Forum.

    ref: 31361