@User the docs for styling of thirdpartyemailpassword styling have been fixed. Thanks for letting us know about the error 🙂

@User heads up: on your NextJS documentation you suggest creating the config file for supertokens inside the 'pages/' folder. This breaks the NextJS build (at least when deploying to Vercel, locally it worked just fine) with the error:

> Build error occurred
Error: automatic static optimization failed: found pages without a React Component as default export in

I just moved the file out of

pages/

(into a folder that I named

config/

) and it fixed it.

I see. Thanks! I'll update the docs and the example 🙂

Hello again.. Thanks to @User for meeting with me a few weeks ago. Using the Next/React format and the EmailPassword recipe, I've managed to: 1. Deploy something 🥺 resembling a production build to Vercel, and 2. Create users in MySQL on my production server via the supertokens CLI locally (I can view all of this live via PHPMyAdmin, which is sweet) . However my dev/prod (Managed Service), and custom URIs and APIs do not seem to be working in prod, on Vercel. I have tried changing the

env.

variables as well. So I can't access my dev/prod (Managed Service) users, or any of the MySQL users when logging in- "Something went wrong" Error. My local setup seems to work fine, connecting to my production instance

https://f9537f518b9c11eba49dcbf073da756f-us-east-1.aws.supertokens.io:3567

Are there any

env.

or configuration steps I need to review? Thanks!

Hey @theefunklord can you see what the error is from the network tab when you send the request?

If the request is not reaching the serverless function, then maybe the apiDomain / websiteDomain value is incorrect?

Sure.. It looks like a 500 error

Is there any way that you can see the error logs of the serverless functions?

Got it. You need to call supertokens.init (from supertokens-node) SDK in all the api routes that use any supertokens' functions

I suggest that you see the updated docs: https://supertokens.io/docs/emailpassword/nextjs/init

Basically extract the config to another file, and use that everywhere in your API routes

So for example, in an api route, (https://supertokens.io/docs/emailpassword/nextjs/setting-up-backend), you can see that there is

supertokens.init(SuperTokensConfig.backendConfig())

once you do that in all the API routes that use supertokens, this error should go away!

> I will definitely try that. I don't currently have a config, my

SuperTokensNode.init({

is sitting in my

_app.js

file. So I'll give this a go. Thanks @rp!

ALso, one more modifcation (which is not updated on the docs yet) is that the

supertokensConfig.js

should not be in the

pages

folder. Instead put it in a folder called

config

(as an example).

and

config

should be at the root of the project

Thanks again @rp.. Success

Hey! Is there any healthcheck endpoint existing in Supertokens Core?

yes. you can hit the

/hello

API

Awesome, it works, thanks a lot @User !

in the browser, you can navigate your core's host and then /hello. FOr example, if the core is on http://localhost:3567, then you can visit http://localhost:3567/hello

if you get back a Hello, it's all good to go. It implies: - Connecting to db was successful - The webserver is running

Another random one, since we're on a roll today: Is there a way to safely modify an

EmailPassword.init

property to hide signUp functionality? I have property for

palette

and the CSS

display:none

is fine, however the link is still available in the DOM. My goal: After validating against my database, I'm attempting to prevent outsiders from Signing Up. Sign in will ideally just validate with the db for user login. and I will manually create my users.

Or maybe it would make more sense to bypass default /auth theme and embed only login in a custom page

@User , there are two parts to removing sign up: - You would need to add some API key to the sign up API that is exposed via the node SDK. This is important since if you don't do this, in theory, someone can still make an account by manually calling this API (since it's open). The way you can do this is to add a middleware before

app.use(supertokens.middleware())

and check for an API key in the header if the route is

{apiBasePath}/signup

and the method is

POST

. Alternatively, you can disable the default sign up API entirely by setting the

disableDefaultImplementation

to

true

in the

signupFeature

object when calling the

init

function in the node SDK. But of course, you would still need to make an API to manually add users, so i'd go with the API key approach 🙂 - The second part of hiding the UI can be achieved by CSS manipulation by setting

headerSubtitle

to have

display: none

. I don't undertsand when you say "however the link is still available in the DOM."

The other way to change the login UI, (which is more complex, but more fullproof), is to create your own "theme". This can be done by: - Disabling the default UI for the sign in page by setting

disableDefaultImplementation

to

true

in

signInAndUpFeature

when calling the

init

function (see https://supertokens.io/docs/auth-react/emailpassword/init). This will basically remove the UI from

/auth

. This mean you can handle this route to render anything you like. - Then you would need to create your own component to show the login UI:

js
import {SignInAndUp} from "supertokens-auth-react/recipe/emailpassword";

render() {
  return (
    <SignInAndUp>
      <YOUR UI COMPONENT GOES HERE>
    </SignInAndUp>
  );
}

- The default UI component can be found here: https://github.com/supertokens/supertokens-auth-react/blob/master/lib/ts/recipe/emailpassword/components/themes/signInAndUp/index.tsx (for emailpassword recipe). So please feel free to copy this and modify its behaviour however you'd like!

What I meant by "still available in the DOM" is that using only CSS

display:none

, someone could still inspect the page, disable the

:none

value, and theoretically access the Sign Up link (

data-supertokens="headerSubtitle"

or

secondaryText

). I'll see what I can come up with using

disableDefaultImplementation

. Outstanding once again with the reply. I appreciate the help

@theefunklord if the custom theme method is complicated (since no examples or docs available), you could stick to the CSS method. If someone does end up changing the CSS manually, sure, they can access the sign up form, but it won’t work as the API will be disabled or they will need the key. So in that way, it is a good and easy solution 🙂