5

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.

GWed
  • 3,085
  • 5
  • 26
  • 43
  • if they really worry only about url (to show nice they domain url) just use iframe on html page in they servre, with includes your real page, then users in browser will see only they domain url, but everything will work in our server. If you will give code to them, then there is no real way to protect (can try some zend encoding, but it's just play), from other hand if thinking that they can stole your code, maybe they don't worth to be customers at all. – Dainius Dec 12 '12 at 15:10
  • If they want the code to run on their servers fine. Just write up a new contract where you sell them a single license to run as they want. Make sure the contract covers maintenance fees for fixing stuff on their servers etc. – Martin York Dec 12 '12 at 16:39
  • If you're worried about piracy, just make it clear in the contract what the terms of use are for the code. Most legitimate companies want to license and use your software properly, and have no interest in piracy. – Robert Harvey Dec 12 '12 at 17:04
  • I agree, but I dont want to take the risk. I charge a yearly fee for my application. If I give them all the code, where is the motivation to purchase a license next year if they have all the code? – GWed Dec 12 '12 at 17:15
  • @Gaz_Edge - You might want to take a look at how GitHub does it with GitHub Enterprise. Basically, they give you a locked-down virtual machine that you stick on your server. It allows you to use your own install, while keeping the closed source closed. – Shauna Dec 12 '12 at 20:18
  • 1
    @Gaz_Edge Divide your app into two layers. On your server you keep db and API accessible as a web service. Your clients get code responsible for presentation and accessing your API. In this way you can control who is using your app at the same time your clients have more flexibility in using your app. It also can create additional source of revenue for you - customized changes on customer servers. – onlineapplab.com Dec 12 '12 at 21:31
  • @onlineapplab.com great answer - this is similar to the front end / service layer below. I think this is the way I need to go. – GWed Dec 12 '12 at 22:28

5 Answers5

5

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.

tdammers
  • 52,406
  • 14
  • 106
  • 154
  • wow! Great answer - very comprehensive. I agree about the contracts, but as they say, prevention is better than cure. Would like to avoid legal actions if someone did abuse the code. I think the service layer / front end is what I'm looking for. Will give it a try. – GWed Dec 12 '12 at 22:26
1
  1. "www" is a sub-domain.
  2. foo.yourclient.com/profile <-- if the links are all relative to the root, then there's nothing to configure. Otherwise, set this for the BASE HREF.

The simple solution is to manage sub-domains, host the software yourself and market it as a SaaS solution. The only hurdle might be skinning the code on a sub-domain basis to match their main site.

Or you can take the overly complex path where you need to deploy obfuscated/compiled code onto their servers, fix any problems with how their servers are setup, coordinate with their IT people to update the software, handle database issues on their servers, etc.

Or you can convert your software to an API and build a RESTful layer that your clients can use from a website they build and maintain.

Adrian J. Moreno
  • 1,098
  • 6
  • 12
0

Would it be an option for them to use a subdomain? So:

They create a subdomain like: accounts.theirdomain.com and in DNS set your server IP. You accept those requests and show the data for their accounts.

Example: https://support.zendesk.com/entries/13976-mapping-a-host-name-of-your-own-to-zendesk-using-cname

Luc Franken
  • 2,664
  • 15
  • 9
  • Thanks for the answer. No that't wont work as the urls need to be has written in my question. Also, I don't want the overhead of managing subdomains on my server – GWed Dec 12 '12 at 15:10
  • Ok that's a pitty, next to that there are no options expect giving the source or rewriting it. Then you could make an API running at your server and you supply only the API client to their server. – Luc Franken Dec 12 '12 at 15:30
0

You could protect your code with a tool like Zend Guard, IonCube or something similar. Most hosts I've seen support the use of protected scripts.

pritaeas
  • 336
  • 5
  • 15
0

Distribute your application in a virtual machine which runs on VMWare or VirtualBox or something similar. All your customer sees is a virtual server in their network. Everything inside is only accessible to you. Your customer does need to be able to support virtualization in their IT environment, but that is becoming more & more common these days.

You will have to do some extra configuration depending on whether they support DHCP or fixed IP addresses, if they insist on data backups, and if they need SSL certificates installed. But either way, they don't have to see anything inside the VM.

Jay Godse
  • 1,174
  • 7
  • 11