• r

    rp

    1 year ago
    whereas sessions works in plain JS too
  • l

    LaurentS

    1 year ago
    hmm, I don't mind building the UI for login/signup/etc, as long as the logic is handled in supertokens
  • l

    LaurentS

    1 year ago
    I just need email/pass signup, nothing fancy for now
  • l

    LaurentS

    1 year ago
    Honestly, I'd rather have ready made UI as well, but ...
  • r

    rp

    1 year ago
    Yea. So you can use supertokens-website repo for sessions (works with plain JS). The docs are here: https://supertokens.io/docs/website/installation Then on the backend, you can use our supertokens-node SDK. Follow the backend quick setup: https://supertokens.io/docs/emailpassword/quick-setup/backend. This would expose APIs for sign up / sign in / reset password etc etc using which you can build your frontend UI. The list of APIs are here: https://supertokens.io/docs/nodejs/emailpassword/default-apis And finally you would have to run the supertokens core which you can run yourself (see this page: https://supertokens.io/use-oss) or let us run for you (need to sign up for this).
  • r

    rp

    1 year ago
    If you have any trouble understanding the API's input / output, then please feel free to ask questions here.
  • r

    rp

    1 year ago
    The supertokens-website repo only manages session tokens. So you will need that even if you build your own login UI.
  • l

    LaurentS

    1 year ago
    thanks for this @User looks like what I needed!
  • l

    LaurentS

    1 year ago
    bonus question then: I'm trying to build an onboarding flow with as little friction as possible. I ask new users a couple of questions, then their email to generate their account, and eventually have them add a password and so on at a later point. Does it sound feasible with supertokens?
  • r

    rp

    1 year ago
    So your UI can decouple the email and password asking, but both will be required to create a new user account. If you don't want that behaviour, then you can hack this by generating a fake password for a user, creating a user, and then later when you ask the user for their actual password, you can change that fake password using the functions we expose via our node SDK. That being said, I suggest that you don't do this anyway cause what if the user logs out before you get their actual password.. then they would have to go through the reset password flow which can be annoying for them.