express-stormpath
express-stormpath copied to clipboard
stormpath
Explicitly specifying account store (directory)
Hi,
I'm thinking of moving our API service that was using the node SDK to use the express SDK. However I can't seem to see a mechanism to specify an account store (directory in my case) against which account will be created, verified and tokens generated?
With the node SDK, it was possible to explicitly create an account against a directory and do the above. This was helpful since I created directories mimicking development, staging and production environments and depending on which environment my API service was running, I would create accounts against each using directory.createAccount as opposed to application.createAccount.
Thank you.
Hi @tanzim , thanks for the question! Multi-tenancy support isn't baked into this library yet, but you can follow #292 to know when we add it. It's the next feature we're going to work on, after our current round of bug fixes that we're working on. Please note, though, that we're going to primarily be supporting multi-tenancy through Organizations, rather than directories (this is a general shift in the Stormpath world). We'll still provide some option for targeting account stores specifically, but a lot of the default configuration will assume Organizations.
Hope this helps!
@robertjd thanks for getting back so quickly.
When we started out with Stormpath, org support wasn't official. We followed Setting up Development and Production Environments to model production, staging and development environments.
Going forwards how would you recommend partitioning the environments? Set up orgs matching environments and have a single default directory mapped to each or something else?
Hi @tanzim , thanks for the clarification on your use case (using directories to segment environments). If your application is not a multi-tenant one, you can continue to use your current model and there wont be any issues. If your app is (or will become a multi tenant application) then I would suggest looking at Organizations.
Do you mind if I close this issue in favor of #292?
Hi @robertjd correct, we're not using multi tenancy. However, it seems that I may have still missed a trick as I can't see how in the current SDK I can specify the directory to perform operations against depending on the environment?
To elaborate, let's say I have 3 directories, dev, stage and production (production directory set as the default account store) which are being used by dev, stage and production servers respectively.
The use case is, a user hits the dev server and registers. From what I can see, the user will be created in the production directory, instead of dev since I don't have any control over which directory the user ends up with the express SDK? On the node SDK, I could create the user against the dev directory.
Additionally, I could authenticate, password reset users against different directories using the node SDK using the same mechanism. Given that application level operations traverses the all mapped directories, reseting password for [email protected] which can exist in one or more directory could easily result in reseting the password for the wrong user, so being able to specify the account store is an important one.
Thank you.
That's correct, we need to modify this library to support the passing of account stores as options for login, registration, and password reset (we're using #292 to track this work).
When implemented, we will have to support a "global" account store configuration, meaning that for all requests, you want to keep using that account store. This will support your use case, if I understand it correctly.
For the multi-tenant cases, the account store is defined by the request context. This can be provided by a subdomain, or a form field that the user fills out.
Right as long as that use case is captured in #292 I'm happy for you to close this. Any ETA on #292 by the way?
By the way having looked through the list of pull requests, seems that someone already made one a while back that can potentially be resurrected? See https://github.com/stormpath/express-stormpath/pull/79