You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This may end up with a Cookie bigger than 4096 bytes, and then not being persisted by the browser and used later.
A possible solution (if accepted) would be to use some compression before encryption, in a way that the raw text/string can be reduced, and then encrypted (in a cost of probably a bit more CPU).
The opposite should happen as well. So one suggestion:
// encryptClaims() receives the STS claims, concatenate them and encrypt them using AES-GCM
// returns a base64 encoded ciphertext
func encryptClaims(credentials *TokenClaims) (string, error) {
payload, err := json.Marshal(credentials)
if err != nil {
return "", err
}
var b bytes.Buffer
payloadgz := gzip.NewWriter(&b)
if _, err := payloadgz.Write(payload); err != nil {
return "", err
}
if err := payloadgz.Close(); err != nil {
log.Fatal(err)
}
ciphertext, err := encrypt(b.Bytes(), []byte{})
if err != nil {
return "", err
}
return base64.StdEncoding.EncodeToString(ciphertext), nil
}
Testing locally, and using default gzip compression, a 4500 bytes cookie could be properly reduced to 2589 bytes, and then the authentication moving forward without any problem.
If this is accepted by the community, I can raise a PR changing encrypt/decrypt Claims to compress before encrypt.
The text was updated successfully, but these errors were encountered:
Hi everyone
It there any fix/plans? we are still experiencing this problem with big jwt token from IDP
We get "malformed response cookie" from 'auth' endpoint
When using IDP, the provider may return a big JWT token.
This JWT is part of the SessionToken and may be used later.
Apparently, in Minio Console, all the credentials are marshalled and then encrypted and finally turned into a base64:
console/pkg/auth/token.go
Lines 127 to 137 in 5e10719
This may end up with a Cookie bigger than 4096 bytes, and then not being persisted by the browser and used later.
A possible solution (if accepted) would be to use some compression before encryption, in a way that the raw text/string can be reduced, and then encrypted (in a cost of probably a bit more CPU).
The opposite should happen as well. So one suggestion:
Testing locally, and using default gzip compression, a 4500 bytes cookie could be properly reduced to 2589 bytes, and then the authentication moving forward without any problem.
If this is accepted by the community, I can raise a PR changing encrypt/decrypt Claims to compress before encrypt.
The text was updated successfully, but these errors were encountered: