https://supertokens.com/ logo
Join Discord
Powered by
Hi Supertokens Team, I hope this message finds yo...
# support-questions-legacy
t
Hi Supertokens Team, I hope this message finds you well. I am currently working on integrating Supertokens into my application, which consists of Vue.js on the frontend and Nest.js on the backend. Initially, I successfully implemented the Supertokens login functionality using the SaaS version, and everything worked smoothly. To facilitate local development, I decided to switch to the Docker version of Supertokens by setting up a local instance and updating the connectionUrl accordingly. After successfully completing the setup, including table creation, both the Supertokens core and database containers appear to be running correctly on my local environment. However, upon switching the backend's connectionUri to the local URL, I encountered an issue. The login form displays as expected, and I can successfully log in with Google authentication. However, instead of being redirected to the application's homepage, the Supertokens session refresh logs continuously appear, causing an infinite loop. When I revert the connectionUri to the SaaS version, everything functions correctly. I've attached a portion of the logs generated endlessly on the frontend for your reference. Could you please provide guidance on what might be causing this issue? Any insights or suggestions would be greatly appreciated.
supertokens
r
Hey @t10o_25646
This is an interesting issue
So the only change you made is the connection uri value? And nothing else?
t
Thank you for your prompt response. I wanted to provide additional information that might be relevant to the issue. While the SaaS version of Supertokens was operating with multi-tenancy in mind, I came across information stating that the Docker version does not enable multi-tenancy by default. Consequently, I have excluded options related to multi-tenancy based on this explanation.
this config is for SaaS:
Copy code
const SuperTokensConfig = {
    enableDebugLogs: true,
    appInfo,
    usesDynamicLoginMethods: true,
    recipeList: [
      Multitenancy.init({
        override: {
          functions: originalImplementation => {
            return {
              ...originalImplementation,
              // eslint-disable-next-line @typescript-eslint/no-unused-vars
              getTenantId: input => {
                const tid = localStorage.getItem('acomo.authTenantId')
                return tid === null ? undefined : tid
              },
            }
          },
        },
      }),
      ThirdPartyEmailPassword.init({
        useShadowDom: false,
        signInAndUpFeature: {
          providers: [Github.init(), Google.init(), Apple.init(), Twitter.init()],
        },
      }),
      Session.init(),
    ],
  }
this is for local Docker:
Copy code
const SuperTokensConfig = {
    enableDebugLogs: true,
    appInfo,
    // usesDynamicLoginMethods: true,
    recipeList: [
      // Multitenancy.init({
      //   override: {
      //     functions: originalImplementation => {
      //       return {
      //         ...originalImplementation,
      //         // eslint-disable-next-line @typescript-eslint/no-unused-vars
      //         getTenantId: input => {
      //           const tid = localStorage.getItem('acomo.authTenantId')
      //           return tid === null ? undefined : tid
      //         },
      //       }
      //     },
      //   },
      // }),
      ThirdPartyEmailPassword.init({
        useShadowDom: false,
        signInAndUpFeature: {
          providers: [Github.init(), Google.init(), Apple.init(), Twitter.init()],
        },
      }),
      Session.init(),
    ],
  }
r
Can you send the HAR file that has the infinite session refreshing?
t
Here is the HAR file. Please let me know if there are any issues.
r
Thanks. Seeing
t
By the way, whether there are comments related to multi-tenancy or not, it works correctly when connecting to the SaaS version.
r
i will need more of the debug logs that are on the console.
can you send them all?
t
I've re-captured the logs from logging into the application's login form to the point where Google authentication occurs and infinite refresh happens.
r
har files don't show the console logs
so you will have to copy / paste it manually
t
How about this?
r
is there an issue with any time setting somewhere? For example, the local core may be getting a bad time due to some system setting?
the frontend keeps on refreshing cause the access token it gets is always expired
and the access token is created in the core. So if the core has some weird time issue, then this can happen
if you see an example access token payload that the frontend gets, the issued at time is 
1707919883
(seconds since epoch), which is yesterday.
t
Thank you! The time synchronization on my WSL was messed up. After synchronizing the time and restarting, everything worked well!
r
great!
PreviousNext
Powered by