We are working on a hosted CMS system that will serve multiple domains from the same database and codebase. We are building it with Symfony2, we have an idea on how to get the multiple domains working with dynamic hosts but I wonder if the Security Component would work with multiple domains and recognize different domain logins and sessions. Also how the Admins and Superadmins would login and work on managing all domains? For users I can save the domain or sitename with the user in the database but how will we get that into the session that the Security Component handles on it's own.
Please advise.
Thanks!
In short, yes, this should be possible– you may need to write a custom handler of some kind to synchronise the sessions using something not too dissimilar to the normal techniques you would use to achieve this in PHP.
You may find that you need to use a relatively recent release, 2.2 perhaps, I think this includes some stuff for multi-domain routing- which may be an issue.
With regards to admin/superadmin capabilities, assuming the above all should work as expected, just ensure all of your firewalls (if you have >1) operate on the same context, otherwise they will need to re-authenticate for each firewall.
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 a server on which I am using dokuwiki to host both a homepage as well as a wiki. The server is available under www.domain.com and the wiki is available under wiki.domain.com. Internally both subdomains are served from different directories.
However this means, that everybody who wants to sign up has to sign up for the both domains and manage a duplicate set of user accounts for both subdomains.
What I would like is to have a system, where anybody can sign up on both pages and only has to log in in any of the domains and get access. ACL should still be managed separately for both domains, since I might use namespace names multiple times.
I looked through the list oft dokuwiki auth plugins, but I was not able to find anything usefull for this purpose. Another idea would be to just soft- or hardlink the auth data directory in the two installations. However this would still mean users would have to log in multiple times. Also I am not sure whether my hoster actually allows such directory links, or if this might mess up the two installations.
Is there any other way to create such a setup?
A DokuWiki farm setup might help with having the same user database for both sites. Symlinking the user file is another way.
More complicated is to share the cookies between both domains. I'm not sure how to approach this best. Maybe others can offer some ideas.
Well since this is on the same server just across your various subdomains I would imagine you would want to store the user info including logins in a shared database so that no matter which app/subdomain you insert their registration data and query for their login info from the same database. Then it's a matter of using PHP sessions for keeping track of if they are logged in across subdomains. There is already a length stack on how to achieve that here:
PHP Sessions across sub domains
Try setting the Cookie Domain to .yourdomain.com
This means your browser will deliver cookies to subdomains of yourdomain.com.
So cookies will beshared among www.yourdomain.com and wiki.yourdomain.com
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 have two websites, one driven by ASP.NET and the other in PHP. The PHP site is hosted on a relatively inexpensive host provider ('unlimited bandwidth and diskspace for $10 a month). The PHP site also provides REST URLs which would help me in monetizing my website.
The other site (the 'main' site, as it were) is an ASP.NET website which houses the login mechanism. My goal is to allow users to log in to the ASP.NET site and then be redirected to the PHP based domain. Is there an easy and feasible solution that accomplishes this?
I have a few questions with regards to that approach:
How would I pass session information and variables from the ASP.NET Application to the PHP based application, to facilitate the aura of 'Single Sign On'?
Would a 'simple' cookie be able to handle this scensario? Or would I need to use encrypted query strings?
There is no 'sensitive' data on these sites, so securing user data isn't a top priority. The site was built 'for fun'.
Are there hosts that allow subdomains to be hosted on a different language platform than the main domain? If I had www.example.com hosted on an ASP.NET server, could I have a subdomain (forum.example.com) hosted on a PHP server? Is this possible?
Any help on this is greatly appreciated.
Although more complex, I would go with the same methodology as the OpenID spec and use the Diffie-Hellman exchange. This allows two parties with no prior trust, to establish a trust for a certain period of time.
Info for PHP
Info for VB.NET
I would go for a cookie if both sites are on the same domain. One advantage of cookies over encrypted strings is that they are automatically passed between requests and you don't have to think about them when building your urls. One downside of cookies is that they can be disabled by users.
Store the sessions in a database and create / use a session-type which is cross-platform. You might to do it yourself. But you should know that passing sessions etc between different languages like this, can be dangerous ( security-wise )