User authentication issue since the v-api v0.4.x upgrade

[notpeter]

Multiple users have reported issues logging into https://rfd.share.oxide.computer on the web since the v-api v0.4.x update in:

• Migrate to v-api v0.4 #484

I have not yet been able to reproduce and am personally able to authenticate via Google OAuth and via GitHub OAuth on the web and via CLI.

Two issues identified:

• Users with old cookies were seeing 404s (even on public RFDs) with no ability to logout
• Users associated with mappers including rfd-specific pemissions grants would fail when they attempted to login

Incident timeline (times ET)

2026-07-20 15:15 Deployment of rfd-api v0.15.0 (initial break)
2026-07-20 17:20 Augustus mentions in chat users may need to logout/login to access RFD site
2026-07-20 17:49 Iliana reports seeing 'Invalid or missing OAuth state parameter' error
2026-07-21 00:00 Augustus suggests it may be stale cookies
2026-07-21 00:02 Iliana confirmed cookie clearing worked
2026-07-23 19:10 Peter ping'd via chat noting external users having ongoing issues
2026-07-23 20:55 Peter pushes rfd-site fix for stale cookies in oxidecomputer/rfd-site#228
2026-07-23 21:16 Augustus posts PR with permissions implies #493
2026-07-23 21:18 External user reports logout was successful, but subsequent login failing
2026-07-23 22:09 Peter posts identical PR with permissions implies #494 (hadn't noticed Augustus' earlier PR)
2026-07-23 22:15 Peter decides to take no make no further deployments due to lateness
2026-07-23 22:45 Peter does db cleanup of adjacent (unrelated) mappers https://github.com/oxidecomputer/infra/issues/78
2026-07-23 23:50 Peter posts PR with improved logging of mapper failures oxidecomputer/v-api#511
2026-07-24 09:40 Deployment of rfd-api v0.15.3 with #494 (implies fix) and oxidecomputer/v-api#511 (improved logging)

cli changes

Unrelated, but adjacent -- rfd-cli auth commands have changed:
Old: rfd-cli auth login github and rfd-cli auth login google
New: rfd-cli auth login oauth github and rfd-cli auth login oauth google

Note

This is a public issue, please refrain from posting any user/customer specific details here.

[augustuswm]

There are a few issues related to this.

1. v-api has never correctly cleared out state cookies when a OAuth exchange ended early or failed. It happened to work because it would overwrite the existing cookie on a new flow. In v0.4 we changed the properties of the cookie (but not the name), this lead to potentially multiple cookies with the same name but different properties. v-api only ever reads the first cookie head it finds from the list of cookie headers sent in the request. Additional paths for cookie handling v-api#510 has a fixed for both of these. It clears out known potential stale paths, adds cookie clearing to the failure path, and reads all cookies with the expected name when searching for a matching state value.
2. v-api v0.4 introduced the implication attribute for permissions. I believed that this was a backwards compatible change, but I was incorrect. I am not sure if this is related to failing to find records, but it certainly causes failures in group, mapper, and other permission assignment operations.

Apologies for shipping this in such a broken state.

[notpeter]

So oxidecomputer/rfd-site#228 fixed the issue with users with logged in users with stale cookies getting 404s (even for public RFDs) and being unable to logout. Rfd-site now deletes session cookies when getting 401 Unauthorized (as you do with an invalid session). Those users can then again browse public RFDs as logged out users. Some of those users will be able to log back in without issue.

But certain users associated with a mapper that has concrete permission grants like GetRfd(123) are still unable to login. Although the server runs with GetRfdsAll, vapi 0.4 requires callers to have permissions they are granting. Currently that is all variants of the RfdPermissions enum via the with_additional_builtin_permissions call here:

rfd-api/rfd-api/src/main.rs

Lines 218 to 223 in cf742fc

	let mut v_ctx_builder = VContextBuilder::<RfdPermission>::new()
	.with_public_url(config.public_url.clone())
	.with_storage(storage.clone())
	.with_jwt_expiration(config.jwt.default_expiration)
	.with_keys(std::mem::take(&mut config.keys))
	.with_additional_builtin_permissions(RfdPermission::iter().collect());

But that does not cover GetRfd(123). We could do an ugly hack like adding GetRfds((0..=9999).collect()) to that list of additional permissions, but instead we define that GetRfdsAll implies GetRfd which applies no matter the associated integer data of GetRfd:

rfd-api/rfd-api/src/permissions.rs

Lines 31 to 37 in 8c4f5fe

	#[v_api(
	implies(variant = GetRfd),
	implies(variant = GetRfds),
	implies(variant = GetRfdsAssigned),
	scope(to = "rfd:content:r", from = "rfd:content:r")
	)]
	GetRfdsAll,

• See: Make permissions implies explicit #494

Mappers that used GetRfdsAll instead of GetRfd(N) grants (like the oxide employee mapper) were unaffected -- service has the same GetRfdsAll permission it's granting. But mappers that provided scoped access to certain RFDs: GetRfd(123) are failing to execute, preventing users from logging in.

[notpeter]

Deployment of v0.15.3 at ~09:40AM ET seems to have resolved the issue.

[izuzak]

👋 @notpeter Hello! I just noticed being unable to sign into the RFD site. Not sure exactly when it broke for me, but it doesn't work today and I believe it did work a week or so ago.

In any case, it doesn't seem to work in latest Chrome and latest Safari, including a fresh/incognito window in Chrome and after clearing cookies in Safari.

Here's what I see (happy to share the http requests/responses from the browser devtools if that helps):

[izuzak]

I just noticed being unable to sign into the RFD site. Not sure exactly when it broke for me, but it doesn't work today and I believe it did work a week or so ago.

Aaaand it miraculously just started working. 🎉 Apologies for the noise!

[augustuswm]

All good, apologies for the inconvenience. This was an unrelated outage on our end.