Web Development – Best Way to Protect Website Application Code

htmlserverurlweb-applicationsweb-development

Background

I have a web application that I host on my own server. I have clients who use the application as is, but some have asked if they can host the application on their own server. This enables them to have their own URLS rather than mine. The application only forms part of their website so I'm assuming it will not be possible for my server to respond to a direct call to their domain etc

To give some examples, i currently have urls like www.mydomain.com/profile, www.mydomain.com/index.php?option=someoption&view=someview&id=1 What my clients' want is www.theirdomian.com/profile, www.theirdomian.com/index.php?option=someoption&view=someview&id=1 etc

Question

My question is, what is the best way for me to allow them to use their own URLs with my application, without giving them all the backend source code and databases to install on their server?

One way I thought would be to create a router.php file that sits on their server. The router then asks my server to output the html. When a link is clicked on the clients site, the router receives the request and forwards the request to get the data from my server etc.

Is this an effective way to achieve what I want, or is it way off the mark.

Best Answer

There are a few technical solutions to this:

Have them point their domain to your server, and configure your server to accept such requests; this is a simple DNS change, but it does mean that their entire domain now runs on your server.
Have them set up a reverse proxy on their end that rewrites the desired requests to your domain. Apache, for example, has modules for this (see https://httpd.apache.org/docs/2.2/mod/mod_proxy.html), including filters to rewrite URLs inside the documents you serve; this is kind of a hassle to set up, and it doesn't work for everything, but it may be worth giving a shot - if it does work, your application will run transparently under their domain, served through their servers, but running on your own servers. The basic idea is that their server matches request URLs against a certain pattern, forwards them to your server, and then changes the URLs in the response it receives before sending it back to the client. (Basically, this is your router.php solution, only at the web server level, thus with less hassle.)
Have them put an iframe into their page, in which they just put your page. If the iframe has 100% width and height, the user won't see the difference (except that navigation does not change the visible URL). This is by far the easiest solution.
Split up your application into a service layer and a front end. Deliver the front end, but keep the service layer on your server. This way, they can only make use of your service through your server; the front-end without the service layer is relatively useless.
Install and maintain a server (physical or virtual) on their network that runs your application; set it up so that they cannot access it (strong passwords, full-disk crypto, etc.).

However, the problem is a social one, not a technical one, and the proper social solution is to set up a proper contract (hint: you do need a lawyer for this) that clearly states what they can and cannot do with it, and deliver the code. Yes, you need to trust them not to violate the contract in clever ways; but that's just the way of the world.

If you absolutely cannot trust them not to be criminals, then maybe you should just decline the offer and make your money elsewhere.

Related Solutions

Web Development – Best Approaches for License Key Solutions in Web Applications

There are many ways to implement something like this, but here's one that shouldn't be too hard to do:

You need a publicly-available website somewhere that hosts a file containing the hashes of license keys that have been blacklisted. How you manage this file is up to you, but the file itself need only have a hash per line.

Then, on a recurring basis, your software initiates a download of this file (most server-side languages provide for this) and then searches it for the hash of the installed license key. If it is found, then the application knows that it should die until the blacklist is removed.

MD5 or similar plus a secret should be sufficient for this. You could get fancier and have the application send the request to your site and you look it up in a database on the fly, but the file (for what I'm assuming would hopefully be a short list) would hopefully remain small and may be the easiest way.

The harder part is going to be keeping the application dead. After all, you've got to store this somewhere internally, which means if it is overly obvious it could be easily subverted, and even if it isn't overly obvious, it can be easily reverted by restoring the appropriate table(s)/file(s). Therefore I suggest a second method of protection as well.

This method would store "LIVE" or "DEAD" (or something sufficiently similar) in a table or a file, but again HASHed. This needs to be hashed with your salt AND a timestamp. Everytime a page on your application runs, check this value with a hashed version of "LIVE"+salt+timestamp and then permit for a valid range of timestamps (for example, one day, two days, one week, one month, etc. Keep in mind the larger the range the harder performance will take a hit.). As long as things match (or a match is found), the app is alive; otherwise, even if the value in the special file or table is "LIVE", it will still be dead if there is attempt to restore from backup because the timestamp will fall outside your threshold.

In summary (this does assume that you have some programatic method of checking the validity of a license key, such as some sort of checksum or other method):

CheckBlacklist
- Convert License Key to hash with salt
- Request blacklist file from server
- Is my hash in the file?
- If YES, then store hash of "DEAD" + salt + timestamp (truncated to day; no need to store hours+days+minutes)
- If NO, then store hash of "LIVE" + salt + timestamp (trunc'd)
IsKeyAlive
- Create hash from "LIVE" + salt + trunc'd timestamp
- Load DeadAlive hash
- Do they agree?
- If YES, then we're alive; return TRUE.
- If NO, then we're possibly dead, but we may still be within our timestamp window:
  - Subtract a day from the timestamp and repeat hash.
  - Do we agree now?
  - YES? Return TRUE
  - Add a day to the timestamp and repeat hash
  - Do we agree now?
  - YES? Return TRUE
- At this point, we're out of the timestamp range with no match. Return FALSE. (Kill app)

Now, goodness knows there's a million and one ways this can fail. Consider all the possible ways and build a reliable system (including one that assumes the client is right if the blacklist file can't be downloaded). Test, test, test it, and then test some more before deploying, because if it goes wrong, you'll have lost your client's trust.

Handling Resource Identifiers in REST API Clients

Edited to address question updates, previous answer removed

Looking over your changes to your question I think I understand the problem you are facing a bit more. As there is no field that is an identifier on your resources (just a link) you have no way to refer to that specific resource within your GUI (i.e. a link to a page describing a specific pet).

The first thing to determine is if a pet ever makes sense without an owner. If we can have a pet without any owner then I would say we need some sort of unique property on the pet that we can use to refer to it. I do not believe this would violate not exposing the ID directly as the actual resource ID would still be tucked away in a link that the REST client wouldn't parse. With that in mind our pet resource may look like:

<Entity type="Pet">
    <Link rel="self" href="http://example.com/pets/1" />
    <Link rel="owner" href="http://example.com/people/1" />
    <UniqueName>Spot</UniqueName>
</Entity>

We can now update the name of that pet from Spot to Fido without having to mess with any actually resource IDs throughout the application. Likewise we can refer to that pet in our GUI with something like:

http://example.com/GUI/pets/Spot

If the pet does not make any sense without an owner (or pets are not allowed in the system without an owner) then we can use the owner as part of the "identity" of the pet in the system:

http://example.com/GUI/owners/John/pets/1 (first pet in the list for John)

One small note, if both Pets and People can exist separate of each-other I would not make the entry point for the API the "People" resource. Instead I would create a more generic resource that would contain a link to People and Pets. It could return a resource that looks like:

<Entity type="ResourceList">
    <Link rel="people" href="http://example.com/api/people" />
    <Link rel="pets" href="http://example.com/api/pets" />
</Entity>

So by only knowing the first entry point into the API and not processing any of the URLs to figure out system identifiers we can do something like this:

User logs into the application. The REST client accesses the entire list of people resources available which may look like:

<Entity type="Person">
    <Link rel="self" href="http://example.com/api/people/1" />
    <Pets>
        <Link rel="pet" href="http://example.com/api/pets/1" />
        <Link rel="pet" href="http://example.com/api/pets/2" />
    </Pets>
    <UniqueName>John</UniqueName>
</Entity>
<Entity type="Person">
    <Link rel="self" href="http://example.com/api/people/2" />
    <Pets>
        <Link rel="pet" href="http://example.com/api/pets/3" />
    </Pets>
    <UniqueName>Jane</UniqueName>
</Entity>

The GUI would loop through each resource and print out a list item for each person using the UniqueName as the "id":

<a href="http://example.com/gui/people/1">John</a>
<a href="http://example.com/gui/people/2">Jane</a>

While doing this it could also process each link that it finds with a rel of "pet" and get the pet resource such as:

<Entity type="Pet">
    <Link rel="self" href="http://example.com/api/pets/1" />
    <Link rel="owner" href="http://example.com/api/people/1" />
    <UniqueName>Spot</UniqueName>
</Entity>

Using this it can print a link such as:

<!-- Assumes that a pet can exist without an owner -->
<a href="http://example.com/gui/pets/Spot">Spot</a>

<!-- Assumes that a pet MUST have an owner -->
<a href="http://example.com/gui/people/John/pets/Spot">Spot</a>

If we go with the first link and assume that our entry resource has a link with a relation of "pets" the control flow would go something like this in the GUI:

Page is opened and the pet Spot is requested.
Load the list of resources from the API entry point.
Load the resource that is related with the term "pets".
Look through each resource from the "pets" response and find one that matches Spot.
Display the information for spot.

Using the second link would be a similar chain of events with the exception being that People is the entry point to the API and we would first get a list of all people in the system, find the one that matches, then find all pets that belong to that person (using the rel tag again) and find the one that is named Spot so we can display the specific information related to it.