Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues when api-domain and auth-domain are on different ports #55

Open
djuelg opened this issue Apr 16, 2024 · 2 comments
Open

Issues when api-domain and auth-domain are on different ports #55

djuelg opened this issue Apr 16, 2024 · 2 comments

Comments

@djuelg
Copy link

djuelg commented Apr 16, 2024

You provide the possibility to have different backends for the api-endpoints and auth-endpoints, by configuring sessionTokenBackendDomain. In our environment the two systems run on the same domain, but on different ports.

When you try to authenticate your Dio api-requests via SuperTokensInterceptorWrapper, the method shouldRunDioInterceptor will return false, when the ports differ, leaving the requests unauthenticated. The causing code is:

    if (SuperTokensUtils.getApiDomain(options.uri.toString()) !=
        SuperTokens.config.apiDomain) {
      return false;
    }

In my example the two values would evaluate to:

  • SuperTokensUtils.getApiDomain(options.uri.toString()) -> https://example.com:65000/ (which is the api-backend)
  • SuperTokens.config.apiDomain) -> https://example.com:3000/ (which is the auth-backend)

Using the following config:

    SuperTokens.init(
        apiDomain: 'https://example.com:3000/',
        sessionTokenBackendDomain: '.example.com/');

This issue prevents the sessionTokenBackendDomain from being evaluated. Wouldn't it be sufficient to rely on the following check only?

    if (!Utils.shouldDoInterceptions(
        options.uri.toString(),
        SuperTokens.config.apiDomain,
        SuperTokens.config.sessionTokenBackendDomain)) {
      return false;
    }
@rishabhpoddar
Copy link
Contributor

I see. The issue is that our implementation does not take into account different ports. You have two options:

  • When making a request to your application domain, you can fetch the access token using this function, and then add this as an authorization bearer token to your request. Our SDK auto refreshes the token if needed before returning one to you.
  • You can make a PR to our SDK which allows users to set their own implementation of shouldDoInterceptions via a config prop which will be used instead of our default implementation.

@djuelg
Copy link
Author

djuelg commented Apr 17, 2024

For the moment I just extended from SuperTokensInterceptorWrapper to override shouldRunDioInterceptor. But when I find the time, I'll look into creating a PR :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants