Unsolved questions

• [ ] Exposing the core to the internet as an "auth server", which is different to an "application server" - this is the standard setup for companies. Here we are sort of forcing the two servers into one?
  • [ ] I guess this can be solved by having two URLS. One for application server, one for auth server. By default, they will be the same, but if they are different, then you are forced to use OAuth recipe.
  • [ ] Do we still require an API key for all routes to the core? Or just the ones that should never be accessed via the frontend directly? If we require for all, we are forcing users to add a proxy server in front of it.. which may be annoying in case they don't wanna do that.
  • [ ] If we allow for the core to be exposed, we must make sure that the intersection of CDI and CDI routes are exactly the same. How?
• [ ] For SSO, will we want to expose this to the internet?
• [ ] I think we can move the plugin-interface and api-interface into supertokens-core. Any thoughts?

Fundamentals of the packages (Modules → Feature API):

The main package (core) provides:

• Github issues related to this:
  • https://github.com/supertokens/supertokens-core/issues/74
  • https://github.com/supertokens/supertokens-core/issues/76

Module

• They must implement the api-interface provided by the core
• Each module is packaged in its own JAR with its own dependencies.
  • TODO: Clashes in JAR dependencies should be managed how?
    • Should each module have it's own directory inside /module/ folder in the installation area? The directory name can be = to the recipeId. The dependencies of this module would be there as well.
  • TODO: How will the JARs be distributed in case of:
    • Manual installation:
      • Add a module into the /modules folder by drag and drop
    • Docker installation:
      • We provide one docker image per our recipe and database
      • Make it very simple for users to create their own docker image with whichever recipe thy want
      • A shared volume with the host machine for /modules folder.
• Should expose a set of APIs per feature api. All these APIs will be prefixed with a /recipe/ path.
• Can have it's own set of config values.
• Has a way to create tables if they are not already created.
• Preventing table name clashes:
  • Can give one database per module
  • Allow the user to override all table names
• Preventing config.yaml params clashes:
  • TODO: Each config.yaml value for this module can be scoped with the recipeId
• Abide by CDI protocol for that recipe