question: Is there a way to match user by github user id?

[luk1337]

In /whoami I can see that there's a github user id in .metadata.id, is there a way to match it in Caddyfile transform user {}?

[greenpau]

@luk1337 , have you used the codex skills in this repo to answer your question yet?

[luk1337]

@luk1337 , have you used the codex skills in this repo to answer your question yet?

no, I did however try to come up with some working configuration with free chatgpt / claude few weeks ago and neither of them suggested anything that worked.

[luk1337]

@luk1337 , have you used the codex skills in this repo to answer your question yet?

no, I did however try to come up with some working configuration with free chatgpt / claude few weeks ago and neither of them suggested anything that worked.

I asked codex just now and it basically said i'm sol if I want to match on uid instead of login:

What I verified using the repo skill guidance:

The transform parser treats matcher lines specially and rewrites bare match to exact match, see caddyfile_authn_transform.go:36 and caddyfile_authn_transform.go:44.
The repo skill explicitly calls out that field exists conditions are not usable in transform user today, see SKILL.md:57 and SKILL.md:60.
From authcrunch behavior (v1.1.39 used by this repo):

GitHub numeric user id is stored under metadata.id in the user data map.
ACL matching in transforms looks up top-level keys by exact key name, not nested dot traversal.
So a transform matcher cannot reliably do “match metadata.id …” in current behavior.
Practical workaround:

Match on fields that are top-level and supported, usually sub, email, origin, or roles.
For GitHub specifically, sub is typically github.com/, so you can match that instead if login-based matching is acceptable.
If you want numeric GitHub ID matching specifically, it would require an upstream change in go-authcrunch/caddy-security (for example exposing metadata.id as a top-level claim before matcher evaluation, or adding nested-field matcher support).

[greenpau]

@luk1337 , the answer Codex gave you is correct.

If you want numeric GitHub ID matching specifically, it would require an upstream change in go-authcrunch/caddy-security (for example exposing metadata.id as a top-level claim before matcher evaluation, or adding nested-field matcher support).

That's probably the route.

[greenpau]

@luk1337 , currently , I am busy with "work" stuff. Might get to it sometime this summer. Currently the matcher is written in such a way that allows me to not use reflect package at all. Modifying the matcher requires some thought, because that's the core of a lot of things in go-authcrunch.

[greenpau]

Side note. I asked whether I can match it based on picture field and it was spot on too.

I read [issue #499](#499). The user wants to match GitHub’s numeric user id from /whoami at metadata.id inside transform user {}.

The picture idea is plausible because GitHub sets it as a top-level string like:

"picture": "https://avatars.githubusercontent.com/u/3826416?v=4"

and that URL embeds the numeric GitHub user id in /u/<id>.

Current state:

• GitHub OAuth fills both fields in ../go-authcrunch/pkg/idp/oauth/user.go: picture from avatar_url, metadata.id from id.
• transform user just forwards matcher strings in caddyfile_authn_transform.go.
• Actual matcher support is in authcrunch ACL. picture is not registered in the ACL field type map at ../go-authcrunch/pkg/acl/condition.go, so regex match picture ... is not usable today.
• picture is parsed into User claims and AsMap() via ../go-authcrunch/pkg/user/user.go, and header injection already supports it through GetClaimValueByField, as shown by caddyfile_authz_test.go.

Best place to enable it for matching:

1. Add picture: dataTypeStr to inputDataTypes in go-authcrunch/pkg/acl/condition.go.
2. For authorization ACL matching too, update unpackPicture to also populate tkv["picture"]; authz uses usr.GetData() in ../go-authcrunch/pkg/authz/validator/validator.go.
3. Then this kind of transform could work:

transform user {
    match origin https://api.github.com/user
    regex match picture ^https://avatars\.githubusercontent\.com/u/3826416(\?|$)
    action add role authp/admin
}

I’d treat this as a workaround, not the clean model. Matching metadata.id directly or promoting a stable top-level provider_user_id/github_id would be more robust than depending on GitHub avatar URL shape.