Hello!
I've been experimenting with reject-static and noticed that adding it to the else segment of basicauth breaks the hidden_domain behavior.
The issue lies in the initial condition within requireBasicAuth, which immediately passes validation to the next provider in the chain, effectively skipping the hidden_domain check.
|
func requireBasicAuth(ctx context.Context, wr http.ResponseWriter, req *http.Request, hidden_domain string, next Auth) (string, bool) { |
|
if next != nil { |
|
return next.Validate(ctx, wr, req) |
|
} |
Since none of the reject-* handlers process hidden_domain inside their own Validate methods, the check never actually happens.
I'm not very proficient in Go, but I'd like to propose a more robust approach: we should validate hidden_domain within requireBasicAuth immediately, before falling back to next.Validate(). I'll submit a PR with these changes.
This fix should resolve the issue with reject-* at the end of the chain and ensure that every hidden_domain is checked at each stage of the basicauth sequence, rather than only the final one.
Hello!
I've been experimenting with
reject-staticand noticed that adding it to the else segment of basicauth breaks thehidden_domainbehavior.The issue lies in the initial condition within
requireBasicAuth, which immediately passes validation to the next provider in the chain, effectively skipping thehidden_domaincheck.dumbproxy/auth/common.go
Lines 24 to 27 in dbdbd4a
Since none of the
reject-*handlers processhidden_domaininside their ownValidatemethods, the check never actually happens.I'm not very proficient in Go, but I'd like to propose a more robust approach: we should validate
hidden_domainwithinrequireBasicAuthimmediately, before falling back tonext.Validate(). I'll submit a PR with these changes.This fix should resolve the issue with
reject-*at the end of the chain and ensure that everyhidden_domainis checked at each stage of the basicauth sequence, rather than only the final one.