Implement the EmailPassword recipeModule

[rishabhpoddar]

• import EmailPassword from "supertokens-node/recipe/emailpassword"
• All features in this module will have a default API implementation that uses functions provided by this library. These functions can be used by users to create their own API as well.
• The default APIs of all features must be able to be disabled via a disableDefaultImplementation boolean passed to them in their init function.
• Must follow its respective part from the new FDI (v1.3.0) and new CDI
• Following are the sets of features:
  • signInFeature
  • signUpFeature
  • resetPasswordUsingTokenFeature
  • signOutFeature
• The init function of this module takes options as per the above features:

  EmailPassword.init({
     signInFeature: {...},
     signUpFeature: {...},
     resetPasswordUsingTokenFeature: {...},
     signOutFeature: {...}
  })

[rishabhpoddar]

@NkxxkN ,
We need to allow users to create, verify and revoke their own session in an easy way.

So I propose that we add another object in the config:

sessionInterface?: {
   createNewSession?: (userId: string, from: "SIGN_UP" | "SIGN_IN", req: express.Request, res: express.Response) => Promise<any>,
   verifySession?: (req: express.Request, res: express.Response) => Promise<string>,
   revokeSession?: (userId: string, req: express.Request, res: express.Response) => void
}

• Having this interface not only makes it easy for users to customise this behaviour but also makes it possible for us to use sessions in a reliable way in default APIs like reset password using old password (which is something we are going to build soon).
• By default, we will implement these assuming that they are using our session lib.
• The createNewSession will return a JSON containing any session tokens. That will be directly available to them on the frontend in the successHandle callback
• We will need a logout method on the frontend as well. I think it can be tied to the emailpassword recipe since sign in / logout are a function of auth first, and then a function of sessions (it's a part of auth, but implemented via sessions). How do you want to do this?
• Should this interface actually be in the supertokens.init level? Since there could be cases where the session recipe might want to invoke functionality from the auth recipe. In this case, we can make the main supertokens package provide an interface that must be implemented by the user if they want to manage sessions on their own (by default, we will provide an implementation).

NOTE

We will do this later

[kant01ne]

We will need a logout method on the frontend as well. I think it can be tied to the emailpassword recipe since sign in / logout are a function of auth first, and then a function of sessions (it's a part of auth, but implemented via sessions). How do you want to do this?

I agree that at first sight it should be part of emailpassword since it is login related. In the future we will build other forms of login and they will share the logout method. Thinking like this, logout might be something that's implemented by SuperTokens recipe module manager directly?

Should this interface actually be in the supertokens.init level?

Agreed!

[rishabhpoddar]

I agree that at first sight it should be part of emailpassword since it is login related. In the future we will build other forms of login and they will share the logout method. Thinking like this, logout might be something that's implemented by SuperTokens recipe module manager directly?

I think that logout should specific to each recipe as it's tightly coupled with how the login for that recipe works. Sure, many times it's going to have the same implementation, however, it's still semantically a function of that recipe (just like how signin is a function of a recipe)