I would like to know the best way to enable custom domains when creating web applications. For instance, if you look at something like Base Camp, when you sign up for that you create your own 'sub domain' to which you use to login to your basecamp with.
Also, if you look at this like hosted ecommerce sites, you can use your own custom domain instead of using a sub domain of theirs.
Personally I can't see these web applications 'parking' each custom domain on the web apps hosting account or adding the DNS if it uses a sub domain like Base Camp does.
Therefore, the only way I can think about doing something dynamically like this is to maybe use mod_rewrite to redirect everything to a certain script that does the 'routing' based on the url. Then for the customer domains, the customer would just need to add a CNAME for their domain to something like custom.webappname.com which then in turn gets picked up by mod_rewrite and the php routing file.
If this is the best way forward, are there any performance issues with routing all incoming requests via this 'routing file'?
Sorry if im not clear, tried to explain the best I can.
Yes, your solution would be the best way. That is how other sites do it. Rerouting all requests through a central file using rewrite rules incurs a small performance penalty but it is well worth it.
In fact, in most applications you are already paying that penalty anyway. Any framework that uses the FrontController pattern already does exactly this. This includes pretty much all frameworks like Zend, Symfony 1 and 2, CakePHP, CodeIgniter an many others.
It really depends on the web app your working with.
For example we have a hosted CMS, using the cPanel API we do create an actual hosting account for each customer and install about 50KB of files on account creation including a default template, initial set-up script (handles DB install, initial population of data and basic settings amongst other things) and a few basic front end control scripts such as the contact form, in saying this we don't provide access to the hosting account, all interaction is via our web app. In our case this is regardless if a sub-domain or fully qualified domain. Our customers have the option of self-hosting their domain or we will host it, because we have complete cPanel hosting infrastructure it makes no difference to us where DNS is but if the customer has it away from us it is entirely their responsibility.
The reason we have this hosting set up is so customers can upload their own templates, for disk storage management (we aren't interested in being a file server but customers need some space for PDFs, images, etc) and to make sure the content of 1 customer doesn't get mixed in with the content of another. As a premium paid-for service our lawyers recommended a minimum of separate identifiable folders on the server for file storage.
Another example is blogger/blogspot, it is well known they use mod_rewrite for their sub-domains. This is appropriate for them to do it this way otherwise they would have to create a separate DNS zone for each blog at a minimum and this is a pain (hence why we use cPanel), plus you have all your other virtual hosting set-ups.
With mod_rewrite as you will be aware it will use a single wild-card zone to control the sub-domains and the mod_rewrite rule is easy to apply. From there it is simply creating a folder and redirecting requests for the sub-domain to it or directing to the script to control your app depending on what you're doing.
The truth is for an automated system using sub-domains I would use mod_rewrite but for something a bit more complex like a fully blown premium CMS requiring full legal conformity, quota management, suspend, terminate and file removal functions then I would recommend looking at a hosting control panel such as cPanel as a possible solution.
You've got the right idea. You keep a single codebase, running (for the sake of argument) on a single IP. You don't need to worry about virtual hosts, or even mod_rewrite (aside from whatever your application needs).
You web app simply handles any and all requests to that IP (on port 80 or 443, or whatever).
When your application bootstraps in response to a request, it peeks at $_SERVER['HTTP_HOST'], and configures itself for the client associated with that domain name. If not found, it 404s, or whatever makes the most sense.
Related
I have seen a lot of solutions that involve using .htaccess. I would like to know a way to create sub domains using only PHP. For my purposes, this also needs to work using non-host-specific mechanics so it would work on most hosts.
All I know is that I would need a wildcard CNAME record that says all sub domains point to x.x.x.x, but I don’t know what to do from here. What I think you need to do is create a folder that contains the code for the sub domains, and I have done this, but I cannot find a cross-host way to link the sub domain with the folder. There has to be a way to do this as I have seen it done, but I can not find a way that meets my needs.
The problem here is that PHP doesn't handle the request coming in, a web server (e.g. Apache or Nginx) does and it's the config for that software that determines where a request goes. Now the good news is that you can have wildcards in your config (at least for Apache and Nginx, YMMV if you're not using one of those), as long as you can access the config file (you'll need root access on the server). There is plenty of information available out there depending on what web server you are using so you can google that part.
Now, assuming you've done that part, in PHP you just need to check what the root domain for the request is. That information is stored in $_SERVER['HTTP_HOST'], so you can use a simple script to figure out which subdomain has been requested and then launch the appropriate script for that subdomain. Something like this should do the trick:
// Assuming request comes from https://subdomain.mydomain.com
$subdomain = str_replace('.mydomain.com', '', $_SERVER['HTTP_HOST']);
echo $subdomain // Outputs "subdomain"
This will capture multiple levels of subdomains as well, so if your request comes from https://sub1.sub2.subdomain.mydomain.com then $subdomain would contain sub1.sub2.subdomain.
Edit after comment
You can't do this with shared hosting. Basically the config panel you get with the host, when you set up a domain or subdomain it's modifying the config file on the server for you. There's no way a host would let anyone access the config through anything other than their control panel for security. It's possible that hosts will have a similar setup to your test server, where subdomains just work as they use wildcards by default, but I don't know that and there's no guarantee of that.
WordPress itself is just blogging software. It doesn't let you set up lots of separate websites with their own installations. What WordPress Multisite (I assume that's what you mean when you mention WordPress) is use a single installation to host multiple "sites", but it's still one installation, one single database. All of the posts, all the pages, they're all stored in a single database and if you got into that database you could easily include a page from one site on another just by editing some fields in the database. It's not designed for reselling or for multiple, completely separate entities. There are a whole host of security risks in doing that sort of thing. It's designed for single entities that want to split their sites up into multiple sites, but where it's all one company, or related companies. Universities with different departments is one example I read about before, each department has their own "site" and the main IT office has a super user that can access all of them as it's on one single installation.
I could do with a little more information on what you're trying to do, but it sounds like you're trying to do something like WPEngine, where they sell hosting space and install WordPress for you. But they have dedicated servers that run scripts that create the config files and install WordPress on your own individual hosting space using their servers. That's known as SaaS (Software as a Service) and from the little you have said seems what you are trying to do. People subscribe to your site and get their own instance of the software you're selling that they access through an admin portal. That's not something they can install on their own hosting, they have to use yours. That's how most companies do this sort of thing.
I have SAAS type application and I am providing it service to many users.
It is developed using php.
I want to know which structure is better, right now I have subdomain structure, each group is different subdomain, though all uses same code from one source.
so it like
group1.domain.com
group2.domain.com
both uses single code but behave has separate application.
Another structure is also available in which we specify group in URL and not as subdomain like
domain.com/group1
domain.com/group2
My question is which structure is better in terms of scalability and security ?
do subdomain or url structure have any security issue ?
Which is better if we need to scale and use multiple server which will be better?
I'm not going to explore the full details about scalability and security, but there is an inherent difference about how the two URL types are handled which is basically the starting point for all other considerations:
Sub-domain routing is controlled by the DNS system and therefore can be routed without requiring any input from the server hosting the site. Changes to routing have a time-lag.
Path-based routing is controlled by the web server (e.g. Apache) and therefore needs to be handled by your server or infrastructure. Changes can be applied instantaneously.
Given that you can configure multiple sub-domains to point to the same server, anything you can do in scenario #2 you can also acheive via scenario #1. Therefore, the question is what advantages do you gain from using sub-domains and what are the disadvantages.
Advantages:
Routing is cheap, as it is handled via the DNS system.
Routing is flexible - it is easy to move a particularly troublesome user to their own server if they are impacting performance of other users. With path-based routing this would require additional infrastructure.
If you offer e-mail services, each client has their own sub-domain and therefore has no restriction on mailbox names.
This will allow you to have per-client SSL certificates, rather than a single certificate for all clients (though the latter is still possible).
Disadvantages:
Adding/removing new clients is harder to automate, as it requires a DNS update.
Changes take a short while to propagate, rather than applying instantly.
I wrote an app for my customer in Symfony2 and we went public with that. However, I am learning right now that he had a separate Wordpress app within previous server to manage some separate product.
Now, he asks that we transfer that WP app on a new server. Being all security in mind, I cannot feel but nervous about potential impact here. I am to have the following URL setup:
www.myclientapp.com
www.myclientapp.com/some-wp
What are my options here? I can think of some, but any suggestion would be helpful.
Buy separate shared hosting and put WP there. Then do redirection from our website.
My VPS server runs with nginx and php-fpm. Can I utilize separate pools which would run under different user. I would need to review access privileges to Symfony's files.
In any case I would allocate separate mysql user and database. Those wold be enforced by strict privileges which prohibit access to my primary database.
Can you guys think of anything else?
My primary goal is: If WP is vulnerable, let it be. Under no circumstances I would allow it to compromise my Symfony2 app. I am primarily concerned about configuration files (app/config/*.yml) which contain sensitive data.
I will recommend that you use something like a sub-domain eg wp.symfony.com.
They may still be hosted on the same server, but using different virtual host directories.
With that, the apps will never see each other.
A way is running symfony under a different php-fpm user than the WP website and make sure the file/directory rights are set correctly. Then a WP exploit cannot write/read to the symfony files depending on the directory/file rights.
A better way is to use the php config open_basedir and isolate the two sites into their own "jails" this way PHP prevents including/reading files from other websites. See http://php.net/manual/en/ini.core.php#ini.open-basedir for more information.
For this to work the code should be separated into different directories, you can use nginx aliases or virtualhosts to point the domainname to the correct directory.
I'm building an online dating website at the moment.
There needs to be an admin backend to the site to approve users/photos etc.
I can add this admin part of the site/login etc to the same domain.
eg: www.domainname.com/admin
Or from my experience with PHP CURL I can put this site on a different domain and CURL the requests through.
Question: is it more secure to put the admin code/site on a completely different domain? or it really doesn't matter if it sits on the same domain? hacking/security is the really point of this.
thx
Technically it might be more secure if you ran it from a different server and hosted it on a subdomain using a different IP/vhost, or use a proxy mod for your webserver (see Apache mod_proxy) to proxy requests from yourdomain.com/admin to admin.otherdomain.com and enforce additional IP or access control using .htaccess or equivalent to access the proxy url.
Of course, if those other domains are web accessible, then they are only as secure as the users and passwords that use them.
For corporate applications, you may want to make the admin interface accessible from a VPN connection, but I don't know if that applies to you.
If there is a vulnerability on your public webserver that allows someone to get shell access, then it may make it slightly more difficult to get administrative access since they don't have the code for the administration portion.
In other words, it can provide additional security depending on the lengths you go to, but is not necessarily a solid solution.
Using something like cURL is a possibility, but you'd have far less troubleshooting to do using a more conventional method like proxy or subdomain on another server.
I'm currently building a simple web application in PHP that other company's can use as one of their services. I want to host the application myself and not install it on one of their servers, but i do want the accessibility that that would offer. Example:
www.mywebapp.com is where i would host the web application.
www.company.com would be the domain name of the client.
webapp.company.com should redirect to www.mywebapp.com/?c=company. Upon navigation, webapp.company.com/view.php?v=test would also be redirected to www.mywebapp.com/view.php?c=company&v=test and so on upon further using the web app.
Can someone explain how i can achieve this and if this is the best option considering my requirements?
I recommend that you switch to implementing an API. That's how this problem is solved by many corporations. They simply have an API key that will let your server know what client they are and therefore what to serve them.
Resources on API's:
Google Tech Talk: http://www.youtube.com/watch?v=aAb7hSCtvGw [1:00:19 long]
http://blog.programmableweb.com/2011/01/06/from-the-trenches-web-api-design-best-practices/
Directory of some existing API's: http://www.programmableweb.com/apis/directory
I think your idea IS possible if both servers are set up correctly, but doesn't it feel wrong to you?
You would need to have an 'a' record for both domains pointing to the same server
http://corz.org/serv/tricks/htaccess2.php?page=all#section-rewrite_sub-domains