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 other’s 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:
After page load, the app-launcher reaches out to each sibling app and asks “is this user permitted to your app”. The answer comes back in JavaScript. Here is the JavaScript that would be returned for a example ‘permitted’ application (android) and here is the JavaScript that would be returned for a ‘denied’ application (skype). I am faking dynamic endpoints on GitHub.io, which also doesn’t have a reverse-proxy stitching a site experience from multiple separate web-apps, but you can imagine that pulling things into the ‘same origin’, which is necessary for this to work. Here is the JavaScript for all the apps that ay or may not be authorized (for the user) invoked to build the icons overlay.
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.
See also Google’s accounts system - architectural meaning and the the diff between the original demo and my permissions example.
Lastly, HTML5 has a html imports feature, that should have been there 20 years ago. If it was we’d have been further advanced with web-app technologies by at least 5 years. It is specified now, but Mozilla have no plans to support it for Firefox. They suggest you put in a shim JavaScript thing to fake it. Asinine. Great - we’ll generally stick with JavaScript imports, then, a feature which was implemented by NetScape (Mozilla’s former company) 20 years ago.