No Cache Invalidation After Verify

[blyork]

Hitting the /verify route verifies that account but does not invalidate the unverified account object in the cache. If a user verifies their account quickly enough, the account data comes back as unverified even though they have already verified.

[robertjd]

Hi @blyork , can you provide some reproduction steps to create the stale account problem, and where you are seeing the stale account data? In particular, I want to confirm that you are using the /verify route that is served by this library, and not the default one on api.stormpath.com? Using the default one will result in a stale cache, but if you're going through this library you shouldn't have a problem. Per your stormpath/stormpath-sdk-node#481, that method is already avoiding the cache with the {nocache:true} option, so the _evict call shouldn't be required.

The steps I just did were:

1. Enable email verification for the directory of my Stormpath application and set the Link Base URL of the template to http://localhost:3000/verify
2. Run the Express-Stormpath Example Project
   and configure it to use redis.
3. Register for an account at http://localhost:3000/register
4. Use redis-cli to confirm that there is a new account entry, and that the status of the account is UNVERIFIED
5. Click on the email link, landing on http://localhost:3000/verify and then redirected to http://localhost:3000/#?status=verified
6. Use redis-cli to confirm that there is a new account entry, and that the status of the account is ENABLED
7. Login with the new account and navigate to http://localhost:3000/me and see my status as ENABLED

Can you let me know how this differs from your workflow? Thanks!

[blyork]

@robertjd

We are using the verify route provided by express-stormpath.

Are you sure nocache used? I did a search on the whole code base including dependencies and that single line is the only place that references nocache.

Environment:

We have one redis master and two redis slaves all being watched by three redis sentinels. I connected them to the stormpath SDK using the method recommended in stormpath/stormpath-sdk-node#467.

We do not currently use the register route since our account workflow is based on invitation rather than #. Instead we call createAccount off of the desired directory.

We have a web server and a CRUD server. Both are connected to the same Redis cache environment. The createAccount is called from the CRUD server. Verification is of course done on the web server. CRUD authentication and authorization is done by passing the user's token via a Bearer Authorization header and calling authenticateApiRequest off the application object.

Problem:

In the current release, we can log in but none of the CRUD data loads due to the fact that the Redis cache contains an unverified user.

After this pull request, everything works perfectly.

[robertjd]

Thanks for the info! I'm going to try some more reproduction with the situation you describe. Regarding the nocache option, it isn't an explicitly enumerated option, but any call to getResource, with query options, will bypass the cache, which you can see here

[robertjd]

@blyork can you tell me how the user gets the token that they use for bearer authentication? Do they login after they've landed on the /verify route? Thanks!

[robertjd]

Also: for login, are you using the /# route, or the /oauth/token route with the password grant flow?

[robertjd]

BTW, your fix for the node sdk is totally correct, we do need to invalidate that resource and I'll get that merged after adding some tests. I just want to understand the rest of your use case for posterity :)

[blyork]

We pull the tokens from the cookies and then add them to the header for our CRUD requests.
After hitting /verify, I am able to log into the web server using /# but not authenticate on CRUD due to the stale cache.

Thanks. Do you know when it might make an official release so that we can switch back to using NPM as our source for express-stormpath?

[robertjd]

I've merged the changes into the node SDK, we should get that release out tomorrow. We have some other express-stormpath issues we are working through, and we plan to make a release of express-stormpath this week. Thanks for helping us find this issue! I will leave this open until the release is made.