Dan6erbond

    Dan6erbond

    2 months ago
    I have another architectural question regarding SuperTokens and its Core. How suitable is the solution for use by multiple services? I would like to use SuperTokens to manage users which are authenticated into multiple apps, and plan on using the UserMetadata recipe as well as UserRoles recipe to store permissions, roles and groups (using the metadata as unfortunately groups aren't part of the UserRoles recipe). My question is particularly regarding some features like initializing recipes and creating all the roles and permissions - from what I can tell I just have to call an initialization method in my service and create all those beforehand to avoid issues later, but if I have to do this in every service just to ensure that the data really exists it seems like this isn't the best approach. How would you go about managing users that are accessed by different apps, and was SuperTokens built for this use-case?
    r

    rp

    2 months ago
    Hey @Dan6erbond
    So if all these apps talk and interact with the same user pool, you can connect them all to the same SuperTokens core.
    And then you just have to create the roles beforehand once, and that's all.
    Dan6erbond

    Dan6erbond

    2 months ago
    Thanks! And when those apps connect to the SuperTokens core, will I have to initialize all the recipes everywhere? Or would it be sufficient to initialize them once in my "main" or central app and have it take over? From my understanding the initialization of those recipes allows SuperTokens to create related tables and such, correct? Also, is there any plan to add groups to the UserRoles recipe? It seems like a missed opportunity since it would be just another field that would make user grouping and querying easier.
    r

    rp

    2 months ago
    will I have to initialize all the recipes everywhere? Not really. Only the recipes that you intend to use in that backend. If you have one backend for actual auth, then all recipes there, but if other backend just use the session management feature and roles feature, then just those two.
    From my understanding the initialization of those recipes allows SuperTokens to create related tables and such, correct? Creation of the tables happens on core start. The recipes are initialised so that the SDK knows which APIs to expose from the middleware
    Also, is there any plan to add groups to the UserRoles recipe? What does groups really mean? We have users which can be mapped to an array of roles, and each role can be mapped to an array of permissions. So where does groups fit into this?
    Dan6erbond

    Dan6erbond

    2 months ago
    If you have one backend for actual auth, This is the case, and admittedly I'd like to handle as much as possible over that backend, as it will centralize the user management so I can modify the solution easily, but as you might expect in situations like simply getting some user data or the roles it would be great if I could do that directly in the app. but if other backend just use the session management feature and roles feature, then just those two. That's great. In particular the
    ThirdPartyEmailPassword
    recipe is a huge amount of boilerplate code to setup, but if I only have to initialize that in the backend that handles sign-up/sign-in it will make things much easier!
    Creation of the tables happens on core start. The recipes are initialised so that the SDK knows which APIs to expose from the middleware Oh, gotcha. Interesting. Then another question: How can I find out which APIs the middleware does expose? Those might be useful to ensure as much as possible happens over the main authentication server. What does groups really mean? We have users which can be mapped to an array of roles, and each role can be mapped to an array of permissions. So where does groups fit into this? Well, in a standard directory like LDAP you have groups which could be tenants, organizational units, etc. while roles correspond more to the user's function within that unit. As I mentioned I've already solved the issue somewhat by using the
    UserMetadata
    recipe to store the user's group, but it would be nice if that was part of the
    UserRoles
    recipe as that seems to be handling the user directory overall. Additionally, I'm not sure what the technical limitations exactly are, but being able to query users by
    UserMetadata
    fields I feel would be an awesome addition, and at least in MongoDB and PostgreSQL that should be possible. I know SuperTokens also supports MySQL, so it might require a solution where MySQL reduces performance, but for querying users by certain value I'd find that extremely useful.
    r

    rp

    2 months ago
    This is the case, and admittedly I'd like to handle as much as possible over that backend, as it will centralize the user management so I can modify the solution easily, but as you might expect in situations like simply getting some user data or the roles it would be great if I could do that directly in the app. In that case, you need to do session.init and userroles.init in those other backend
    but if I only have to initialize that in the backend that handles sign-up/sign-in it will make things much easier! Yes - exactly.
    How can I find out which APIs the middleware does expose? Those might be useful to ensure as much as possible happens over the main authentication server.
    https://app.swaggerhub.com/apis/supertokens/FDI
    Well, in a standard directory like LDAP you have groups which could be tenants, organizational units, etc. while roles correspond more to the user's function within that unit. As I mentioned I've already solved the issue somewhat by using the UserMetadata recipe to store the user's group, but it would be nice if that was part of the UserRoles recipe as that seems to be handling the user directory overall. I see. Makes sense. Will probably add this extra layer as part of organisations / multi tenancy feature then.
    Additionally, I'm not sure what the technical limitations exactly are, but being able to query users by UserMetadata fields I feel would be an awesome addition, and at least in MongoDB and PostgreSQL that should be possible. I know SuperTokens also supports MySQL, so it might require a solution where MySQL reduces performance, but for querying users by certain value I'd find that extremely useful. Hmmm. We store the actual JSON in the db as a TEXT field. So not sure how we would go about this without using MongoDB only.
    Dan6erbond

    Dan6erbond

    2 months ago
    I see. Makes sense. Will probably add this extra layer as part of organisations / multi tenancy feature then. Is there an issue for this feature that I can follow?
    Hmmm. We store the actual JSON in the db as a TEXT field. So not sure how we would go about this without using MongoDB only. PostgreSQL should support a JSON field with queryable "columns" so the limitation is mostly MySQL.
    It essentially turns the JSON field into its own "subtable" that supports queries, sorting, and I believe even JOINs.
    r

    rp

    2 months ago
    Is there an issue for this feature that I can follow? Not yet. Feel free to open an issue
    I see. Thanks for the info about the JSON querying.