Paul Hammant's Blog: Permissions for composite in-house webapps
You have an bunch of internal web-apps that are stitched together in a load balancer / reverse proxy layer. You have an app-launcher effect that allows, like Google do in their standardized top-nav:
(In fact I blogged about that before, and this is really a follow up trying to build it in 2016).
They all have different technologies, teams, builds, source repos, and release cadences. These agree on cookies and URLs - in the browser - the way it should be. If you are me, you want to engineer these apps so that they are not calling each others backends. I mean from backend to backend, specifically.
Different employees have different permissions to different apps. You could hold who is permitted to what in a number of places. Centralized is one place. My preference, as with all configuration is “with application”. Your new problem is in the app-launcher backend - does it query that centralized place N times for permissions for the logged in user?
Well, there is a way in which you could construct the app-launcher backed where it does not do that. Instead we could do the permissions work for the app-launcher control in the browser itself. I’ve forked a Codepen by Manar Kamel, and made an app that handles permission in the browser:
The app-launcher does those permissions check after (asynchronously) the initial load of the page. The assumption is that the user is not permitted (the app icons are ghosted on load). Each app (12 in this case) is separately checked for permissions. And it does not matter if an end-user hacks their DOM to attempt to permit themselves to an application, as the application itself handles authorization to its own pages and/or data APIs, and would block unauthorized users as they attempted to go to a known URL. It also doesn’t matter if one of the backends is down - the app will appear ghosted, and a refresh (etc) will bring it back when the system recovers.
In the non example version of this, each separate application’s server needs to be able to read the shared cookie for the logged in user during the response creation for
app-name/permissions.js. That is so that it knows who the user is (and that they are logged in).
This way you could code an app-launcher backend and not have to handle user permissions on the server side. At least in that application.
Lastly, HTML5 has a