You have an bunch of internal web-apps that are stiched 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. Centralizes 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 centralizaed 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:

Link to example app

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 an ‘permitted’ example and here is a ‘denied’ example. I am faking dynamic endpoints on Github, 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.

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 cheked 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 appication’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 applicaton.

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 specced 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.

blog comments powered by Disqus


December 11th, 2016