Programming Language Interoperation for Website

Question

Say I have one website created with the LAMP stack and another with the MEAN stack. I want to create a program which estimates the entropy of a password so that I can add a password strength meter to the sign up pages on both sites. I do not want to write the same same program in both PHP and Javasript.

What is the best (or at least standard) way of facilitating interop between my entropy program and LAMP/MEAN servers?

It seems like the easiest way would be to use PHP's exec or Node's child_process.exec to call my entropy program, but I always read literature warning against direct system calls. Or is it the case that it just has to be done right?

Should I use UNIX sockets?

Should I create a REST (or WS*) API for the entropy program which is only accessible from the same server?

Is there another method?

In this case I plan on using C for the entropy program, but I am looking for a solution which works with any language: complied or interpreted.

Answer 1

What you're trying to achieve is described as an SOA (Service Oriented Architecture) which defines an application as a set of very loosely coupled, fine-grained, independently deployable services interfaced with a lightweight technology-agnostic protocols. This kind of architecture puts emphasis on modularity, testing, continuous refactoring of individual modules (also called microservices). It's a very young concept and an overall consensus in regards to best practices has yet to emerge, therefore, it's hard to directly answer your question. What people usually agree on is:

• each service should represent a philosophy of "do one thing and do it well"
• each service should use best language for given task
• selected protocols shouldn't be language dependant
• not everything should be a service

This last bullet is an example of the usual criticism towards the SOA concept which seems to be focused around the tendency of creating "nanoservices" (i.e. services too fine-grained to justify the overhead of inter-service calls).

As there's no real "standard" or commonly agreed "good practice" in regards to such services, I've seen several applications over the years where literally each service used different stack. Even though they communicated with each other rather easily and efficiently, I'd personally advice against it due to the high entry threshold for new developers.

Above said, the most common solution I've seen was C/C++ daemon listening on a Unix socket. It's pretty scalable as these can be communicated locally or over the network, also C/C++ language is widely used and there's high chance somebody new to the project will know it or be able to quickly find help on the Internet. Slightly less popular were using a shell script + Unix socket. The rest of SOA services I often ended up replacing with a piece of JavaScript that I kept in shared memory and just included wherever needed (it's a breeze in both typical PHP and JavaScript SPA style applications).

Answer 2

I suggest a web service approach.

Create a json formatted rest service in any language (c, nodejs, whatever).

Service takes arg of password and returns json structure with analysis results.

This service is then a module that can be easily used from either existing website for example via simple curl calls.

Security of this service can be achieved in many ways but one simple example is the service can be configured to only listen on a private localhost port so it's as secure to the existing webservers as a subroutine call would have been.

Note this is intrinsically quite similar to the exec approach you outlined but because the service is always running this approach is more efficient: same interprocess communications but no need to start process and initialize it's data for each request.

Answer 3

A password strength meter is highly security-sensitive software. The password should ideally never be transmitted to the server.

This also resolves your dilemma: implement the password strength meter as a client-side widget in pure JavaScript. You can then easily reuse this widget on both websites.

---

When you heard that running child processes should be avoided that is mostly right. Launching a process takes a long time, relatively speaking, which noticeable limits the requests per second you can handle. Even more so when the child process is an interpreter. Error handling of child processes can be nontrivial.

There are also some potential security issues: command line parameters are not private. Secrets should be communicated through a pipe instead. It can be difficult to guarantee that you are running the process you intended due to features like the PATH variable and filesystem symlinks. If you were to accidentally run the wrong process, the passwords might be compromised. While none of these security concerns should apply if you are running on a private server, it is important to consider them.

A note on using C: it is a perfectly fine language, but writing secure software with it can be challenging unless you are an experienced C programmer. It is easy to accidentally introduce buffer overflows, and it is easy to forget correct error handling. The Spiderman Principle “with great power comes great responsibility” applies.

Running a persistent password strength meter program and communicating with it via sockets or an API could be interpreted as a kind of microservice. This would allow you to reuse the same service on multiple websites as the programming language of the microservice is independent of the rest of your website. But as discussed above, a client side implementation is vastly preferable here.