I’m unclear on what we need to do in order to prepare for this change. Is there config change we need to make?
We are using an older version of the package, I can not see any mention in the changelog regarding updates for this specific issue, so I’m not sure if upgrading would help? I know someone will say “upgrading is always recommended”, problem is the package was rewritten at one point so it’s not just a quick update, there’s work required around migrating to the new version. I’d like to know if we put in this effort will it fix this deprecation issue? Or is it based on config we’re putting in?
Please include the following information in your post:
It looks like it is a toggle under the advanced settings of your dashboard, you need to scroll down to the migrations section and disable the fixed-length toggle. Would have been helpful if that had been included in the migration documentation.
Thanks. I was aware of this, but not certain if when I toggle it whether the nextjs library will just work fine or not. Or if there is a particular version we need to be on or a config value we need to set/change.
Some SDKs, including this one, store the Access Token (encrypted) in a cookie - so a larger Access Token will mean a larger cookie. If you already specify an audience - then the cookie size will not change, if you don’t then the Access Token will increase (it will go from an opaque id to a JWT, which can be roughly 1kb larger). If you are in the unlikely position of already being close to the maximum header size (16kb in Node >12) with your other cookies, a larger session cookie could potentially take you over that limit.
But on the whole, we don’t expect this package, or any of our SDKs, to be affected by the size of the Authorization Code or the Access Token. You can verify this by toggling on the migration in your development tenant and confirming it locally.