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.
Related
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 have one site completely working for one client , now I have some more clients want same thing replicated for them , Is there any way , that I can use this site as base site , as I plan to access this site from there domain and providing database for each client.
I am using PHP and MYSQL.
Thanks for any support , I appreciate your point of view also in this process. do I have right approach
I have been told that there will be SEO issues if I use one site for multiple domain. I have no competent person available which can direct me on domain name linking. I have www.xyzuniversity.com and 85% data is fetching from database. now i have to create abcuniversity.com and I want that I just create new database and ready to use and I think I can make multiple sites like this , if I succeed
Thanks
You can point multiple domains to the site. You can get the domain name from the server vars ($_SERVER['HTTP_HOST']) and choose you database through that. Make sure you dont have any absolute links.
Put the shared code into a shared directory and give each domain it's own database configuration, so the database configuration is not shared.
Then start your application with the different configuration based on the domain, e.g. by server environment variables like the hostname.
If your design does not support a configuration that can be injected into the application, you need to maintain two code-bases, one for each domain, e.g. in source-code control with one branch per domain.
However I suggest that your code is that modular that it supports configuration for the parts that need configuration according to your needs. If it's not yet, think about coming closer to it and make the changes.
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.
I am using php/mysql on linux servers. I want to create a user sub domain for each user upon sign up. For instance, john doe --> johndoe.example.com
The issue is, we are going to allow customizations such as adding custom features for clients wanting customizations. So, is it better we automate the process or manually create sub domains for clients requiring customizations and let other users just use basic login?
And how can i automate the process if need be?
Instead of creating subdomains, have a wildcard subdomain which is mapped into one folder and with PHP figure out which user's data you want to show.
If you are using a cPanel hosting, creating a wildcard subdomain should be pretty easy and wont require any manual adjustment to the httpd.conf file. Otherwise whenever you will add individual subdomains Apache will be restarted in the background, which is not at all good.
I rephrased my answer for clearer understanding.
We are about to begin work on an application that will eventually be deployed many times on one server. I am hoping to build a nice interface so that one of my coworkers can easily create new deployments of this application. The idea is to create a wizard with a series of options that will configure basic properties of each particular copy of the app such as color scheme, domain name, etc. Each copy of the application may be further tweaked independently down the line. I would like to know what is the best way to manage the automatic creation of users, the updating of domain name info and the deploying of copies of an application, with the ability to maintain certain discrepancies between each of these copies (such as installed plugins, different CSS) as we update the application in the future.
What I'm asking is extremely similar to the way StackExchange 1.0 functioned, where a user could configure several options and a customized version of the StackExchange would soon be up and running. How is this accomplished?
One thing you can do is have the web server set a variable based on the domain name and path, and then you can check $_SERVER for the value and choose the configuration based on that. Or if the application will only be run once per domain then just check $_SERVER['HTTP_HOST'].