How to disable "Initialize User" email?
Hello, I am migrating users from another system (Firebase Auth), and since Zitadel does not support the their modified scrypt algorithm, I have to set
passwordChangeRequired = true for email+password users when I call Create/Import User.
What I didn't know that this API would send an email to those users. This is awkward because
- The Zitadel-based system is still in testing phase
- Our email provider flags email addresses as spam if too many emails are sent within short period of time
How can I disable the default behavior of sending "Initialize User" email? Is my only option (for now) to disable all email providers in Zitadel before migration?ZITADEL Docs
Create/import a new user with the type human. The newly created user will get an initialization email if either the email address is not marked as verified or no password is set. If a password is set the user will not be requested to set a new one on the first login.
18 Replies
Unknown Userā¢13mo ago
Message Not Public
Sign In & Join Server To View
The user who received the Initialize User email had
isEmailVerified set to true and passwordChangeRequired to true
I didn't set any initial password, because that seems unnecessary, especially since I don't want to send any email in the first placecurrently zitadel requires to initialize the user, a user counts as initialized when a password is set and the email is verified. we are about to change that with the user v2 api. the console ui at the moment still uses the v1 api
so the email will not be sent if you put an initial password and email verified true
But does the user have to know the initial password?
I'm back to trying to import users. What I need is a programmatic solution where:
- I don't have to set passwords that they would have to know
- No emails get sent, unless they try to log into their uninitialized accounts
Is this possible with Zitadel cleanly? If not, is there a hacky way, such as removing the SMTP credentials before importing the users and then setting them back?
We have designed a solution for this, we call it invite user link, with that we will implement the possiblity so you can decide when to send out a link to a user: https://github.com/zitadel/zitadel/issues/8310
GitHub
Invite User Link Ā· Issue #8310 Ā· zitadel/zitadel
As an administrator I want to be able to invite users to my application with the API V2, some user data I will already prefill, the user should add the authentication method itself (password, passk...
however at the moment I do see another solution for your problem, if you use our new user service, you can create a user and tell zitadel that you want to get the code as response instead of sending it as an email.
still in the background we do create the code, but it will not be sent to the user, we designed that, so our customers are able to send their emails themself and include the code there
ZITADEL Docs
Create/import a new user with the type human. The newly created user will get a verification email if either the email address is not marked as verified and you did not request the verification to be returned.
make sure to not include the sendCode attribute in the body, and only an empy returnCode: {}
Okay, thanks. It also seems that I should make sure email.isVerified is not present, or the call will fail
The small little awkward thing with this solution/workaround is that once the user tries to log in, the login screen tells them that a confirmation email has been sent, which is not true. They will waste time searching for the email and possibly conclude that the system doesn't work.
Fortunately, at least the more discerning users will spot the
Resend code buttonYes thats the case, and feels weired to the users
what i currently do not understand is, you said you are in a testing phase and you don't want the users to get the emails right? so whats your goal, how they will be able to login later on? do you migrate the passwords?
No, I'm not sending them any email, I don't set any passwords. They just log in , and Zitadel asks them to change passwords
ok
I can't migrate passwords, because I am migrating from Firebase Auth which uses a propietary hashing algorithm (I think it was a modified version of scrypt) tha Zitadel does not support
Implementations of their scrypt are available in case Zitadel wants (and has the resources) to make it easier to migrate from Firebase Auth one day
would it be an option for you to implement a just in time migration? https://zitadel.com/docs/guides/migrate/introduction#just-in-time-migration
ZITADEL Docs
This section of guides shows you how to migrate from your current auth system to ZITADEL.
While it might have solved some problems, it would have been iffy, because our clients are mostly in the public sector, and to them keeping the data in Firebase Auth is a No-No, because the authentication data is stored outside EU. We have to be able to say that we don't use it
Ok, so for me the best would feel to wait for the "invite user" issue, its something we want to implement rather soon than late, but i can't give you a concrete eta yet
I don't think I can wait at this point. I'll just use the current workaround.
If/when there are still uninitialized users by the time the feature has been released, I can just use the Invite User feature to set things right, correct? (As long as the users would not be stuck in some kind of awkward state where they are expecting both the code and the invitation)
āā
Anyway, thank's a lot for the help. This workaround seems reasonable / tolerable for now š
Ok great that you can take the workaround, yes for newly created users it should not be a problem to just take the invite user later on