search

stormpath / express-stormpath

Build simple, secure web applications with Stormpath and Express!
http://docs.stormpath.com/nodejs/express/
Apache License 2.0
325 stars 111 forks source link

No Cache Invalidation After Verify #448

Open blyork opened 8 years ago

blyork commented 8 years ago

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 commented 8 years ago

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/login?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 commented 8 years ago

@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 signup. 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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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

robertjd commented 8 years ago

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 commented 8 years ago

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 /login 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 commented 8 years ago

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.