603466164219281420 #support-questions

Hey, I had a question regarding the flow & structure. So with the default setup, after a user signs up, where is the information stored (the email and password hash)? Does it get persistently stored somewhere by default or do we need to add another request when the Sign Up button is clicked to our own API to save the user credentials

12/30/2020, 4:45 AM

If you are using the self hosted version, the email and password hash are stored in your db (the one you have connected supertokens core with). If on the other hand, you are using our managed service version, it gets stored in a dedicated database we provide for your instance of the core.

user

12/30/2020, 4:54 AM

@User I gotcha. I'm gonna go with the self-hosted DB. So in the case that I have other information I want associated with a

User

like bio, email, avatar, for example, what would you suggest on how to set that up?

user

12/30/2020, 4:55 AM

Because currently just a user ID, email, and password hash are stored via supertokens right?

12/30/2020, 4:58 AM

> Because currently just a user ID, email, and password hash are stored via supertokens right? Yes. To store other info post sign up, you can override a callback in your node code when initing SuperTokens: https://supertokens.io/docs/emailpassword/common-customizations/signup-form/adding-fields#handle-form-fields-on-successful-sign-up As you can see in the above link, you can override

handleCustomFormFieldsPostSignUp

, which will be called on successful signup. The arguments to this function is the

user

object (

user.id, user.email

). And any extra form fields you may have added to the sign up UI. Using the above, you can store any info associated with your user in a separate table, controlled by your app (and not supertokens).

user

12/30/2020, 5:11 AM

Okay just to confirm I have the correct image in mind, does this sound about right? In my case, I only want to collect the default information from the user on sign up (email and password and nothing else), but after they create their login, I will let them customize their profile and etc.

user

12/30/2020, 5:11 AM

message has been deleted

user

12/30/2020, 5:12 AM

@User Does my mental model look correct

12/30/2020, 5:15 AM

yes! it's correct. A few comments: - You do not need to store the email IDs in your table as you can fetch the email ID using the userID via supertokens. - Since you are using self hosted, both tables will be in your database. So you can also directly read from the supertokens tables if you want as well. Table info and structure can be found here: https://supertokens.io/docs/emailpassword/quick-setup/database-setup/mysql (click on "See table structure" button) - If it makes it easier for you, you do not need to call any API in

handleCustomFormFieldsPostSignUp

function. You can directly insert data into your table from that function - as the function is declared in your API code anyway.

12/30/2020, 5:16 AM

- Also, the "Client" here should refer to your API code and not the frontend code.

user

12/30/2020, 5:22 AM

Gotcha. So would this be more correct then?

12/30/2020, 5:22 AM

this is accurate! yes

user

12/30/2020, 5:23 AM

Awesome thanks Rishabh

12/30/2020, 5:23 AM

happy to help!

user

12/30/2020, 5:36 AM

For the part about > # NOTE: POSTGRESQL_HOST being localhost / 127.0.0.1 will not work in a docker image. > # Please provide the database's local / public hostname or IP address Where can one find the database / public hostname or IP address?

user

12/30/2020, 5:36 AM

Use your public ipv4 address?

12/30/2020, 5:38 AM

You need to use the IP address of your computer in your network. And make sure that the Postgres DB is listening on that IP

12/30/2020, 5:38 AM

This is topic related to docker networking, and there are plenty of resources available to understanding that.

user

12/30/2020, 5:55 AM

I see. I've been using docker compose and think I have the right values but it's not accepting the host + port

user

12/30/2020, 5:55 AM

yaml
// docker-compose.ysml
version: '3'
services:
  database:
    image: postgres
    restart: always
    ports:
      - '5432:5432'
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: pass123

  supertokens:
    image: supertokens/supertokens-postgresql
    restart: always
    ports: 
      - '3567:3567' 
    environment:
      POSTGRESQL_USER: postgres
      POSTGRESQL_PASSWORD: pass123
      POSTGRESQL_HOST: database
      POSTGRESQL_PORT: 5432
      POSTGRESQL_DATABASE_NAME: supertokens

12/30/2020, 5:56 AM

perhaps @User can help you with this.

user

12/30/2020, 5:57 AM

Oh one sec.

user

12/30/2020, 6:01 AM

Okay I got it.

user

12/30/2020, 6:02 AM

If anyone else wants to use docker-compose to run their own postgres container + supertokens container all in one network, here is my docker-compose file for reference:

user

12/30/2020, 6:02 AM

yaml
//docker-compose.yml
version: '3'

services:
  database:
    image: postgres
    restart: always
    ports:
      - '5432:5432'
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: pass123
      POSTGRES_DB: my_db

  supertokens:
    image: supertokens/supertokens-postgresql
    restart: always
    ports: 
      - '3567:3567' 
    environment:
      POSTGRESQL_USER: postgres
      POSTGRESQL_PASSWORD: pass123
      POSTGRESQL_HOST: database
      POSTGRESQL_PORT: 5432
      POSTGRESQL_DATABASE_NAME: my_db

user

12/30/2020, 6:03 AM

Keep in mind you are publishing your ports here. Remove those if you want the containers to be contained within your network in production

12/30/2020, 6:03 AM

thanks! the issue was the value of

POSTGRESQL_DATABASE_NAME

user

12/30/2020, 6:03 AM

Yes I forgot that it was referencing the name of the

database

user

12/30/2020, 6:04 AM

I mixed up

database

and

tables

for a second

12/30/2020, 6:04 AM

ah okay!