Closed nickperry closed 5 years ago
It seems like the easiest cross-browser fix might be just to span the id_token data over multiple cookies with sequentially numbered suffixes. An additional cookie could be introduced to define the number of additional cookies that have been used and that need processing from a request.
Hey @nickperry! We have an open PR that addresses this: https://github.com/heptiolabs/gangway/pull/117
We haven't had a chance to look at it. It would be great if you could provide a testing data point, although the PR is most likely out of date with master
.
Thanks @alexbrand. I managed to overlook that PR. I will try it tomorrow and feed back. Many thanks.
Rebased it onto master :) Yes, please test it out. We've been running it successfully on our clusters.
Awesome @Croissong! Would be great to get this in. Thanks!
@Croissong @alexbrand PR #117 works like a charm. I made some artificially large credentials, they spanned correctly:
and were able to log in.
Many thanks.
I can confirm it works great for me too. Thanks @Croissong
Further to my artificially modified account testing last night, today we've had multiple real users who could not log in previously, report that they can now log in fine with @Croissong's patch.
is this ticket closed? i see something is merged.
is this ticket closed? i see something is merged.
yes, and included in release v3.2.0
Yep! Closing as this was fixed by #117
Nice thanks
Chrome has an upper bound on each cookie of 4096 bytes. I understand that some other browsers are limited to 4093 bytes.
A significant proportion of users in our organisation are members of enough LDAP groups to inflate the size of the gangway_id_token cookie in the response headers from /callback to be above this limit.
The result is that the cookie does not get set by their browser and is absent in their subsequent call to /commandline. They cannot therefore use Gangway to log in.