raystack / raystack/frontier

GetOrganization returns 500 internal for a disabled org looked up by slug (200 by id)

Open
#1,798 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

authz bug
Dominant language
Go
Stars
344
Forks
47
Avg merge
4d 4h
Merged PRs (30d)
26

Description

Summary

FrontierService.GetOrganization returns 500 internal when you look up a disabled org by its slug (name). The same org returns 200 when you look it up by id. This is a user facing RPC (frontier.proto), so it should never answer a known, expected condition with an internal error.

Behavior today

Called as a platform superuser against a disabled org:

Lookup HTTP connect code body
disabled org by slug 500 internal {"code":"internal","message":"internal server error"}
disabled org by id 200 - returns the org (state: disabled)
enabled org by slug 200 - returns the org
unknown slug 404 not_found -
unknown uuid 403 permission_denied -

So the same disabled org gives 200 by id but 500 by slug. That is both a wrong status code and an inconsistency between the two ways to address the same org.

Why it matters

  • GetOrganization is on FrontierService and is user facing. A 500 internal tells clients "server bug" and is the wrong signal for a normal state (the org is disabled). Clients cannot handle it cleanly.
  • It leaks an internal error string path (handleAuthErr: org is disabled) instead of a typed, documented error.
  • It breaks slug based deep links for disabled orgs. The admin UI slug URL work (#1763) resolves the URL segment through GetOrganization. A disabled org opened by slug (refresh or bookmark) hits this 500 and the page cannot load.

Root cause

The RPC handler itself is fine. internal/api/v1beta1connect/organization.go GetOrganization calls orgService.GetRaw, which returns disabled orgs.

The 500 comes from the authorization step that runs before the handler:

  1. pkg/server/connect_interceptors/authorization.go maps GetOrganization to handler.IsAuthorized(Object{Namespace: organization, ID: req.GetId()}, GetPermission, req). req.GetId() is the raw URL segment, which can be a slug.
  2. internal/api/v1beta1connect/authorize.go IsAuthorized calls resourceService.CheckAuthz(...). Resolving the org by name rejects disabled orgs and returns organization.ErrDisabled. Resolving by id reads the graph directly and passes (disabled orgs stay authorized by id on purpose, per the Disable service comment in core/organization/service.go).
  3. handleAuthErr maps organization.ErrNotExist to CodeNotFound, but organization.ErrDisabled is not handled and falls through to the default branch, which returns CodeInternal.
// internal/api/v1beta1connect/authorize.go
func handleAuthErr(err error) error {
	switch {
	case errors.Is(err, user.ErrInvalidEmail) || errors.Is(err, errors.ErrUnauthenticated):
		return connect.NewError(connect.CodeUnauthenticated, ErrUnauthenticated)
	case errors.Is(err, organization.ErrNotExist),
		errors.Is(err, project.ErrNotExist),
		errors.Is(err, resource.ErrNotExist):
		return connect.NewError(connect.CodeNotFound, ErrNotFound)
	default: // organization.ErrDisabled lands here -> 500
		return connect.NewError(connect.CodeInternal, fmt.Errorf("handleAuthErr: %w", err))
	}
}

Expected behavior

No 500 for this case. Pick one, consistently for both id and slug:

  1. Preferred: let the authz name lookup treat disabled orgs the same as the id path, so GetOrganization returns the disabled org for both id and slug. This matches the admin use case (a superuser can already read a disabled org by id) and removes the slug vs id split.
  2. If reading a disabled org through this endpoint should be blocked, return a typed client error (for example failed_precondition "org is disabled" or not_found) for both id and slug, and stop returning the org by id too. Today the two paths disagree.

At minimum, handleAuthErr should recognize organization.ErrDisabled and map it to a proper client code instead of CodeInternal, so the endpoint never returns a 500 for a disabled org.

Steps to reproduce

  1. Create an org, then disable it (DisableOrganization).
  2. Call GetOrganization with {"id": "<slug>"} as a superuser. Returns 500 internal.
  3. Call GetOrganization with {"id": "<uuid>"} for the same org. Returns 200 with state: disabled.

Related

Same pattern of user facing endpoints returning 500 instead of a proper client code: #1693, #1697.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with internal/api/v1beta1connect/authorize.go and pkg/server/connect_interceptors/authorization.go, then compare organization name and ID resolution in core/organization/service.go. Reproduce GetOrganization for a disabled organization by slug and ID, and make the endpoint return a consistent non-internal result for both paths without breaking the documented disabled-organization behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
api, authorization, backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
64/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.