Communicating with a walled-off system



  • So, as I've mentioned in the Status thread, we got a client with a fairly problematic infrastructure. They want two things - an admin panel, living in their intranet, not exposed to the world and logged in to via WinAuth, and a microsite living on a most basic shared hosting, probably some $0,99 PHP/MySQL stack (they don't want to bother with upgrades and maintenance, so a VPS is off the question) and authenticated via email links.

    The microsite allows for the basic operation (here it's "confirm frobbing", "reject frobbing" and "change the list of people who can confirm/reject"). From admin panel, the list of people can also be changed (plus accounts locked, etc.), and the two need to be in total sync and have no anomalies - so if someone, say, changes the list from the admin panel while you have the microsite open on the "tweak the list" form, your changes should be rejected, since you didn't see the updates list. And the other way around - the admin panel needs to be updated with changes from the microsite.

    The problem is, the client has his networking managed by $BIG_TELCO, and there's no way for the microsite to connect to the server (where the DB resides, among other things) without three or so months of paperwork. We can't expose a web service, we can't have it use a limited DB account, nada. We can, however, initiate web connections from the intranet (or so we hope).

    So my solution is for the intranet server to long-poll the microsite one on an IP restricted endpoint, have the microsite respond whenever an action is taken, and have the intranet server return the results of the action in the next long-poll. It should work, but it seems horribly ass-backwards. Is this the best we can do under the given circumstances?



  • Seems like a cheap client, do the shit and off to the next one.


  • ♿ (Parody)

    @Maciejasjmj said:

    They want two things - an admin panel, living in their intranet, not exposed to the world and logged in to via WinAuth, and a microsite living on a most basic shared hosting

    @Maciejasjmj said:

    the two need to be in total sync and have no anomalies

    Give them this link:

    https://youtu.be/BKorP55Aqvg

    OK, more seriously:

    @Maciejasjmj said:

    and there's no way for the microsite to connect to the server (where the DB resides, among other things) without three or so months of paperwork.

    Is this to get stuff set up or for each connection? I recommend they do the requisite paperwork.


  • BINNED

    The only other thing I can suggest is that maybe you could use something like WebSockets if available to make the communication snappier?

    Oh, no, wait... You can't open a listening server on the intranet side, can you?

    Also, almost everything else I thought of broke down even sooner because

    @Maciejasjmj said:

    PHP

    Yeah.... that...



  • @boomzilla said:

    Is this to get stuff set up or for each connection?

    To open a port. We'd love for them to provide us a sensible environment to do this thing, but we're not sure they'll roll with it.

    @Onyx said:

    Oh, no, wait... You can't open a listening server on the intranet side, can you?

    Natch.

    @Onyx said:

    Yeah.... that...

    Well that's the preferred solution, but maybe we'll be able to go .NET if we find a suitable (read: cheap and maintenanceless) hosting.



  • @Maciejasjmj said:

    It should work,

    It should? Even a tiny 99 cent server can handle 20-30 connections simultaneously. It can easily process multiple pageloads while your long poll is reconnecting.

    The only answer here is they have to go through the telco process. (And start looking into switching ISPs.) It'd take longer to develop a bug-free implementation of your long-polling idea.

    I highly doubt the telco process, whatever it is, genuinely takes 3 months. I think it's more likely there's a fee associated with it and your client is cheap. In any case, replacing 20 hours of a secretary or intern doing paperwork and making phone calls with 40+ hours of a developer fiddling in PHP and MySQL trying to get something like this to work is a terrible trade-off in ANY company even SLIGHTLY interested in operating efficiency. (Unless you're massively underpaid. I guess that's a possibility.)

    EDIT: do both systems have access to Amazon Web Services? Enough access to use Simple Queueing Service? Is the data sensitive in any way, or is it "cloud-able"? Of course your client will kibosh that idea because it costs $$$ (gasp!) but there's an alternative for you.



  • Long Poll should work just fine (if done well). It is used by many major systems.



  • @TheCPUWizard said:

    Long Poll should work just fine (if done well). It is used by many major systems.

    Do those two sentences have any sort of connection? Because I'm not seeing it.



  • @Scarlet_Manuka said:

    TheCPUWizard:
    Long Poll should work just fine (if done well). It is used by many major systems.

    Do those two sentences have any sort of connection? Because I'm not seeing it.

    There is a statistical correlation between frequency of use and "working well" [though there are plenty of exceptions].



  • @TheCPUWizard said:

    There is a statistical correlation between frequency of use and "working well"

    ... positive or negative? ;)


Log in to reply