In debug mode this outputs the oidc discovery
2026-07-07T20:51:14+02:00 DBG discover config={"authorization_endpoint":"http://192.168.178.2:5556/dex/auth","claims_supported":["iss","sub","aud","iat","exp","email","email_verified","locale","name","preferred_username","at_hash"],"code_challenge_methods_supported":["S256","plain"],"device_authorization_endpoint":"http://192.168.178.2:5556/dex/device/code","grant_types_supported":["authorization_code","refresh_token","urn:ietf:params:oauth:grant-type:device_code","urn:ietf:params:oauth:grant-type:token-exchange"],"id_token_signing_alg_values_supported":["RS256"],"introspection_endpoint":"http://192.168.178.2:5556/dex/token/introspect","issuer":"http://192.168.178.2:5556/dex","jwks_uri":"http://192.168.178.2:5556/dex/keys","request_uri_parameter_supported":false,"response_types_supported":["code"],"scopes_supported":["openid","email","groups","profile","offline_access"],"subject_types_supported":["public"],"token_endpoint":"http://192.168.178.2:5556/dex/token","token_endpoint_auth_methods_supported":["client_secret_basic","client_secret_post"],"userinfo_endpoint":"http://192.168.178.2:5556/dex/userinfo"} rp.function=NewRelyingPartyOIDC
This will make testing easier, as it's more similar to the actual prod
deployment. We don't have to rewrite anything in vite, as the host and
origin is the same.
With session elevation, we cannot use DELETE /client as this requires
elevation. It should be possible to logout without an elevated session.
This makes the logout endpoint public api to be used by the android app.
Add two new endpoints for native app OIDC authentication using the
PKCE relay pattern (similar to Vaultwarden's SSO implementation):
- POST /auth/oidc/external/authorize - accepts a PKCE code_challenge
from the client, forwards it to the IdP, and returns the authorize URL
- POST /auth/oidc/external/token - accepts the auth code and
code_verifier, relays them to the IdP for token exchange, and returns
a gotify client token
The server never generates its own PKCE pair for this flow. It then relays
the client's code_challenge to the IdP during authorization and the
code_verifier during token exchange. The IdP validates the binding.
Pending auth sessions are stored in memory with a 10-minute TTL.
CSRF protection is provided by the state parameter, which contains a
cryptographically random nonce and is validated on the token exchange.
The state is single-use (deleted from the pending session map on lookup),
preventing replay attacks. Even without single-use enforcement, replay
would be harmless since the IdP's authorization code can only be
exchanged once.
Improve the performance of the unique function by:
1. Pre-allocating map capacity with len(s) to avoid frequent map resizing
2. Pre-allocating result slice capacity with len(s) to reduce append overhead
3. Reducing the number of traversals performs well under the condition of a large number of elements
These changes maintain the original behavior (preserving element order)
while reducing memory allocation operations, especially effective for
large slices (100k+ elements) with benchmark showing ~25% speedup.
No breaking changes, the function signature and output order remain unchanged.
We should use `(*regexp.Regexp).MatchString` instead of
`(*regexp.Regexp).Match([]byte(...))` when matching string to avoid
unnecessary `[]byte` conversions and reduce allocations.
Example benchmark:
var allowedOrigin = regexp.MustCompile(".*.example.com")
func BenchmarkMatch(b *testing.B) {
for i := 0; i < b.N; i++ {
if match := allowedOrigin.Match([]byte("www.example.com")); !match {
b.Fail()
}
}
}
func BenchmarkMatchString(b *testing.B) {
for i := 0; i < b.N; i++ {
if match := allowedOrigin.MatchString("wwww.example.com"); !match {
b.Fail()
}
}
}
goos: linux
goarch: amd64
pkg: github.com/gotify/server/v2/api/stream
cpu: AMD Ryzen 7 PRO 4750U with Radeon Graphics
BenchmarkMatch-16 2076819 647.7 ns/op 16 B/op 1 allocs/op
BenchmarkMatchString-16 2536326 442.0 ns/op 0 B/op 0 allocs/op
PASS
ok github.com/gotify/server/v2/api/stream 3.552s
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
