Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test."

@slnode ok to test

@benkroeger thank you for the pull request. The code changes look reasonable, I appreciate you included a unit-test too!

I have one concern though.

Digging in the code, I found that the token middleware skips when req.accessToken !== undefined. Unfortunately, if the first instance of the middleware can not find valid credentials, it assigns req.accessToken = null (which is !== undefined).

I think our original assumption was that all instances of the token middleware use the same auth method and if the first instance of the token middleware does find any valid credentials, then the second and all subsequent instances will not find any valid credentials either, and thus we can skip them to improve performance.

Now your use case is different and our assumption no longer holds.

Can we find a way how to support both cases? For example, what if we added a configuration option for the token middleware that will instruct it to run even if other token middleware was not able to find any valid credentials?

/cc @raymondfeng @ritch thoughts?

@bajtos sure, making this a middleware prop shouldn't be a problem. suggestions on the naming? how 'bout enableDoublecheck?

now that I think about it - I actually don't want a subsequent instance to overwrite any existing req.accessToken that was set by a previous instance. Meaning, if a user provides a token on the "regular" way, that one supersedes any other tokens.

now that I think about it - I actually don't want a subsequent instance to overwrite any existing req.accessToken that was set by a previous instance. Meaning, if a user provides a token on the "regular" way, that one supersedes any other tokens.

Sure, that makes sense to me as well.

I am thinking about the following rule:

req.accessToken is defined and truthy 
   => return next();
req.accessToken is defined but falsy && the new feature is NOT in effect 
   => return next();
go ahead, extract & verify the access token

As for the option name, now about overwriteTokenNotFound?

I've implemented a two-step decision now:

It checks for enableDoublecheck to be truthy and, it also a token exists already, overwriteExistingToken must be truthy as well.

if (req.accessToken && req.accessToken.id) {
      rewriteUserLiteral(req, currentUserLiteral);
      return next();
    if (req.accessToken !== undefined) {
      if (!enableDoublecheck) {
        // req.accessToken is defined already (might also be "null" or "false") and enableDoublecheck
        // has not been set --> skip searching for credentials
        rewriteUserLiteral(req, currentUserLiteral);
        return next();
      }
      if (req.accessToken.id && !overwriteExistingToken) {
        // req.accessToken.id is defined, which means that some other middleware has identified a valid user.
        // when overwriteExistingToken is not set to a truthy value, skip searching for credentials.
        rewriteUserLiteral(req, currentUserLiteral);
        return next();
      }
      // continue normal operation (as if req.accessToken was undefined)
    }

@slnode test please!

Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test."

ok to test

Since there hasn't been any updates on this issue from the maintainers, I thought it might be because the tests on travis fail. Judging from the indications, it looks like "grunt" does not get installed correctly during the tests for Node.js 5.0. All of them state "grunt: command not found". Thoughts? Any chance we can get this PR moving again?

@rmg should your latest CI fix have resolved this?

it looks like "grunt" does not get installed correctly during the tests for Node.js 5.0. All of them state "grunt: command not found". Thoughts?

Node 5 is failing on all platforms.

The Node 5 failure looks like it happened before I removed shelljs from the cache (which was the source of the source of the problem when installing deps with npm3). The current failure on node-0.12 on Windows looks like a run of the mill flaky test.

looks like now tests are failing that previously were successful - without further commits / code change. npm-debug.log says something about failing to install phantom.js

r u guys adding more and more tests? What's about all the dependant tests? Didn't see those in other PRs. And the ones I looked at are failing due to timeout reasons (e.g. dependant strong-arc after > 5 mins).

@benkroeger, we have always checked the dependants to make sure that nothing is broken down stream. I believe that the only two dependants that failed that we need to worry about are the angular sdk and the angular live-set.

@bajtos PTAL. Are we still having issues with CI?

@benkroeger please let me know when this patch is ready for another round of review. Note that github does not send any notifications when you add a commit, one has to leave a comment for that (ideally including the GH handle of the reviewer).

alright @bajtos this PR is ready for another review. I reverted the blank changes and am using a better comparison on the token object in my unit test

@slnode test please

Landed via a9c7801, thank you @benkroeger for your contribution and the patience with us :)

Finally! 🎉

Agreed, thanks a lot @benkroeger, awesome job!

Woohoo!
Thanks guys!
@richardpringle @bajtos I just saw that my last commit didn't make it into the merge. It solves a potential "can not read property of null" error that I occurred during one of my experiments. Any chance to get that one in, too?

forget my previous comment. it's in a9c7801
sorry for the confusion!

@benkroeger ouch! Could you please add a unit-test to a9c7801 that demonstrates/reproduces the bug in the current implementation and send a new PR? Please mention my GH handle in the PR description, I'll get it landed ASAP.