8537805ea5
# Which Problems Are Solved The current handling of notification follows the same pattern as all other projections: Created events are handled sequentially (based on "position") by a handler. During the process, a lot of information is aggregated (user, texts, templates, ...). This leads to back pressure on the projection since the handling of events might take longer than the time before a new event (to be handled) is created. # How the Problems Are Solved - The current user notification handler creates separate notification events based on the user / session events. - These events contain all the present and required information including the userID. - These notification events get processed by notification workers, which gather the necessary information (recipient address, texts, templates) to send out these notifications. - If a notification fails, a retry event is created based on the current notification request including the current state of the user (this prevents race conditions, where a user is changed in the meantime and the notification already gets the new state). - The retry event will be handled after a backoff delay. This delay increases with every attempt. - If the configured amount of attempts is reached or the message expired (based on config), a cancel event is created, letting the workers know, the notification must no longer be handled. - In case of successful send, a sent event is created for the notification aggregate and the existing "sent" events for the user / session object is stored. - The following is added to the defaults.yaml to allow configuration of the notification workers: ```yaml Notifications: # The amount of workers processing the notification request events. # If set to 0, no notification request events will be handled. This can be useful when running in # multi binary / pod setup and allowing only certain executables to process the events. Workers: 1 # ZITADEL_NOTIFIACATIONS_WORKERS # The amount of events a single worker will process in a run. BulkLimit: 10 # ZITADEL_NOTIFIACATIONS_BULKLIMIT # Time interval between scheduled notifications for request events RequeueEvery: 2s # ZITADEL_NOTIFIACATIONS_REQUEUEEVERY # The amount of workers processing the notification retry events. # If set to 0, no notification retry events will be handled. This can be useful when running in # multi binary / pod setup and allowing only certain executables to process the events. RetryWorkers: 1 # ZITADEL_NOTIFIACATIONS_RETRYWORKERS # Time interval between scheduled notifications for retry events RetryRequeueEvery: 2s # ZITADEL_NOTIFIACATIONS_RETRYREQUEUEEVERY # Only instances are projected, for which at least a projection-relevant event exists within the timeframe # from HandleActiveInstances duration in the past until the projection's current time # If set to 0 (default), every instance is always considered active HandleActiveInstances: 0s # ZITADEL_NOTIFIACATIONS_HANDLEACTIVEINSTANCES # The maximum duration a transaction remains open # before it spots left folding additional events # and updates the table. TransactionDuration: 1m # ZITADEL_NOTIFIACATIONS_TRANSACTIONDURATION # Automatically cancel the notification after the amount of failed attempts MaxAttempts: 3 # ZITADEL_NOTIFIACATIONS_MAXATTEMPTS # Automatically cancel the notification if it cannot be handled within a specific time MaxTtl: 5m # ZITADEL_NOTIFIACATIONS_MAXTTL # Failed attempts are retried after a confogired delay (with exponential backoff). # Set a minimum and maximum delay and a factor for the backoff MinRetryDelay: 1s # ZITADEL_NOTIFIACATIONS_MINRETRYDELAY MaxRetryDelay: 20s # ZITADEL_NOTIFIACATIONS_MAXRETRYDELAY # Any factor below 1 will be set to 1 RetryDelayFactor: 1.5 # ZITADEL_NOTIFIACATIONS_RETRYDELAYFACTOR ``` # Additional Changes None # Additional Context - closes #8931 |
||
|---|---|---|
| .codecov | ||
| .devcontainer | ||
| .github | ||
| build | ||
| cmd | ||
| console | ||
| deploy/knative | ||
| docs | ||
| e2e | ||
| internal | ||
| load-test | ||
| openapi | ||
| pkg/grpc | ||
| proto | ||
| statik | ||
| .dockerignore | ||
| .gitattributes | ||
| .gitignore | ||
| .golangci.yaml | ||
| .releaserc.js | ||
| ADOPTERS.md | ||
| buf.gen.yaml | ||
| buf.work.yaml | ||
| changelog.config.js | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| go.mod | ||
| go.sum | ||
| LICENSE | ||
| main.go | ||
| Makefile | ||
| MEETING_SCHEDULE.md | ||
| README.md | ||
| release-channels.yaml | ||
| SECURITY.md | ||
| Community Meeting |
|---|
| ZITADEL holds bi-weekly community calls. To join the community calls or to watch previous meeting notes and recordings, please visit the meeting schedule. |
Are you searching for a user management tool that is quickly set up like Auth0 and open source like Keycloak?
Do you have a project that requires multi-tenant user management with self-service for your customers?
Look no further — ZITADEL is the identity infrastructure, simplified for you.
We provide you with a wide range of out-of-the-box features to accelerate your project, including:
✅ Multi-tenancy with team management
✅ Secure login
✅ Self-service
✅ OpenID Connect
✅ OAuth2.x
✅ SAML2
✅ LDAP
✅ Passkeys / FIDO2
✅ OTP
and an unlimited audit trail is there for you, ready to use.
With ZITADEL, you are assured of a robust and customizable turnkey solution for all your authentication and authorization needs.
🏡 Website 💬 Chat 📋 Docs 🧑💻 Blog 📞 Contact
Get started
Deploy ZITADEL (Self-Hosted)
Deploying ZITADEL locally takes less than 3 minutes. Go ahead and give it a try!
See all guides here
If you are interested to get professional support for your self-hosted ZITADEL please reach out to us!
Setup ZITADEL Cloud (SaaS)
If you want to experience a hands-free ZITADEL, you should use ZITADEL Cloud. Available data regions are:
- 🇺🇸 United States
- 🇪🇺 European Union
- 🇦🇺 Australia
- 🇨🇭 Switzerland
ZITADEL Cloud comes with a free tier, providing you with all the same features as the open-source version. Learn more about the pay-as-you-go pricing.
Adopters
We are grateful to the organizations and individuals who are using ZITADEL. If you are using ZITADEL, please consider adding your name to our Adopters list by submitting a pull request.
Example applications
Clone one of our example applications or deploy them directly to Vercel.
SDKs
Use our SDKs for your favorite language and framework.
Why choose ZITADEL
We built ZITADEL with a complex multi-tenancy architecture in mind and provide the best solution to handle B2B customers and partners. Yet it offers everything you need for a customer identity (CIAM) use case.
- API-first approach
- Multi-tenancy authentication and access management
- Strong audit trail thanks to event sourcing as storage pattern
- Actions to react on events with custom code and extended ZITADEL for you needs
- Branding for a uniform user experience across multiple organizations
- Self-service for end-users, business customers, and administrators
- CockroachDB or a Postgres database as reliable and widespread storage option
Features
Authentication
- Single Sign On (SSO)
- Passkeys support (FIDO2 / WebAuthN)
- Username / Password
- Multifactor authentication with OTP, U2F, Email OTP, SMS OTP
- LDAP
- External enterprise identity providers and social logins
- Device authorization
- OpenID Connect certified => OIDC Endpoints
- SAML 2.0 => SAML Endpoints
- Custom sessions if you need to go beyond OIDC or SAML
- Machine-to-machine with JWT profile, Personal Access Tokens (PAT), and Client Credentials
- Token exchange and impersonation
Multi-Tenancy
- Identity Brokering with templates for popular identity providers
- Customizable onboaring for B2B and their users
- Delegate role management to third-parties
- Domain discovery
Integration
- GRPC and REST APIs for every functionality and resource
- Actions to call any API, send webhooks, adjust workflows, or customize tokens
- Role Based Access Control (RBAC)
- Examples and SDKs
- Audit Log and SOC/SIEM
- User registration and onboarding
- Hosted and custom login user interface
Self-Service
- Self-registration including verification
- Self-service for end-users, business customers, and administrators
- Administration UI (Console)
Deployment
- Postgres (version >= 14) or CockroachDB (version latest stable)
- Zero Downtime Updates
- High scalability
Track upcoming features on our roadmap and follow our changelog for recent updates.
How To Contribute
Find details about how you can contribute in our Contribution Guide. Join our Discord Chat to get help.
Contributors
Made with contrib.rocks.
Showcase
Quick Start Guide
Secure a React Application using OpenID Connect Authorization Code with PKCE
Login with Passkeys
Use our login widget to allow easy and secure access to your applications and enjoy all the benefits of Passkeys (FIDO 2 / WebAuthN):
Admin Console
Use Console or our APIs to setup organizations, projects and applications.
Security
You can find our security policy here.
Technical Advisories are published regarding major issues with the ZITADEL platform that could potentially impact security or stability in production environments.
License
here are our exact licensing terms.
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See our license for detailed information governing permissions and limitations on use.