. It contains a rough estimate of when we expect to start and release new projects. Although it's not guaranteed, it's a good glimpse into how we expect the weeks, months, and quarters ahead to unfold.

Out with the old, in with the new! We were nearing capacity for some of our infrastructure and needed to upgrade.

The upgrades successfully deployed with zero downtime!

Over the weekend, we detected an unusual spike in bot activity associated with SMS verifications. We worked with Twilio to determine that this attack was 

 - where attackers are able to steal money by receiving SMS messages.

We've upgraded our systems to detect and put a stop to the suspicious behavior. Though this attack did not manifest in downtime or security issues, the impacted customers were notified and will not be charged for SMS overruns.

Changelog May 27, 2022

 components. But since launching our B2B SaaS Suite for onboarding business customers, our top feature request has become better 

 capabilities: not just helping developers determine 

 a user is, but also what permissions they have within their organization.

Today we’ve launched two new features to make robust authorization easy:

In Clerk’s dashboard, developers can now define custom roles, which their business customers can assign to their employees. Previously, roles were restricted to just “admin” and “member.”

In addition, fine-grained permissions can now be defined and mapped to roles. When used properly, this extra layer of abstraction allows developers to create additional roles as-needed, without making any changes to their codebase.

Each role and permission defined in Clerk’s dashboard has a corresponding key, like 

To make it easy to leverage permissions for authorization checks, we’ve introduced three new helpers in our SDKs.

 function on both the frontend and the backend to determine if the active user “has” a particular role or permission.

 can be used anywhere that Clerk returns an “auth” object:

 in client components, including during SSR

 in server contexts outside of the App Router (Remix Loaders, Node, Express, Fastify, etc)

, which takes definitive action to block further processing, instead of allowing developers to manually handle the unauthorized case. It is intended to be used in cases where unauthorized users are assumed to be attackers.

Consider an endpoint that your product would never issue a request to unless the current user is authorized. For example, you may have a page with a button that can issue requests to that endpoint, but the page is only accessible to authorized users. That is the perfect place to use 

 – you don't need a precisely-written error, just confidence that an attacker's requests will fail.

 has launched in Next.js only, though we will extend the helper to other frameworks in the future. Please use 

 to request the feature for your framework.

 component is intended to block further processing. It only renders children for authorized users, and optionally renders a 

 can be used across all React frameworks, in CSR, SSR, and RSC contexts.

For full details and usage information, please see our updated Organization documentation, including:

Authorization is now a core feature of Clerk

With today’s launch, authorization has become a core feature of Clerk, and you will see significant, continued investment in the future.

In 2024, we will extend our authorization helpers to support entitlements, so Clerk can be used to gate features based on the subscription plan a customer selected.

Further, you likely noticed above that every role and permission is namespaced with the 

 prefix, which relates to the Organization resource. We recognize this is limiting, and in the future we will be extending our authorization helpers to work with other resources.

Introducing has(), protect(), and <Protect>

Clerk’s components were created with you in mind. Components do most of the functional work for you, allowing you to get your auth flows working in minutes, and support customization to fit your app’s style. That said, sometimes a component like the 

 doesn’t suit the needs of your application. The good news? Clerk provides hooks and functions that make building your custom UI components easy. Let’s take a quick look at how to create your custom user menu.

The hardest part of building a custom user menu is often the dropdown menu itself. You need the button to trigger the menu opening, a way to close it, a way to track open/closed states, a way to handle ‘click off’ to close, logic to close if the user hits the 

 button, a way to handle keyboard input, and the list goes on. We’re going to save ourselves some time and use a great library while doing so. Radix provides world-class, accessible, unstyled 

 that you can use to quickly and efficiently build your UI. Let’s start by installing the primitive we need — the dropdown menu.

Once the installation finishes, let’s create the scaffolding for our new component. The following will be the foundation of the menu. The trigger will hold the User button that will open the menu, and each item will hold one of the menu entries. Remember that Radix Primitives are unstyled and there is no content so this will be blank.

The first content we will add is the User button. This will show that the user is logged in, and will be the trigger to open the menu. For the sake of this post we will assume that you have marked email as required in the Clerk Dashboard, in the 

User & Authentication → Email, Password, Username → Email

 section to ensure every user has an email. You could change this to a first name or username easily enough. Just make sure that whatever option you choose is something that will exist for all users, for the sake of rendering. You could also conditionally render different information depending on what the user has provided — show the first name if available; if not, show the email.

To build the button we will leverage the 

 hook. This gives us access to information about the user, such as profile image, email, name, and more. We will also make sure that Clerk and the user have loaded, and that there is valid user data, before rendering the User button.

Add the Sign-Out and Manage Account Buttons

With the User button in place, we can now add Sign Out and Manage Account buttons. The 

 hook provides the two methods we will need for this — the 

 method. The User Profile will open as a modal. You could, instead, mount the 

 component to its own route, and then link it to the route. For the Sign Out button, we will also need to use the Next.js router to handle the redirect.

The custom button has now replicated the behavior of the 

, though it is very much still unstyled. We’re going to do one more thing — add one more menu entry to mimic expanding the menu. This will use the 

 component from Next.js to link to a fictional 

Your new component is almost ready — it just needs some styling. Let’s add a little bit to get started. The code below is ready to drop right into your app, and then you can import the new 

Explore the Powerful Customization Options Clerk Offers!

 documentation to explore more ways to customize your application using the many hooks and methods Clerks provides.

For more in-depth technical inquiries or to engage with our community, feel free to 

. Stay in the loop with the latest Clerk features, enhancements, and sneak peeks by following our Twitter/X account, 

. Your journey to seamless user management starts here!

Need help?

Company

Company

Changelog May 27, 2022

Public Roadmap

Resilience upgrades

Bot detection upgrades

Start now,
no strings attached

Pricing built for
businesses of all sizes.

Newsletter!

Company

Company

Changelog May 27, 2022

Resilience upgrades

Bot detection upgrades

Start now,no strings attached

Pricing built for.css-qa8l2m{color:var(--chakra-colors-primary-500);}businesses of all sizes.

Newsletter!

Start now,
no strings attached

Pricing built for
businesses of all sizes.