Any ETA for roles management and support for regions? Right now I see only 2 regions.

Roles management is sort of far away into the future (at least 6+ months). New regions can be added fairly quickly (takes us 2 days), as long as they are within AWS.

However, we will add new a new region only if we have a user who is ready to roll us into their production, and wants that region. So if you are still in dev, you can deploy your app in an existing region, and when you want to use us in prod, then you can tell us a few days before and we can start support for that region

@rp Snyk flagged axios <0.21.3 for a severe vulnerability. Not sure if that's relevant though. It's a dependency in supertokens-node.

Thanks! Will fix and release a new version

@User we have updated the axios dependency in the supertokens-node SDK. Thanks for the heads up 🙂

Hello. I am using ThirdpartyEmailPassword recipe. I have overridden the signin and signup functions. However, those functions only work for EmailPassword and not for Third-party ( google OAuth) . Can you help me in this ?

There should be another function called signinup which is used for social logins

Oh ok. That's a relief! Thanks 😀

Out of curiousity, is there a way to secure API endpoints by using a server to server login + session? Just started wading through (the really excellent, btw) documentation but have not seen a reciepe for that scenario, only for user login. Pure session assumes frontend already authenticated but how would you guys implement something similar to say Okta's OAuth? https://developer.okta.com/docs/guides/implement-oauth-for-okta/request-access-token/

So we don't provide Open ID tokens yet (coming soon though). What you get now is an access token and a refresh token for session management which allows your frontend to auth with your backend. The main use case of open ID tokens is to implement SSO where several apps can login a user via some common login portal. We don't have SSO either. machine to machine is not supported right now either.

Using our session recipe for server to server is not recommended cause the "client server" would need to synchronise all calls to the refresh endpoint - which adds complexity to the code + causes issues if the client server's infra is distributed. A simple alternative for this kind of interaction is to use an API key instead.

This is sort of a complicated topic with several gotchas.. i don't know if my explanation above suffices to answer your question. I am happy to get on a call to explain it 🙂

@rp Yeah, that makes all sense 👍 Right, in my case I have no need for SSO but machine to machine would be very useful at some point. I will definitely try supertokens for user auth and technically speaking at this point in the project, there is no need to auth the API server. There is nothing sensitive there for now, just pure web content. But planning ahead, the need will come. ^^ Is machine to machine part of your plan in the near future?

Yea. A LOT of people have asked for machine to machine.. so it surely will be.

But until we implement it, you can always use another solution, specifically for machine to machine

I will, but having all in the same shop, so to say, would be soooooo comfy 😌 And thank you so much for your prompt reply!!!! 🙂

I agree. Using one solution for everything is most convenient.

Your username is really interesting btw... hahaha

It's "my dog spies", just to clear any confusion 😅

oh yea.. got that. I found that funny and interesting

One of those crazy things... my dog always watches me... and I needed I nick for a project... so it become nick for it all, hahahah

Hahahahaha

https://supertokens.io/docs/contribute/module-architecture/core/overview //By concurrently safe, we mean that it is thread safe, as well as multi-process safe. This means that if an operation is not idempotent (like signing up a new user based on their email), doing that operation in parallel across different cores should have the same effect that these operations were instead run in a sequence. This in turn implies that we will have to use mutex locking with a core, or db transactions (with row level locking), or some concensus algorithm, or some distributed locking system. //

Yes. That is correct

My question is regarding the above... locking involves complex steps and prone to errors (dead locks sometimes), performance hits. My question is this... Architecturally, is it easier to consider the following? Keep one core instance as write instance (mainly for user creation/updates) and others as read?

Sorry, hit the enter button too early and I could not go back and edit.

Keeping only one core for write has the following implications: - Single point of failure - Difficult to scale out As a result, we decided to make all instances such that you can do any operation with them in any order. We use row level locking in SQL dbs + db constraints (like unique or primary key) - which prevent race conditions. Row level locking is mostly applied to operations that require a read -> update, whereas operations that require creation of a new row (like sign up a user), we rely on db constraint (like keeping the email column unique).

how do you install this via plesk/cpanel