gofr-dev/gofr · error

regex pattern is not supported, use mux patterns instead

Error message

regex pattern is not supported, use mux patterns instead

What it means

errRegexIndicatorNotSupported is returned by checkRegexIndicators when regex syntax characters are used outside variable constraints in an RBAC endpoint pattern (e.g. '[0-9]' or '.*' embedded in a path but not as a declared regex-style variable). GoFr RBAC accepts mux patterns, and regex indicators inside plain path segments are invalid and rejected during validation.

Source

Thrown at pkg/gofr/rbac/config.go:34

	"gofr.dev/pkg/gofr/container"
	"gofr.dev/pkg/gofr/datasource"
)

var (
	// errUnsupportedFormat is returned when the config file format is not supported.
	errUnsupportedFormat = errors.New("unsupported config file format")

	// ErrEndpointMissingPermissions is returned when an endpoint doesn't specify requiredPermissions and is not public.
	ErrEndpointMissingPermissions = errors.New("endpoint must specify requiredPermissions (or be public)")

	// errWildcardPatternNotSupported is returned when a wildcard pattern is used.
	errWildcardPatternNotSupported = errors.New("wildcard pattern '/*' is not supported, use mux patterns instead")

	// errRegexPatternNotSupported is returned when an old regex pattern is used.
	errRegexPatternNotSupported = errors.New("regex pattern '^...$' is not supported, use mux patterns instead")

	// errRegexIndicatorNotSupported is returned when regex indicators are used outside variable constraints.
	errRegexIndicatorNotSupported = errors.New("regex pattern is not supported, use mux patterns instead")
)

// RoleDefinition defines a role with its permissions and inheritance.
// Pure config-based: only role->permission mapping is supported.
type RoleDefinition struct {
	// Name is the role name (required)
	Name string `json:"name" yaml:"name"`

	// Permissions is a list of permissions for this role (format: "resource:action")
	// Example: ["users:read", "users:write"]
	Permissions []string `json:"permissions,omitempty" yaml:"permissions,omitempty"`

	// InheritsFrom lists roles this role inherits permissions from
	// Example: ["viewer"] - editor inherits all viewer permissions
	InheritsFrom []string `json:"inheritsFrom,omitempty" yaml:"inheritsFrom,omitempty"`
}

// EndpointMapping defines authorization requirements for an API endpoint.

View on GitHub (pinned to 187eb24962)

Solutions

  1. Move the regex expression into the mux variable constraint syntax, e.g. '/files/{name:[a-z]+}/download' if constraints are supported, or drop it entirely.
  2. Simplify the pattern to plain path segments and mux variables.
  3. Validate constraints only where the mux supports them; elsewhere use literal paths.
  4. Run a pre-flight scan of your config for '[', ']', '*', '.' indicators before loading.

Example fix

// before
"/files/[a-z]+/download": {"GET": ["user"]}
// after
"/files/{name}/download": {"GET": ["user"]}
Defensive patterns

Strategy: validation

Validate before calling

var regexIndicators = regexp.MustCompile(`[\[\]\+\.\*]`)
func hasRegexIndicatorOutsideVar(pattern string) bool {
	// strip {var:constraint} segments, then check the rest
	clean := muxVarPattern.ReplaceAllString(pattern, "")
	return regexIndicators.MatchString(clean)
}

Try / catch

if err := checkRegexIndicators(pattern); err != nil {
	return fmt.Errorf("regex indicator in %q not allowed: %w", pattern, err)
}

Prevention

When it happens

Trigger: Writing paths like '/files/[a-z]+/download' or '/a.*b' in the RBAC config where the regex syntax appears in the path rather than inside a supported variable constraint; checkRegexIndicators detects it during LoadPermissions.

Common situations: Attempting inline regex filtering in RBAC route patterns; partially converting a regex config where anchors were removed but character classes kept; misunderstanding which positions allow regex constraints.

Related errors


AI-assisted analysis of gofr-dev/gofr@187eb24962 (2026-09-01). Data as JSON: /api/errors/505cc8185231e727. Report an issue: GitHub.