I am trying to implement a sliding token, so that on the first API request a renew token request is initiated. However, right now there is a race condition going on in LocalStorage where the nonce and state object are being overwritten by the next api request.

I am not clear whether this is even the right approach, per my issue IdentityModel/oidc-token-manager#8. However, I have came up with a strategy to prevent the race condition and am curious whether this is something worth creating a PR over.

I have added the following to the OidcClient:

    OidcClient.prototype.tokenRequestInProgress = function () {
        var client = this;
        var settings = client._settings;

        if (settings.store.getItem(requestDataKey) === null) {
            settings.store.setItem(requestDataKey, "in-progress");
            return false;
        } else {
            return true;
        }
    };

Then in the TokenManager within the renewTokenSilentAsync add this check as the refresh is already in flight:

TokenManager.prototype.renewTokenSilentAsync = function () {
        var mgr = this;

        if (!mgr._settings.silent_redirect_uri) {
            return _promiseFactory.reject("silent_redirect_uri not configured");
        }

        var settings = copy(mgr._settings);
        settings.redirect_uri = settings.silent_redirect_uri;
        settings.prompt = "none";

        var oidc = new OidcClient(settings);
        //if the refresh is in flight by another call then don't create another
        if (!oidc.tokenRequestInProgress()) {
            return oidc.createTokenRequestAsync().then(function (request) {
                var frame = new FrameLoader(request.url);
                return frame.loadAsync().then(function (hash) {
                    return oidc.readResponseAsync(hash).then(function (token) {
                        mgr.saveToken(token);
                    });
                });
            });
        }
    }

Hi I have been giving the task to implement SSO for an existing Angular SPA App using IdentityServer3.

I would have liked to use a refresh token, but since it's out of the question, I guess that the next best thing is an hidden ugly (-: IFRAME

Before I start using your code I would ask if its production ready and if there are any typings made for this library.

Hello @brockallen,

I was wondering if there is a way to silently refresh a token for a user without the use of an iFrame.

I noticed the library attempts to inject an iFrame into my application, however the framework I am working with (aurelia, together with SystemJS to load libraries) seems to keep getting rid of this iFrame because it replaces the entire DOM structure and keeps only the application and libraries loaded with SystemJS.

Now, I managed to load the library through SystemJS, however using an iFrame does not seem to be an option.

Would there be any workaround or a way to use ajax calls for this?

Thanks a lot in advance!

I'm wondering if there are any examples or guidance available on how to use this library in an angular 2 app?

I'm not hugely experienced in javascript development but I've had a go at using oidc-client in a simple app. However as soon as I add a reference (to the compiled version) in my index.html, the angular system seems to stop working. Triggering a click event starts it up again and data is rendered to the view as normal . Sign-in, get user, sign-out etc all seem to work well. However the ui does not get updated (unless I trigger a click afterward).

Is there something I'm missing that will get this playing nicely with Angular 2?

I looked at the sample app provided and I also looked at the latest IdentityServer3.Samples. I'm trying to figure out how the popup signin is intended to work. The popup window opens to IdSvr but after authentication the popup is redirected to the calling index.html. Is there something built-in to trigger closing the popup window after authenticating that passes back the result to the calling page?

First of all, thank you for this awesome library! Is there any interest in allowing unsigned tokens (not using RSA) in this library? I'm testing against Ping Federate, and I do not have a X.509 certificate returned as the first/only entry in my /pf/JWKS endpoint. As a matter of fact, there are no certificate chain values returned in the JWKS results.

In lieu of this, is there much harm in allowing the oidc-client to just use .parseJWS(token) where there are no certificates returned?

Please take a look at a possible implementation in my fork: https://github.com/mitch-b/oidc-client/commit/8c97eb51b30686baacd3f0070b520102615e3795.

I am very new to this, so trying to make sense of this new world while jumping numerous hurdles...

In my project I have a static UserManager instance with automaticSilentRenew enabled. My question now is two-fold:

1. Where do I get the renewed user object from?
   I see that there is a userLoaded event I can subscribe to. Is this event raised after a successful silent renew? Does this event pass over the newly loaded user as a parameter to the callback?
2. Which user manager instance raises the event?
   The beforementioned user manager instance is set to work with my application. The silent renew page to be loaded into the iframe creates another instance to call the signinSIlentCallback function, inspired your sample. Which one of these two instances will raise the event?

Hello,

I am trying out the lib using https://github.com/maxmantz/redux-oidc as a wrapper.
I am experiencing some trouble with my redirect callback that gives me signature validation failed. I want to enable logging so I can check if a raw exception gives me any clues.

I have tried import Oidc from 'oidc-client'; Oidc.Log.logger = console;both in my Express server file, and in my Root React component, but nothing happens.

Am I totally on the wrong track here? @maxmantz ref: maxmantz/redux-oidc#5

Hello,

Just spotted that when token stored in browser storage is expired and user manager reads it, it doesn't check for expiration. So if token is already expired it'll be used anyway.

I think there should be check for token expiration when it's being read.

Original issue: IdentityServer/IdentityServer3.Samples#189

We forked your library and ported it to be a pure node server side component for our purposes. We want to make sure we're abiding by your intentions. Do you know what licenses you want to release this under? Apache, MIT, other?

I use oidc-client against IdentityServer with implicit flow. I get back the access_token and need to get a value from it's payload, specifically the "sub" / "subject" value.

However, since its not a id_token it seems oidc does not parse the claims, and even if it would, telling from the code in the User class or the UserManager class, I see no way of how to access the claims / token values.

Currently I use jsrsasign to manually parse the token property from the User object. Which is quite a massive overhead: oidc has it included but not exposed, so I can't re-use that and need to add it as an additional reference, so it's included twice.

It would be very convenient if the User object would not only expose the token itself, but also the parsed headerObj and payloadObj of the token(s).

Or is there another way I did not figure out to access the token information?

Hi,

The function _filterSigningKeys in MetadataService looks for a "use" property on the keys being filtered. As far as I can tell from this RFC, this property is optional:

Use of the "use" member is OPTIONAL, unless the application requires its presence.

The keys provided by the authority I am working against do not have this property set. Any suggestions?

Thanks for the great work!

Hi,

I have run into a situation in which some code calls UserManager.getUser() whenever a userLoaded event is fired. This is causing an infinite loop, as the getUser() function emits a userLoaded event internally.

I'm wondering if this is intentional, or if it is a bug? A userLoaded event should only be fired when a signin-process is successful, or when loading a token from local storage, right?

Basically, we want to refresh the id_token and access_token, when it is about to expire. So, that user can keep on working on the app without interruption. I think refresh_token can be used to do a ajax post in case of implicitflow. Kind of newbie to all this, any help and links would be appreciated :)

Hi Brock,

when using requirejs with oidc-client together, in the browsers which does not have native support for Promise, oicd-client throws exception.

Cause of the issue is bundled version of es6-promise (v2.0.0, file here) and following lines at the bottom of the file:

/* global define:true module:true window: true */
if (typeof define === 'function' && define['amd']) {
  define(function() { return es6$promise$umd$$ES6Promise; });
} else if (typeof module !== 'undefined' && module['exports']) {
  module['exports'] = es6$promise$umd$$ES6Promise;
} else if (typeof this !== 'undefined') {
  this['ES6Promise'] = es6$promise$umd$$ES6Promise;
}

window.Promise = window.Promise || this['ES6Promise'].Promise; // do this to access Promise directly

When used with requirejs, first if condition is true. This code gets executed:

if (typeof define === 'function' && define['amd']) {
  define(function() { return es6$promise$umd$$ES6Promise; });

while this else if does not get executed:

} else if (typeof this !== 'undefined') {
  this['ES6Promise'] = es6$promise$umd$$ES6Promise;
}

However, last, unconditional line always assumes that this['ES6Promise'] has been set:

window.Promise = window.Promise || this['ES6Promise'].Promise; // do this to access Promise directly

As a quick-fix, in my local project I replaced above live with:

window.Promise = window.Promise || es6$promise$umd$$ES6Promise.Promise; // do this to access Promise directly

However, as permanent solution, perhaps update of es6-promise should be considered? Current version is v3.0.2.

Sorry - I won't leave you alone just yet :-)

When switching from the oidc-token-manager one thing that I found odd in the new UserManager is that the getUser() function returns a promise. I guess this is because an aynchronous call to the user info endpoint is made to load user data?

Anyways - what was really convenient about the oidc-token-manager was that you could just generate a new instance and had everything about the currently stored user available. Especially when running initialization logic in my app on startup, having the user information not readily available is problematic, it opens the gates to 'callback hell' when dealing with promises. Is there a way to synchronously check whether or not the currently stored user (in sessionStorage) is still valid? I was thinking about a method called getUserSync() which does nothing but read out the values in sessionStorage and put them in a user object just as getUser() would, but without any asynchronous calls.

I'm having problems using the dev branch with a simple cordova project, specifically around the popup handling. I use InAppBrowser so window.open is hijacked which means calls like _popup.focus() fail. I suspect some custom code may be required to support InAppBrowser usage, similar to what was implemented in oidc-token-manager.js in this demo project: https://github.com/dtuit/Demo.IdentityServer.Cordova.

Is cordova support in the works for this library? I have several cordova/Ionic apps in need of this feature.

So callback page doesn't have to be re-configured with oidc-client on callback page.

That model the sample app.

I'm working in a jsclient (SPA), the automatic silent renew is working fine but when I reload the page (e.g: pressing F5) it does not anymore, I can even see the valid token in the storage but it seems that the userManager does not "realize" that it is going to expire.

This scenario worked without any problem with the oidc-token-manager (I'm migrating). Is it about some new validation or a bug that the timer is turned off after the page-reload?

Best regards.

I've tried using the new client with my project. When I try to transpile/uglify the module, I get the following error:

ERROR in index.js from UglifyJs
Unexpected token: name (Log) [./~/oidc-client/index.js:4,0]

I think this is because the main entry of the package.json points to the index.js which is written in ES6 and therefore cannot be uglified. I suggest pointing it to the distributable version in dist/oidc-client.js so that the module can be used properly.

It would be beneficial for npm users if you could remove es6-promise from the dist bundle. This would give us freedom to include it ourselves if we really need it.

A side-effect of including es6-promise in the dist bundle is that it causes view rendering in Angular 2 to malfunction. The underlying problem is that zone.js - a dependency of Angular 2 - hooks into all kinds of events and hooks in the browser, among them Promises. When oidc-client and its accompanying es6-promise loads, it overwrites the global Promise object, which messes with zone.js and causes ramifications in Angular 2.

Hi ,

Great library!

The automaticSilentRenew is not functioning. I setup my javascript similar to the provided sample.
I see messages in the console:
access token present, remaining duration: 178
Log.js:55 registering expiring timer in: 118
Log.js:55 registering expired timer in: 179
Log.js:55 Raising event: User loaded
automaticSilentRenew is configured, setting up silent renew

But when I look at dev tools of Chrome or with fiddler I cannot see any call to the auth server

Thanks for your help

Oren

Maybe useful:

https://crypto.stanford.edu/sjcl/

Is there a way to use the EnablePostSignOutAutoRedirect setting from oidc-client-js? I tried passing a setting but it appeared to be ignored.

Hi, in Oidc-token-manager reported issue: IdentityServer/IdentityServer3#1670.
As far as I can see, in latest version, there is no way to configure iframe navigator timeout. May I expect, that it will be changed in next releases?

Long title, I know. It's also a long post. Sorry for that!

tl;dr - when calling signinRedirect from within the catch() of a failed promise from signinSilent(), the wrong parameters are being passed to the identity server.

So maybe I'm doing something unorthodox here, but to me it seemed like a legitimate way to achieve what I want: Upon navigating to a screen in my SPA, check if the user is authenticated. If they are, navigate. If not, attempt to perform a silent signin using an iframe. If the user is logged into identity server already, the silent redirect occurs and navigation completes. If there is no cookie for the auth server (so silent iframe signin fails), redirect the user to the signin screen for the identity server to complete the auth process (then redirect back as per OIDC spec).

So the relevant part of this process' code is here:

        // userManager is the oidc-client library's UserManager class.
        // data is the field where the OIDC state param goes
        var state = {data: navigationInstruction.fragment};
        return userManager.loginSilent(state).then(result => {
          console.log('signinSilent finished with: ', result);
          return next();
        }).catch(er =>
        {
          console.log('signinSilent failed.  Doing full page redirect.');
          this.userManager.loginRedirect(state).then(result => {
            //cancel navigation, redirect will occur.
            return next.cancel();
          }).catch(er =>
          {
            console.log('redirect failed:', er);
          });
          return next.cancel();
        });

This worked as expected, mostly. The problem is that I would not be directed to the login page for identity server, but rather presented with an error "login_required". I dug a little bit and discovered this is completely normal if you are using prompt: none which is rightfully used by the iframe silent signin. So I checked the parameters, and sure enough, that was being passed along with the silent_redirect_uri, instead of the redirect_uri I had set.

So I did a little more digging into the oidc-client source and discovered I could pass those settings in at the time of calling signinRedirect() I tried and it works:

        // userManager is the oidc-client library's UserManager class.
        // data is the field where the OIDC state param goes
        var state = {data: navigationInstruction.fragment};
        return userManager.loginSilent(state).then(result => {
          console.log('signinSilent finished with: ', result);
          return next();
        }).catch(er =>
        {
          console.log('signinSilent failed.  Doing full page redirect.');
          // -------------------------- These two lines:
          state.prompt = 'consent';
          state.redirect_uri = this.config.redirectUri;
          // ^^^^^^^^^^^^^^^^^^^
          this.userManager.loginRedirect(state).then(result => {
            //cancel navigation, redirect will occur.
            return next.cancel();
          }).catch(er =>
          {
            console.log('redirect failed:', er);
          });
          return next.cancel();
        });

Firstly, does this workflow make sense? If silent sign-in fails, call redirect sign-in from the catch() of the promise?

Secondly, should it still use the settings it normally would use in this case? (So prompt: undefined or whatever the default setting is for signinRedirect(), and use redirect_uri instead of silent_redirect_uri? If so, this is a bug.

Hello,

I've spotted some strange behavior that if user nagivates out of page during JsonService call it will fire onerror handler. I've some logic that if silent renew will fail i redirect for token and it's happening right now if user navigates out of page. I've spent some time trying to reproduce it and i've found that it exists only in firefox. After short googling it seems that mozilla fires wrong event handler (onerror instead of onabort) when user navigates out of page https://bugzilla.mozilla.org/show_bug.cgi?id=768596.

I don't think that there is much you can change in oidc-client. I'm writting this because maybe someone else will face the same problems and i hope to spare him some time finding cause of this bug.

This may be more of a webpack-related question, but then again maybe not.

I can't figure out how I can change the user store to use localStorage rather than session storage. Currently if I open a new tab in my client application, it does not have access to my user information, and therefore begins a login redirect.

I have tried passing on the settings object to the UserManager with userStore: localStorage but I am getting TypeError: this._userStore.get is not a function(...) when calling UserManager.getUser(). Here are the two log entries leading up to the error:

UserManager.getUser
_loadUser

Some long time ago I was watching the evolution of your Identity Server, Authorization server and related "parts" with excitement, waiting for the nice opportunity to use them in the Open Source projects. Since then, I got completely immersed in Aurelia, focusing on development of various components that now allow Aurelia application developers to use existing third party UI toolkits (KendoUI, SyncFusion, Materialize, etc).

Now, I need to provide a world class interface between Aurelia and {authentication, authorization} services and your software comes to mind immediately (helped by your just announced oidc client, which seems like "invented for me".

Question: is there a chance that you can guide me to help me make Aurelia get the benefits of your work?

I'm currently writing an example app for my library. For that I've registered the app at Google's OpenID provider. Of course the settings used for the UserManager, including the client_id will be accessible via GitHub. What implications does this have? Should I hide the client_id to make sure no one can hijack my app?

In the first reply to #28, I saw that you wanted the dist folder for referencing the files, which is great.
If possible, can you put either the sourcemap or a plain concatenated version of the file? Ex: oidc-client.js, oidc-client.min.js

Reason: stepping through the code while in dev in order to whitebox debug. This is a standard for js libraries I've seen.

Hi,
In method validateIdTokenAsync the following code checks if a token is expired or not:

    var now = parseInt(Date.now() / 1000);
    if (id_token_contents.exp < now ) {
       return error("Token expired");
    }

Shouldn't take this check time zones into account. In typical cases, the id_token_contents.exp value is provided by the server, right, which may run in another timezone than the client that executes Date.now(). My guess is that now should be corrected with the timezone offset as returned by new Date().getTimezoneOffset().

Am I correct in this, or did I overlook something?

Kind regards,
Merijn

Microsoft browsers below version 10 doesn't natively support XMLHttpRequest.
A popular polyfill called xdomain(https://github.com/jpillora/xdomain) makes IE9 support (CORS) requests across external domains.

After implementing this and using the oidc client, the promise for client.createTokenRequestAsync never resolves and fails silently. In the background, the XMLHttpRequest has resolved correctly, except that the "xhr.response" is undefined. The IE9 network inspector shows that the request to get the .well-known endpoint has succeeded.

The source where it fails is in the this.getJson(url, config) function:

    var xhr = new XMLHttpRequest();
                xhr.open("GET", url);
                xhr.responseType = "json";

                if (config) {
                    if (config.headers) {
                        setHeaders(xhr, config.headers);
                    }
                }

                xhr.onload = function () {
                    try {
                        if (xhr.status === 200) {
                            var response = xhr.response;
                            if (typeof response === "string") {
                                response = JSON.parse(response);
                            }
                            resolve(response);
                        }
                        else {
                            reject(Error(xhr.statusText + "(" + xhr.status + ")"));
                        }
                    }
                    catch (err) {
                        reject(err);
                    }
                };

The issue is resolved by replacing xhr.responseType = "json" with type "text".
It would be nice to have a condition for checking if the browser has window.XDomainRequest defined, if so, the responseType should be using "string".

Thanks.

I have a working login and redirect in Chrome but when running the same code in IE 11 the login form opens but after creds are entered a white page remains

the redirect back to the page never happens in IE

When I call:

userManager.siginRedirect({ some: 'data });

How can I access this value after the redirect? I guess it's in the user object's session_state passed into the callback but I don't know how to decode it.

Great job with this. I've started working with it in an Angular 1.5 application, and so far it's been super easy to work with.

Would love to see this as a bower package though. Like a lot of devs, I try to limit the use of npm for just the tooling and node.js specific stuff, and use bower (or jspm or whatever) for the pure front-end application dependencies.

The oidc-client is pretty large. That is, the code for oidc-client itself is small (around 15K) but the dist with all dependencies in minimal form is around 90K. Is it possible to reduce this size? E.g.,

• the included crypto.js is 50K. Does oidc-client really needs the full crypto package? I'm using part of it myself which takes just 7K.
• Also rsa (126K), es6-promise (32K), and jws (26k) are pretty large. Are they really needed, or are there smaller alternatives possible?

I'm using oidc-client on a smart-phone webapp, where it takes significant time to load the library.

I develop SPA on top of jQuery / KnockOut / Durandal. In this tech stack all parameters in URL transferred after hashtag. So my redirect URL looks like:

https://localhost:4748/#auth/login?id_token=eyJ0eX...dis7_g&access_token=eyJ0eXA...Tvz2-Jg&token_type=Bearer&expires_in=3600&scope=openid&state=bd0...b77&session_state=s7Ccf9

At IdentityServer config it looks like:

RedirectUris = new List<string>
{
   Startup.Container.Resolve<IConfiguration>()["Hosting:HttpsUrl"]+"#auth/login?"
},

But default parser at SigninResponse.js ignore all after hashtag. As workaround i use:

var query = window.location.href.split("?").slice(1).join("?");
app.userManager.signinRedirectCallback(query).then(function (user) {
   console.log(user);
});

I think oidc-client is a good tool for SPA builder but ignorance of data after hashtag breaks client side navigation. It must be fixed or explained why it is bad practice.

Currently, it's only using the primary.

I am wondering if you are supporting code flow in your newest version? I have an application where I don't want to expose access tokens to the client, but use a token endpoint to grab it directly from an Express server and store it in a session.

Hi,
I have a problem because signin with popup (from your samples) gives me back a user (when I call get user) and signin main window signs in correctly but the user is always null.

Any idea?

It looks like you might have babel-polyfill installed globally as it's required by the project but doesn't exist in project.json.

This issue will be referenced by my pull request soon

npm install
...
npm WARN [email protected] requires a peer of babel-polyfill@>=6.7.4 but none was installed.
...
npm run build
...
Error: multi main
Module not found: Error: Cannot resolve module 'babel-polyfill' in J:\dev\oidc-client-js
resolve module babel-polyfill in J:\dev\oidc-client-js
  looking for modules in J:\dev\oidc-client-js\node_modules
    J:\dev\oidc-client-js\node_modules\babel-polyfill doesn't exist (module as directory)
    resolve 'file' babel-polyfill in J:\dev\oidc-client-js\node_modules
      resolve file
        J:\dev\oidc-client-js\node_modules\babel-polyfill doesn't exist
        J:\dev\oidc-client-js\node_modules\babel-polyfill.webpack.js doesn't exist
        J:\dev\oidc-client-js\node_modules\babel-polyfill.js doesn't exist
        J:\dev\oidc-client-js\node_modules\babel-polyfill.web.js doesn't exist
        J:\dev\oidc-client-js\node_modules\babel-polyfill.json doesn't exist
[J:\dev\oidc-client-js\node_modules\babel-polyfill]
[J:\dev\oidc-client-js\node_modules\babel-polyfill]
[J:\dev\oidc-client-js\node_modules\babel-polyfill.webpack.js]
[J:\dev\oidc-client-js\node_modules\babel-polyfill.js]
[J:\dev\oidc-client-js\node_modules\babel-polyfill.web.js]
[J:\dev\oidc-client-js\node_modules\babel-polyfill.json]

• Allows for some unit testing
• Allows for easier modules
• Possibly allows for both npm/server and require/client modules (we'll see if I can make this happen)

We are using Identity Server 4, and I am able to get a token back after authenticating on the Identity Server, but the oidc-client is complaining about the algorithm used to sign it: "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"

I'm using webpack, so this stacktrace is not going to be super useful, but:

oidc-client.min.js:1 algorithm 'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256' not accepted in the list
t.error @ oidc-client.min.js:1
t._validateJwt @ oidc-client.min.js:1
t.validateJwt @ oidc-client.min.js:1
(anonymous function) @ oidc-client.min.js:1
tryCatcher @ bluebird.js:5098
Promise._settlePromiseFromHandler @ bluebird.js:3129
Promise._settlePromise @ bluebird.js:3186
Promise._settlePromise0 @ bluebird.js:3231
Promise._settlePromises @ bluebird.js:3310
Async._drainQueue @ bluebird.js:190
Async._drainQueues @ bluebird.js:200
Async.drainQueues @ bluebird.js:69
(anonymous function) @ bluebird.js:4365

bluebird.js:1482 Unhandled rejection Error: signature validation failed
    at Function.t._validateJwt (http://localhost:3001/bundle.js:40974:28866)
    at Function.t.validateJwt (http://localhost:3001/bundle.js:40974:27755)
    at http://localhost:3001/bundle.js:40974:18655
    at tryCatcher (http://localhost:3001/bundle.js:22305:24)
    at Promise._settlePromiseFromHandler (http://localhost:3001/bundle.js:20336:32)
    at Promise._settlePromise (http://localhost:3001/bundle.js:20393:19)
    at Promise._settlePromise0 (http://localhost:3001/bundle.js:20438:11)
    at Promise._settlePromises (http://localhost:3001/bundle.js:20517:19)
    at Async._drainQueue (http://localhost:3001/bundle.js:17397:17)
    at Async._drainQueues (http://localhost:3001/bundle.js:17407:11)
    at Async.drainQueues (http://localhost:3001/bundle.js:17276:15)
    at MutationObserver.<anonymous> (http://localhost:3001/bundle.js:21572:18)

Here is a sample token being generated/returned from ID Server:

eyJhbGciOiJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGRzaWctbW9yZSNyc2Etc2hhMjU2Iiwia2lkIjoiMjc5RUIzOTRBRDgzMkFEMTY4RURCMTVFRTBDODY3RkFCNjFEQzZDRCIsInR5cCI6IkpXVCJ9.eyJuYmYiOjE0NjQ4ODc2OTcsImV4cCI6MTQ2NDg4Nzk5NywiaXNzIjoiaHR0cHM6Ly9hbHBoYS4yMDIwaWRlbnRpdHkuY29tIiwiYXVkIjoiMTQ2NDY5ODkyNy5hcHBzLjIwMjBpZGVudGl0eS5jb20iLCJub25jZSI6IjRmNjlhYWYwZDI4YjRlYzBiMGJhMmI4YzczZWU3OTc2IiwiaWF0IjoxNDY0ODg3Njk3LCJhdF9oYXNoIjoicGw2UnlTM1NwOUtES2xYU2k2UkVIZyIsInNpZCI6IjciLCJzdWIiOiI5Y2ViNWMxNi03MjdmLTQ3YTktNTk5NS0wOGQzODk1MjJhZGYiLCJhdXRoX3RpbWUiOjE0NjQ4ODE0OTQsImlkcCI6Imlkc3ZyIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYW5kcmV3YUAyMDIwcmVzZWFyY2guY29tIiwiZW1haWwiOiJhbmRyZXdhQDIwMjByZXNlYXJjaC5jb20iLCJlbWFpbF92ZXJpZmllZCI6InRydWUiLCJnbG9iYWxfYWNjZXNzIjoiZGV2ZWxvcGVyIiwiZ2l2ZW5fbmFtZSI6IkFuZHJldyIsImZhbWlseV9uYW1lIjoiQWxicmlnaHQifQ.HOEc9dcDksYjz2DN1Aam5yR-En-jNkUxkn3BD1fnpQrdaYggVKgyFpnhv9FVIdNok_Xx68jN2Lo8WBzEEbmOWysHndxkMsZj9ptRsctUS2m3IAjpTJeea2Q7NkH6lmmPvLZ5CNlNsPPwpD_Vfe8QKJACYRRWsNw3V8Zs_g2E6ND1gjk8anwcDt4Q_298vAYcLPs-Mg5dPIzMMgNhyNyQmxJeahFVSkaPNQp2EbRWIguexPhxBUEs1WjiSrmAPkxyFUoMKYplSGrjEqks8F511Gs0iTJnHvoXRSSITx7PrQfCDRfWg-bYdFtxn4zOjVCGxABf6sjnG8EF5d7lpms1Dw