@UserI was able to fix my issue by moving the file from pages/api/auth to api/auth (which is not the suggested way of doing it according to the vercel docs). I had to put the backendConfig into the serverless functions too

awesome!!

thanks for letting us know. When we write docs for vercel, we will keep this in mind 🙂

I will keep you updated if vercels support knows an alternative solution

Hello everyone. Just started using supertokens. Is there a way to disable signups?

hello @User disabling signups involves two steps: - Disabling the sign up API on the backend - Disabling the frontend sign up widget Before I give you more details, which recipe are you using?

thx for reply. I'm using 'Third Party Email Password' in next.js

Got it. Disabling the backend API will be very easily possible in our next release of the node SDK (coming out this week).. Once it's out, I can give you instructions on how to do that. For frontend, you will want to override the login UI to disable sign up. To do that, follow the steps in this file.

I'd also be happy to get on a quick call to guide you around changes for the frontend as it may be a bit confusing (since we don't have official docs for it yet).

thx a bunch, I'll try to figure it out myself ☺

cool!

feel free to ask more questions in case you are stuck,,

where does Supertoken store the secret/key?

in the db. In the

key_value

table.

it stores the public and private key in there

great.. Also, is there an option to use SHA512 as the algorithm instead of SHA256?

not yet 😦

but if you are worried about secret key being compromise, then you should know that the keys are changed regularly (the older ones are immediately revoked).

And we do this without any user logouts... so really, using

SHA512

over

SHA256

wouldn't make too much of a difference.

understood. Thanks for the quick replies 🙂

I have a few more questions: 1. Can we inject supertokens as a middleware in our java services instead of having a dedicated service? 2. How does the solution take care of CSRF?

> Can we inject supertokens as a middleware in our java services instead of having a dedicated service? No. The superotkens core needs to run as a dedicated http service. If your backend is in Java, we only have a Javalin SDK at the moment. > How does the solution take care of CSRF? https://supertokens.io/docs/session/common-customizations/sessions/anti-csrf

we are using spring webflux for our java services calling a dedicated API for each request might slow us down

The session verification on the backend happens in a stateless manner. That is, it doens't query the core for session verification. It queries the core only for creation, refresh, recoking of sessions.

unfortunately, we don't have support for spring webflux at the moment.

According to this text: "The frontend sends the access token for each API call that requires session authentication. These API calls verify the access token and its expiry. If verification fails, the API throws a session expired error, else, execution continues." Won't by backend API need to communicate with Core for verification of access token each time?

No. Cause the access token is a JWT. So they can be verified in a stateless manner using the public key of the private key that is used to sign them

right, yes.. got it..infact my backend APIs dont need to communicate at all with core, only frontend needs to.. our frontend is in react js

Our architecture is such that the frontend communicates with the core via your backend API domain. This is because session cookies are to be set against your API domain. To achieve this, you can run a node process that uses our NodeJS SDK, and have a reverse proxy (using Nginx) in your backend that routes all /auth/* requests to that node process.