Bug : When SSO login is started twice within the same running process, the CLI crashes with a panic #549
Description
Describe the bug
When SSO login is started twice within the same running process, the CLI crashes with a panic:
This happens because oauth2login registers /auth/callback on Go’s global HTTP router every time it runs. The second registration causes Go to panic.
Steps to reproduce:
- Start SSO login once.
- Start SSO login again in the same process.
- Observe the panic.
here is the Panic: `panic: pattern "/auth/callback" conflicts with pattern "/auth/callback"
The issue can be reproduced with:
package cmd
import (
"context"
"testing"
"time"
"golang.org/x/oauth2"
)
func TestReproduceSSODuplicateCallbackPanic(t *testing.T) {
config := &oauth2.Config{
Endpoint: oauth2.Endpoint{
AuthURL: "http://127.0.0.1",
TokenURL: "http://127.0.0.1",
},
}
go func() {
_, _, _ = oauth2login(context.Background(), 0, config, false)
}()
time.Sleep(2 * time.Second)
// The second invocation registers /auth/callback again and panics.
_, _, _ = oauth2login(context.Background(), 0, config, false)
}Expected behavior:
- The second login should return a normal error or create its own temporary callback server.
Actual behavior:
- The process crashes with a panic and stack trace.
Impact:
- Applications, tests, or services that reuse the CLI cannot safely perform multiple SSO logins.
Suggested fix:
- Use a private http.ServeMux for each login instead of the global http.DefaultServeMux..
Expected behavior
No response
Actual behavior
No response
How to Reproduce?
No response
Microcks version or git rev
No response
Install method (docker-compose, helm chart, operator, docker-desktop extension,...)
No response
Additional information
@Harsh4902
Please review and assign if valid
Activity
Sarthak-Shreshtha01 commentedon Oct 4, 2026
Each SSO login now adds the /auth/callback route to its own private http.ServeMux instead of the global http.DefaultServeMux, so a second login no longer crashes. (PR: #571)
Sarthak-Shreshtha01 commentedon Oct 4, 2026
Sorry @aniket866, I missed that you had asked for this in the issue. I'm closing #571 so you can go ahead with yours.
yada commentedon Oct 15, 2026
Still valid on current master (f9550f5).
cmd/login.go:312still callshttp.HandleFunc("/auth/callback", callbackHandler)on the globalhttp.DefaultServeMux. The test from this issue (twooauth2logincalls in one process) panics:The earlier comment about a fix refers to PR #571, which was closed, so nothing has been merged. A private
http.NewServeMux()per login, set assrv.Handler, would fix it. It would also cover #312, which has the same root cause.Disclosure: this comment was drafted with AI assistance, and the results were run locally.
Sarthak-Shreshtha01 commentedon Oct 15, 2026
@aniket866 are you still working on this? If not, I can reopen #571. It's rebased on current master, and its test that runs two logins in one process passes. It would also fix #312.
aniket866 commentedon Oct 15, 2026
@Sarthak-Shreshtha01
yeah you can reopen No problem
Sarthak-Shreshtha01 commentedon Oct 15, 2026
Thanks @aniket866. I reopened #571 and rebased it on current master.
yada commentedon Oct 17, 2026
Update: there are PRs for this. I built the PR heads and ran the two-logins-in-one-process test from #549 (the one that panics on master):
ServeMuxper SSO login, reopened and rebased): no morepattern "/auth/callback" conflictspanic. The second login just waits for the browser callback, so the test only ends on its timeout. Thecmdtests pass.cmdtests pass. I did not test the occupied-port behavior it also targets.Both PRs touch the same code, so only one of them should be merged.
Disclosure: this comment was drafted with AI assistance, and the results were run locally.