return send200Response(res, {
      status: 'FIELD_ERROR',
      formFields: {
        id: 'email',
        error:
          'This email is already in use via a social provider. Please sign in instead.',
      },
    });

this doesn't seem to work, not showing any error on the ui

> Another thing, in the methods all the errors are thrown which I think would be catched by the supertokens error handler, how can I achieve that You would need to generate an error using the supertokens error functions. You can see an example of this here: - https://github.com/supertokens/supertokens-node/blob/master/lib/ts/recipe/emailpassword/coreAPICalls.ts#L55 - There is also

GENERAL_ERROR

(example here: https://github.com/supertokens/supertokens-node/blob/master/lib/ts/recipe/emailpassword/api/signin.ts#L63), which if thrown passes the

err

object to your error handler.

@User

formFields

must be an array:

return send200Response(res, {
    status: 'FIELD_ERROR',
    formFields: [{
        id: 'email',
        error:
          'This email is already in use via a social provider. Please sign in instead.',
    }],
});

> which if thrown passes the err object to your error handler What should the error handler send in response, that's what I was asking

when it receives the err object

> What should the error handler send in response, that's what I was asking Your error handler? It can send a 500 response.. whatever you want.. Other APIs you make will also use this same error handler im guessing. So a generic something went wrong error I guess.

What about errors like these

throw new STError(
      {
        type: STError.BAD_INPUT_ERROR,
        message: 'Please provide the code in request body',
      },
      recipeInstance,
    );

Shouldn't they be received by the UI or something?

Those would go to your error handler too. You can send them to the frontend and display an appropriate error. But showing something like "Please provide the code in request body" to your end user wouldn't make sense anyway

Thanks a lot @User , everything works now

great!! We will definitely work on making customisations to APIs easier

> You can create an issue about displaying a specific message (that can be read from the 400 error respose) and we can implement it very soon. Which repo should I create this issue in?

@User I have released a new version of our SDKs to give you the feature you requested: - supertokens-auth-react: v0.9.1 - supertokens-node: v4.3.2 You can safely upgrade to the above without any breaking changes. To send a custom error message that displays on the frontend, you can throw the following error from your signinup API:

throw new STError(
        {
            type: "FIELD_ERROR",
            message: "Some custom message"
        },
        recipeInstance
    );

This will show "Some custom message" on the signup screen when the user tries to login using a social provider.

Cool, I'll try it tomorrow, thanks

Hi! Could somebody please elaborate why do we need idRefreshToken?

The purpose of that is to: - Let the frontend know about changes in refresh token without actually having access to the refresh token. This is used to synchornise parallel calls to the refresh API. - Let the backend know that a session exists even if the access token has expired, and without sending the actual refresh token to all APIs.

So the lifetime of

idRefreshToken

is the same as that of the refresh token, and whenever the refresh token changes, so does the value of

idRefreshToken

. However, the value of

idRefreshToken

itself is meaningless.

@User Thank you for quick reply! I've looked through the code of nodejs-sdk and supertokens-core, and still can't say usage of idRefreshToken became clear to me (the purpose of idRefreshTokenHeader is unclear too). But I'll look closer to the client sdks as well, and maybe I will ask more specific questions. If there are any sequence diagrams with usage of idSessionToken (cookie and header) in documentation it will be very helpfull. Thanks.

There isn't any diagram as such yet 😦 But we can add it soon.

The purpose of

idRefreshToken

is exactly what I described in my previous comment.

hey @User! so, I have the following config for the frontend SDK:

appInfo: {
    appName: "WorkoutApp",
    apiDomain: "https://blah-blah.execute-api.blah-blah.amazonaws.com",
    apiBasePath: "/dev/auth",
    websiteDomain: "https://blah-blah.execute-api.blah-blah.amazonaws.com/dev/auth",
  },

but then on SignUp I get a CORS-related error:

Access to fetch at 'https://blah-blah.execute-api.blah-blah.amazonaws.com/dev/auth/signup/email/exists?email=qwwqwq%40hahah.com' from origin 'http://localhost:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

I think earlier you mentioned that

apiDomain

and

websiteDomain

have to be the same 🤔

So the

websiteDomain

should be

"https://blah-blah.execute-api.blah-blah.amazonaws.com"

and there is

websiteBasePath

which should be changed to

"/dev/auth"

. For development, youe

websiteDomain

will be

"http://localhost:3000"

. Finally, CORS error can be fixed by doing this step: https://supertokens.io/docs/thirdpartyemailpassword/quick-setup/backend#3-add-the-supertokens-and-cors-middleware, where the

origin

value should be

"http://localhost:3000"

.

CORS is not required when the api domain is the same as the website domain (as is usually the case in a nextjs app). But in your case, the api domain is

https://blah-blah.execute-api.blah-blah.amazonaws.com

, and the website domain (during dev) is

http://localhost:3000

. So you need to deal with CORS.

okay, did all that and now the SignUp/In form doesn't show... 😄 😄

You need to navigate to

http://localhost:3000/dev/auth

for the form

since you have set the

websiteBasePath

to

/dev/auth

If you want the form to show up in

/auth

, then you can remove the use of

websiteBasePath

from the frontend and backend config.

yes, that worked out. but wait. why the URL path in my frontend should be dependent on some config? what if I have this:

<Route exact path="/authed">

?

> what if I have this: ? What do you mean?