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
{{ message }}
This repository has been archived by the owner on Feb 24, 2018. It is now read-only.
For a project we are currently working on, we are using cookie storage to enable single-sign on across various subdomains (eg site1.domainname.com, site2.domainname.com).
Testing has shown that the tokens that Cognito generates are rather large. Especially when device tracking is enabled, the tokens that require storage will easily surpass the per-domain cookie limits of some browsers, most notably Safari, which, even in its latest iterations, still has a specific limit of about +- 5090 bytes per domain (= the sum of all cookie sizes on a particular domain cannot exceed 5090 bytes). Once that limit is exceeded, the entire domain becomes inaccessible from Safari, with a cryptic kCFErrorDomainCFNetwork error 303. The only fix we are aware of at that point is to fully clear the cookies.
To provide some data on base token size, for the three tokens issues by Cognito:
Clearly it's quite easy to bump into the domain-level cookie limit on Safari, especially if device tracking is enabled. Even with device tracking disabled, our ability to use other packages, modules, plugins, ... on any subdomain is now limited, since they might also have a need to set cookies.
A cursory examination of the token contents indicates that some tokens may be larger than they strictly need to be. For example, the idToken appears to contain full user information, including custom fields. I can imagine situations where, if a Cognito User Pool has lots of custom attributes set to their maximum limit, token sizes would quickly become prohibitively large.
I don't have an immediate solution to propose, except perhaps to allow blacklisting/whitelisting of properties inside the idtoken. This way, the admin has control over what fields should be included in the token itself.
Any other suggestions?
The text was updated successfully, but these errors were encountered:
For a project we are currently working on, we are using cookie storage to enable single-sign on across various subdomains (eg
site1.domainname.com
,site2.domainname.com
).Testing has shown that the tokens that Cognito generates are rather large. Especially when device tracking is enabled, the tokens that require storage will easily surpass the per-domain cookie limits of some browsers, most notably Safari, which, even in its latest iterations, still has a specific limit of about +- 5090 bytes per domain (= the sum of all cookie sizes on a particular domain cannot exceed 5090 bytes). Once that limit is exceeded, the entire domain becomes inaccessible from Safari, with a cryptic
kCFErrorDomainCFNetwork error 303
. The only fix we are aware of at that point is to fully clear the cookies.To provide some data on base token size, for the three tokens issues by Cognito:
Clearly it's quite easy to bump into the domain-level cookie limit on Safari, especially if device tracking is enabled. Even with device tracking disabled, our ability to use other packages, modules, plugins, ... on any subdomain is now limited, since they might also have a need to set cookies.
A cursory examination of the token contents indicates that some tokens may be larger than they strictly need to be. For example, the
idToken
appears to contain full user information, including custom fields. I can imagine situations where, if a Cognito User Pool has lots of custom attributes set to their maximum limit, token sizes would quickly become prohibitively large.I don't have an immediate solution to propose, except perhaps to allow blacklisting/whitelisting of properties inside the idtoken. This way, the admin has control over what fields should be included in the token itself.
Any other suggestions?
The text was updated successfully, but these errors were encountered: