[Docs]: Confusion regarding the SUPERTOKENS_* env variables in generated code about redwood HOT 10 CLOSED

SUPERTOKENS_WEBSITE_DOMAIN - this has to be set to the url of the web side when deployed? eg https://www.myapp.com

That is correct.

SUPERTOKENS_API_DOMAIN - does it have to be set to the api side url?

Yes.

And why does it default to websiteDomain?

Cause in the local deployment of redwood, the website domain and api domain are both on localhost:8910. The api has a path of .redwood/functions as far as i remember. This means that the auth apis for sign in etc, are exposed on .redwood/functions/auth/signin, where the gateway path is .redwood/functions/ and the auth related apis are further scoped by /auth (known as apiBasePath)

What exactly is SUPERTOKENS_API_GATEWAY_PATH, and why does it default to /.redwood/functions?

You can read more about this here.

Can it be set to the api url

Nope. The config for api url is called SUPERTOKENS_API_DOMAIN

At least in dev mode, setting SUPERTOKENS_API_DOMAIN to http://localhost:8911 results in CORS issues when trying to use Supertokens. Does it mean that the value has to be entirely omitted?

Can you share the cors error? This is unexpected.

Not setting the env var results in an exception getting thrown on the api side

If you are using our managed service, there is an api key, but if you use a self hosted route, then there is no API key (by default). Either way, I think it makes sense to add a new env var SUPERTOKENS_API_KEY which can be "" by default (works for self hosted with no api key configured).

from redwood.

At least in dev mode, setting SUPERTOKENS_API_DOMAIN to http://localhost:8911 results in CORS issues when trying to use Supertokens. Does it mean that the value has to be entirely omitted?

So far it seems that the only values thave to be be set are SUPERTOKENS_WEBSITE_DOMAIN, SUPERTOKENS_JWKS_URL and SUPERTOKENS_CONNECTION_URI

from redwood.

And it also seems that we have to set SUPERTOKENS_API_KEY, which is missing from the generated code (and the docs):

supertokens: {
    connectionURI: env.SUPERTOKENS_CONNECTION_URI,
    apiKey: env.SUPERTOKENS_API_KEY, # !!!
  },

Not setting the env var results in an exception getting thrown on the api side.

from redwood.

Hi @suzdalnitski - it looks like SuperTokens may have changed their implementation and the setup commands are not up to date and the Redwood setup guide they had as part of the docs is no longer present.

Edit: note the implementation hasn’t changed - just need to clarify the config.

I'll have to reconnect with their team and see what needs to be done to support the Node backend and React front end apis now offered.

from redwood.

I think it makes sense to add a new env var SUPERTOKENS_API_KEY which can be "" by default (works for self hosted with no api key configured).

Ah that’s a good idea. Thanks!

from redwood.

At least in dev mode, setting SUPERTOKENS_API_DOMAIN to http://localhost:8911 results in CORS issues when trying to use Supertokens. Does it mean that the value has to be entirely omitted?

Can you share the cors error? This is unexpected.

Not setting the env var results in an exception getting thrown on the api side

Access to fetch at 'http://localhost:8911/.redwood/functions/auth/authorisationurl?thirdPartyId=google&redirectURIOnProviderDashboard=http%3A%2F%2Flocalhost%3A8910%2Fauth%2Fcallback%2Fgoogle' from origin 'http://localhost:8910' 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.

This goes away if SUPERTOKENS_API_DOMAIN=http://localhost:8910.

Looking at this one more time, it seems that the url isn't entirely correct - http://localhost:8911/.redwood/functions/auth should probably be http://localhost:8911/auth?

I think this default may be the reason for that:

const apiGatewayPath =  process.env.SUPERTOKENS_API_GATEWAY_PATH || '/.redwood/functions'

from redwood.

And why does it default to websiteDomain?

Cause in the local deployment of redwood, the website domain and api domain are both on localhost:8910. The api has a path of .redwood/functions as far as i remember.

If I'm not mistaken, it is both http://localhost:8911 and http://localhost:8910/.redwood/functions (the framework internally rewrites calls to .redwood/functions to the API side which runs on :8911). But I may be wrong since I'm not too familiar with the internals of Redwood.

from redwood.

I was able to get it all working locally/in prod, and updated the docs/templates with my learnings: https://github.com/redwoodjs/redwood/pull/9757/files

from redwood.

Thanks @suzdalnitski !

Looking at this one more time, it seems that the url isn't entirely correct - http://localhost:8911/.redwood/functions/auth should probably be http://localhost:8911/auth?

At the time of integration, the edge functions would run on /.redwood/functions/*. However, I'm not sure how this might have changed now. But the point is, the apiGatewayPath + apiBasePath should point to the API layer in which the supertokens middleware resides.

from redwood.

Docs provided by #9757 help clarify the SuperTokens setup.

from redwood.