[GH-ISSUE #3589] Set active organization is broken in 1.3.2 and future versions #26979

Closed
opened 2026-04-17 17:44:59 -05:00 by GiteaMirror · 4 comments
Owner

Originally created by @iRoachie on GitHub (Jul 24, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/3589

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

Create a next js project and create an auth instance with the organization plugin.

Create an organization
Create a user
Add user to the organization

After logging in, attempt to set the active organization using authClient

await authClient.organization.setActive({
  organizationSlug: selectedOrganization,
});

Current vs. Expected behavior

The expected behaviour is that the organization specified should be set active.

The current behaviour is that /api/auth/organization/set-active returns 403

What version of Better Auth are you using?

1.3.2

Provide environment information

- Mac 15.5 (24F74)
- Edge 138.0.3351.95

Which area(s) are affected? (Select all that apply)

Backend, Client

Auth config (if applicable)


Additional context

Works in 1.3.1

Originally created by @iRoachie on GitHub (Jul 24, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/3589 ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce Create a next js project and create an auth instance with the organization plugin. Create an organization Create a user Add user to the organization After logging in, attempt to set the active organization using authClient ```ts await authClient.organization.setActive({ organizationSlug: selectedOrganization, }); ``` ### Current vs. Expected behavior The expected behaviour is that the organization specified should be set active. The current behaviour is that /api/auth/organization/set-active returns 403 ### What version of Better Auth are you using? 1.3.2 ### Provide environment information ```bash - Mac 15.5 (24F74) - Edge 138.0.3351.95 ``` ### Which area(s) are affected? (Select all that apply) Backend, Client ### Auth config (if applicable) ```typescript ``` ### Additional context Works in 1.3.1
GiteaMirror added the lockedbug labels 2026-04-17 17:44:59 -05:00
Author
Owner

@dosubot[bot] commented on GitHub (Jul 24, 2025):

Hi @iRoachie! I'm Dosu and I’m helping the better-auth team.

This is a confirmed regression in 1.3.2 and later. The cause is a new membership check: the backend now verifies that the user is a member of the organization before allowing it to be set as active. If the user is not recognized as a member (or if access policies are misconfigured), the endpoint returns a 403 error. This stricter check was introduced in PR #3497.

To restore expected behavior, double-check that the user is correctly added as a member of the organization and review any custom access policies in your Better Auth config. If your setup relies on custom org context management or non-standard flows, these new checks may block activation even if the user appears to be a member.

There are no documented workarounds or config changes in the official docs for this regression. If you confirm correct membership and still see 403s, the stricter policy in 1.3.2+ is likely the cause. For more technical details, see the discussion here.

To reply, just mention @dosu.


How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

<!-- gh-comment-id:3113985876 --> @dosubot[bot] commented on GitHub (Jul 24, 2025): <!-- Greeting --> Hi @iRoachie! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the better-auth team. <!-- Answer --> This is a confirmed regression in 1.3.2 and later. The cause is a new membership check: the backend now verifies that the user is a member of the organization before allowing it to be set as active. If the user is not recognized as a member (or if access policies are misconfigured), the endpoint returns a 403 error. This stricter check was introduced in [PR #3497](https://github.com/better-auth/better-auth/pull/3497). To restore expected behavior, double-check that the user is correctly added as a member of the organization and review any custom access policies in your Better Auth config. If your setup relies on custom org context management or non-standard flows, these new checks may block activation even if the user appears to be a member. There are no documented workarounds or config changes in the official docs for this regression. If you confirm correct membership and still see 403s, the stricter policy in 1.3.2+ is likely the cause. For more technical details, see the [discussion here](https://github.com/better-auth/better-auth/issues/3452). <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/14523ff5-3a60-44e7-bb48-85736847f65a?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/14523ff5-3a60-44e7-bb48-85736847f65a?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/14523ff5-3a60-44e7-bb48-85736847f65a?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/14523ff5-3a60-44e7-bb48-85736847f65a?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/14523ff5-3a60-44e7-bb48-85736847f65a?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/14523ff5-3a60-44e7-bb48-85736847f65a?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/14523ff5-3a60-44e7-bb48-85736847f65a?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/3589)
Author
Owner

@iRoachie commented on GitHub (Jul 24, 2025):

The user is a member. The list of organizations was returned using authClient.organization.listInvitations

The response from the organization.setActive is

{
    "code": "USER_IS_NOT_A_MEMBER_OF_THE_ORGANIZATION",
    "message": "User is not a member of the organization",
    "status": 403,
    "statusText": "FORBIDDEN"
}
<!-- gh-comment-id:3114080648 --> @iRoachie commented on GitHub (Jul 24, 2025): The user is a member. The list of organizations was returned using `authClient.organization.listInvitations` The response from the `organization.setActive` is ```json { "code": "USER_IS_NOT_A_MEMBER_OF_THE_ORGANIZATION", "message": "User is not a member of the organization", "status": 403, "statusText": "FORBIDDEN" } ```
Author
Owner

@iRoachie commented on GitHub (Jul 24, 2025):

I added some logs to the drizzleAdapter, and I found the issue.

The new code added in #3497 does not work when organizationSlug is used, only id.

2025-07-24T16:44:54.701Z INFO [Better Auth]: [Drizzle Adapter] #14 [1/3] findOne: {
  model: 'members',
  where: [
    {
      operator: 'eq',
      connector: 'AND',
      field: 'userId',
      value: 'FnbgGyhPnGjqNf0NNDnINUotPTmTQtUx'
    },
    {
      operator: 'eq',
      connector: 'AND',
      field: 'organizationId',
      value: 'FxnpLdiVJjq3TrtuhSWiWvg9MKZPF9EU'
    }
  ],
  select: undefined
}

Check attempts to use organizationId even when organizationSlug is passed in

<!-- gh-comment-id:3114158505 --> @iRoachie commented on GitHub (Jul 24, 2025): I added some logs to the drizzleAdapter, and I found the issue. The new code added in #3497 does not work when `organizationSlug` is used, only id. ``` 2025-07-24T16:44:54.701Z INFO [Better Auth]: [Drizzle Adapter] #14 [1/3] findOne: { model: 'members', where: [ { operator: 'eq', connector: 'AND', field: 'userId', value: 'FnbgGyhPnGjqNf0NNDnINUotPTmTQtUx' }, { operator: 'eq', connector: 'AND', field: 'organizationId', value: 'FxnpLdiVJjq3TrtuhSWiWvg9MKZPF9EU' } ], select: undefined } ``` Check attempts to use `organizationId` even when `organizationSlug` is passed in
Author
Owner

@Soluce-Technologies commented on GitHub (Jul 27, 2025):

I added some logs to the drizzleAdapter, and I found the issue.

The new code added in #3497 does not work when organizationSlug is used, only id.

2025-07-24T16:44:54.701Z INFO [Better Auth]: [Drizzle Adapter] #14 [1/3] findOne: {
  model: 'members',
  where: [
    {
      operator: 'eq',
      connector: 'AND',
      field: 'userId',
      value: 'FnbgGyhPnGjqNf0NNDnINUotPTmTQtUx'
    },
    {
      operator: 'eq',
      connector: 'AND',
      field: 'organizationId',
      value: 'FxnpLdiVJjq3TrtuhSWiWvg9MKZPF9EU'
    }
  ],
  select: undefined
}

Check attempts to use organizationId even when organizationSlug is passed in

Same error on my side, better auth try to compare with organization id when using the slug.

<!-- gh-comment-id:3124580498 --> @Soluce-Technologies commented on GitHub (Jul 27, 2025): > I added some logs to the drizzleAdapter, and I found the issue. > > The new code added in [#3497](https://github.com/better-auth/better-auth/pull/3497) does not work when `organizationSlug` is used, only id. > > ``` > 2025-07-24T16:44:54.701Z INFO [Better Auth]: [Drizzle Adapter] #14 [1/3] findOne: { > model: 'members', > where: [ > { > operator: 'eq', > connector: 'AND', > field: 'userId', > value: 'FnbgGyhPnGjqNf0NNDnINUotPTmTQtUx' > }, > { > operator: 'eq', > connector: 'AND', > field: 'organizationId', > value: 'FxnpLdiVJjq3TrtuhSWiWvg9MKZPF9EU' > } > ], > select: undefined > } > ``` > > Check attempts to use `organizationId` even when `organizationSlug` is passed in Same error on my side, better auth try to compare with organization id when using the slug.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#26979