keratin / authn-js Goto Github PK

If a page is loaded with an expired access token, Keratin returns it while asynchronously issuing a refresh call. If the refresh call fails, the user is logged out.

This does not meet expectations. Sessions should not be restored if they're expired.

Object doesn't support property or method 'remove'

From the iframe.

After logging in, updateStore is called, which causes a session refresh to be scheduled. This causes problems in tests as there's no way to pause the test until the promise is resolved, clear the timeout, or just not cause the timeout to happen. It causes intermittent failures if the promise resolves before the end of a test run, as a server needs to exist to handle the refresh GET.

Is there any ways to perform server-side-rendering (ssr)?

Cause now there is err

`
/node_modules/keratin-authn/dist/keratin-authn.js:167
document.addEventListener('visibilitychange', function () {
^

ReferenceError: document is not defined
at new SessionManager (node_modules/keratin-authn/dist/keratin-authn.js:167:9)
at Object. (node_modules/keratin-authn/dist/keratin-authn.js:322:15)
at Module._compile (internal/modules/cjs/loader.js:689:30)
at Module._compile (node_modules/pirates/lib/index.js:83:24)
at Module._extensions..js (internal/modules/cjs/loader.js:700:10)
at Object.newLoader [as .js] (node_modules/pirates/lib/index.js:88:7)
at Module.load (internal/modules/cjs/loader.js:599:32)
at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
at Function.Module._load (internal/modules/cjs/loader.js:530:3)
at Module.require (internal/modules/cjs/loader.js:637:17)

`

The jhr function correctly interprets HTTP status codes as errors, but if a status code of 0 is returned, which indicates that the connection didn't work at all, it falls through and sends an empty message as the error.

Hi,

We are using AuthN on a product and loving it. Thank you for building it. We're seeing an issue in prod where token refreshes made by authn-js aren't working. I spent a little while today understanding how the SessionManager works, and I think I'm seeing something unusual.

When authn-js attempts to refresh, it isn't even sending along the current jwt. The server gives us a 401 with no response body.

We're running on version 1.3.0 of the js client.

I am using authn-js in an application and was wondering, whether we also want to support a non-singleton usage, like:

let authn = new Authn(hostname, storage)

or

let api = new AuthnApi(hostname)

We could still provide a global instance via the existing import so nothing changes for the end-user.

Another part of this: how do we go about authenticating against two different authn servers. Currently, that would not be possible due authn and api being a singleton.

Would you be open to a PR for this?

See https://www.dropbox.com/s/umdap5yer5xfy2g/Screenshot%202017-02-28%2012.26.30.png?dl=0

Note:
Actually this case has been resolved at #26. But I don't know why, author close the PR

Case:

I build my system using microservices architecture, so login page will be on auth.domain.com while the app on app.domain.com
When login via auth.domain.com, I want my cookie can be read by app.domain.com also
But for current code, Its only can used by current domain (Host only)

Resolve:

Pull Request #32

I add domain name when call setCookieStore as second parameter & optional parameter (for backward compatibility)
so syntax below are valid

setCookieStore("my-cookie"); // it will use current domain as cookie domain, i.e. auth.domain.com

and

setCookieStore("my-cookie", "auth.domain.com");

and with dot prefix (further information read Share cookie between subdomain and domain )

setCookieStore("my-cookie", ".domain.com");

But I can’t create test code for that in test folder.
Since document.cookie always empty if I add domain ; domain=domain.com at CookieSessionStore.ts on update method, I don’t know why

Should I create test for this changes @cainlevy ?

Tested by running localStorage.setItem('empatico-session', 'asdf123'), got the following stack trace:

JWTSession.js?a3d0:21 Uncaught DOMException: Failed to execute 'atob' on 'Window': The string to be decoded is not correctly encoded.
    at jwt_claims (eval at <anonymous> (http://localhost:8080/vendor.9210e3be8341d4623c22.js:2344:1), <anonymous>:21:23)
    at new JWTSession (eval at <anonymous> (http://localhost:8080/vendor.9210e3be8341d4623c22.js:2344:1), <anonymous>:5:23)
    at SessionManager.setStore (eval at <anonymous> (http://localhost:8080/vendor.9210e3be8341d4623c22.js:2358:1), <anonymous>:10:34)
    at setStore (eval at <anonymous> (http://localhost:8080/vendor.9210e3be8341d4623c22.js:391:1), <anonymous>:8:13)
    at Object.setLocalStorageStore (eval at <anonymous> (http://localhost:8080/vendor.9210e3be8341d4623c22.js:391:1), <anonymous>:16:5)
    at eval (eval at 283 (http://localhost:8080/app.5f7485fdef982d649c19.js:207:1), <anonymous>:4:9)
    at Object.283 (http://localhost:8080/app.5f7485fdef982d649c19.js:207:1)
    at __webpack_require__ (http://localhost:8080/login:64:30)
    at eval (eval at 261 (http://localhost:8080/app.5f7485fdef982d649c19.js:39:1), <anonymous>:27:1)
    at Object.261 (http://localhost:8080/app.5f7485fdef982d649c19.js:39:1)
    at __webpack_require__ (http://localhost:8080/login:64:30)
    at Object.632 (http://localhost:8080/app.5f7485fdef982d649c19.js:337:18)
    at __webpack_require__ (http://localhost:8080/login:64:30)
    at webpackJsonpCallback (http://localhost:8080/login:35:23)
    at http://localhost:8080/app.5f7485fdef982d649c19.js:1:1

The claims function might catch and re throw this with a more descriptive error message?

May be worth pushing out a 1.4.1 with dependency updates before releasing v1.5 with the MFA functions added in #60

Currently, the setFooStore config method will also attempt to restore a session and possibly contact AuthN to refresh. With v0.9.0 it returns a promise that a host app can use to trigger business logic.

This makes the mixture of configuration and side effects awkward, and also introduces an order-of-operations problem where setHost must be configured before setFooStore can operate reliably.

Solution: extract restoreSession() into an explicit public method.