- 09 Feb, 2017 5 commits
-
-
Sean Hammond authored
Add OAuth refresh support
-
Sean Hammond authored
-
Sean Hammond authored
Just separating concerns, and also future code is going to reuse this function as well, reducing duplication.
-
Sean Hammond authored
Just separating concerns, and also future code is going to reuse this function as well, reducing duplication.
-
Robert Knight authored
Cache access token promise not access token
-
- 08 Feb, 2017 12 commits
-
-
Sean Hammond authored
-
Sean Hammond authored
Cache the access token request promise, not just the access token itself. This commit fixes a problem that the client would send multiple concurrent access token requests if tokenGetter() was called multiple times before a response to any of the HTTP requests was received: 1. tokenGetter() is called, sends an HTTP request for the access token and returns a Promise for the access token from the request's response 2. Before the HTTP response is received tokenGetter() is called again, sends another HTTP request, returns another Promise. As soon as one access token response is received then tokenGetter() caches the access token and just returns it, doesn't send any more HTTP requests, but each time tokenGetter() is called *before the first access token response has been received* it sends another, concurrent access token request. It does not "know" that it already has an access token request in-flight. The fix is to cache the first access token request Promise when the first access token request is sent and then just keep returning that Promise, instead of sending more requests: Instead of caching the access token itself (`cachedToken`) we now cache a Promise for the access token (`accessTokenPromise`) the first time we send the access token request. Each further time that `tokenGetter()` is called, if it already has a `accessTokenPromise`, then it just returns the Promise and doesn't send another HTTP request. It now "knows" that it already has an access token request in-flight.
-
Robert Knight authored
Don't reuse OAuth grant tokens
-
Robert Knight authored
Add test for failed grant token request
-
Sean Hammond authored
-
Robert Knight authored
Don't delete cached OAuth access token
-
Sean Hammond authored
Simplify the oauth-auth service by not caching the grant token in memory - it is (now) only used once anyway.
-
Sean Hammond authored
Don't reuse the OAuth grant token if the access token has expired. The grant token is only intended to be used once, and if the access token has expired then the grant token will likely have expired as well anyway. A later commit will add support for refreshing an expired access token using its refresh token, instead.
-
Sean Roberts authored
Add examples in docs for sidebar trigger and annotation count display.
-
Sheetal Umesh Kumar authored
-
Sean Hammond authored
When using OAuth (the host page provides an embedded grant token) don't call auth.clearCache() on session update. The authorized user never changes when using OAuth with a grant token embedded in the page, and the oauth-auth service's clearCache() is a no-op anyway, so there is no point in calling clearCache() here.
-
Sean Hammond authored
This fixes an issue that, when the client is embedded on a partner site using third-party auth: 1. The client reads grant token that the client embeds in their page from the page 2. The oauth-auth service sends a grant token request, receives back an access token which it caches 3. session.js calls oauth-auth's clearCache(), which deletes the access token 4. The next time the access token is needed the oauth-auth sends a second grant token request, with the same grant token, and gets a second access token So two grant token requests are sent, when only one was needed, because the cached access token is deleted unnecessarily. The fix is to make clearCache() in oauth-auth a no-op for now. For now it never makes sense for oauth-auth to clear its cached access token. OAuth is currently only used when the client is embedded in partner sites and the grant token is embedded in the page by the client. Since the grant token never changes, there's never any reason to clear the access token and request a new one using the same grant token again (you would just be requesting a new access token for the same user account).
-
- 06 Feb, 2017 2 commits
-
-
Sean Roberts authored
Set initial annotation counts to 0 because annotation counters are not…
-
Sean Roberts authored
Remove unused SESSION_CHANGED event
-
- 03 Feb, 2017 9 commits
-
-
Sheetal Umesh Kumar authored
Set initial annotation counts to 0 because annotation counters are not updated if a page has no annotations.
-
Robert Knight authored
-
Robert Knight authored
-
Robert Knight authored
-
Nick Stenning authored
Minify production build and fix prod build in non-ES6 browsers
-
Robert Knight authored
Ensure that NODE_ENV is set to 'production' when building the client for release and thereby ensure that the JS and CSS is minified.
-
Robert Knight authored
We are not currently transpiling client code using Babel, so this doesn't work with our minifier or older browsers.
-
Robert Knight authored
This event was fired by the `session` service but not listen for by any other module.
-
Robert Knight authored
Use new profile update endpoint for dismissing sidebar tutorial
-
- 02 Feb, 2017 6 commits
-
-
Robert Knight authored
-
Robert Knight authored
Explicitly update vinyl-fs's graceful-fs dependency to v3.0.11. graceful-fs v3.0.8 had a dependency on an internal Node module which no longer exists in Node v7. See https://github.com/gulpjs/gulp/issues/1843
-
Robert Knight authored
-
chdorner authored
-
chdorner authored
-
chdorner authored
Make `store.profile` an object containing `read` in preperation for the upcoming changes where we will use the update profile endpoint for updating a user's preferences.
-
- 01 Feb, 2017 6 commits
-
-
Sean Roberts authored
Adding client metric tracking for interactions with annotations
-
Robert Knight authored
In preparation for adding a profile update endpoint, the name of the route for fetching the profile was renamed to 'profile.read'. See https://github.com/hypothesis/h/commit/a3d45a4a4abb5b7b6f899eade5186820340a545c
-
Sean Roberts authored
-
Sean Roberts authored
Verify userid after connecting to WebSocket
-
Robert Knight authored
-
Robert Knight authored
Listen for the 'whoyouare' reply to the 'whoami' request sent after the WebSocket connects and log a warning if the userid does not match the logged-in user for any reason.
-