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

We don’t currently support PHP

But you can integrate with our APIs directly if you’d like

theres a section for node based apps

as weell as docker

Yea. We do support Node. But isn’t cpanel in PHP?

i use plesk.. it has more features

Hey! I started some time ago the integration of supertokens and so far so good 👏 While there is still some work to do (I still have to integrate supertokens into our react-native app - nice timing btw 😄 - ), I wanted to know if you had a timeframe on the 2FA feature or a draft on how that will look?

We will have 2fa in a couple of months from now. We have already started working on it internally and should have an equivalent of a "RFC" in some time. What second factor are you considering using?

Ok, might be a little too long for us to wait, will see how to implement it (I still have your tips from a couple months ago). For now I think it will be a SMS or email based factor but once the feature is available on your side, I'd like to move to it to propose more factors

When you say more factors, do you mean that you want to offer a choice to your users on which type of second factor they should enable?

yes

Got it. And what would those options be? SMS OTP, email OTP, Authenticator app? Or something else?

That would be all. The other reason I would move to supertokens OTP once it's available is to have less thing to worry when it comes to security (using your solution instead of a custom one).

Makes sense

Can I not get the google user Image, with log in with Gooogle?

You can. You would have to: - modify the scopes array during the init call: https://supertokens.io/docs/thirdpartyemailpassword/common-customizations/signup-form/changing-oauth-scopes - the fetch the image via the response from the auth code exchange or then use google's access token to fetch the image. You can get these like this: https://supertokens.io/docs/thirdpartyemailpassword/common-customizations/signup-form/built-in-providers#get-the-third-party-providers-access-token

hey @rp is it possible to add fields on signUp form with email + password recipe? i tried the way its in thirdparty recipe but im getting no additional fields back to express even tho they do show up in signUp form

oh sorry, i should've posted in supertokens-questions, will move there

Which version of the node SDK are you using?

"supertokens-node": "^7.0.2"

Right. So you should be able to access the fields on your backend via the override feature. Have you done that? If yes, can I see the code?