Cookies, Browsers and the AEK
Balancing the functionality of the AEK against what browsers continue to refine on and even introduce as new functionality can be difficult. One of the areas where there is little compromise, however, is security. We’ve seen a number of changes come into play in the past year or two (for example the recent SameSite changes).
There’s no impact on your apps or web apps. Typically, that’s handled by platform improvements, and the monthly native release cycle. But what it does impact is local development. We frequently recommend plugins, or describe approaches that allow you to safely simulate the web app on your own machine, running the AEK project you’re working on. Changes to cookie security have gotten in the way of this, and sometimes it’s just through feature updates to the browsers we all rely on.
One of these changes is Google Chrome redesigning its privacy settings. It’s reasonable to expect other browsers to make similar changes, so even if you’re used to Firefox, or Safari, Edge, or others, it’s important that you understand what this can affect. An example of the default settings in Chrome 83 and onwards is shown below (click for full size):
Impact on the AEK
Session cookies are the most common form of cookies, and they’re used in campusM to handle your web app session (among other things). The CMAuth session token is also stored here. Blocking cookies – though sensible for most users – is going to cause problems in validating your session (even in a non-CMAuth profile). We’ve seen an increase in reports in copying cookies to your localhost environment simply not working – one of the major reasons are these evolving privacy settings and standards.
What this means is even if you copy the cookies correctly, when clicking on the relevant app profile in your localhost session, you either will be redirected back to the profile selection page, or you’ll be redirected onwards to the profile’s identity provider (as you would be in the actual web app).
Chrome lets you add exceptions, or even allow all cookies. The choice is yours, but I’d recommend allowing specific exceptions for domains you either work with directly, or know to be trustworthy. An example of my current exceptions (the only exceptions I have set for Chrome full stop) is shown below (click for full size):
You wouldn’t need to have such an expansive whitelist. localhost, and maybe some of your app’s web hostnames for testing in Incognito (though only localhost is strictly necessary). As a campusM developer I work on a variety of apps, test apps and domains, so I decided to whitelist all the potential (non-custom) domains I work with.
Important: please make sure you tick “all cookies, on this site only” when you add the exception. You cannot edit this setting back in if you forget it – you’ll have to delete the exception and re-add it if you miss it the first time around.
Once that’s done, just restart the Incognito window and the new settings will have been applied.