Over a million developers have joined DZone.

Permissions for Composite In-House Web Apps

DZone 's Guide to

Permissions for Composite In-House Web Apps

There's a way to code an app launcher back end and not have to handle user permissions on the server side.

· Web Dev Zone ·
Free Resource

You have a bunch of internal web apps that are stitched together in a load balancer or reverse proxy layer. You have an app launcher effect that allows this, like Google does in their standardized top-nav:

In fact, I've blogged about this 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 like 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. 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:

Image title

(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 a 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 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 checked for permissions. 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 will bring it back when the system recovers.

In the nonexample 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 can 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 difference between the original demo and my permissions example.)

Lastly, HTML5 has an 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 five years. It is specced now, but Mozilla has no plans to support it for Firefox. They suggest that you put in a shim JavaScript thing to fake it. Asinine. Great. We’ll generally stick with JavaScript imports, a feature that was implemented by NetScape (Mozilla’s former company) 20 years ago.

web dev ,back-end ,web security

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}