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.
Related
As you can probably tell, I am new to Magento2 and I am trying to figure out some of the basics. I'm a full-stack developer that is use to developing (frontend and backend) myself then using docker and finally hosting it on an AWS:S3/EC2 or AWS: Elastic Beanstalk. With that said, Magento seems like a completely different beast to conquer.
I have a family member who is wanting me to do some basic frontend stuff for their website (such as changing Navbar design and a potential home page overhaul later on), naturally wanting to help them out I agreed to have a look and see what I can do. I have access to their Magento 2 dashboard area and have been looking around with no sure luck thus far. I have researched online that Magento 2 allows for a "Page Builder" or a "WYSIWYG" type functionality. But I am unable to use these types of tools because my family member had the website built by a Magento 2 developer firm awhile back and everything is coded manually and could cause problems if using one of the above mentioned tools. Due to this I am trying to get access to their site directory so that I can go in and make the necessary changes and upload the files. But I am really struggling on how to access the codebase.
I have read that an admin needs to send me the code??? Or grant me access to the code or something along those lines? I do have the host, port, root, username, password, etc. for the live server but still having trouble.
Any help would be greatly appreciated.
You need to use ssh to access the server
ssh user#host -p port
After you get into the server, you should set up a git repository in the project root and push the code from the server to the repository, then clone the repo to your local environment.
From there on, it's the normal development flow. You can use a clean database with sample data or you can dump the db from the live env and use it on your local env, but this will require some changes in the db after the import.
Detailing all the steps required to do this task would take forever and would cover a lot of different issues/steps.
"I have read that an admin needs to send me the code???"
Not sure what you mean by this, but a Magento admin is just a user on the backend side of the website. He does not have access to any code.
A git repository admin(probably previous dev) could grant you access to the code repository, but this doesn't seem like an option.
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'm making an web application, it's a kind of online shop using PHP, jQuery, AJAX and JavaScript.
I want to launch my site on only one PC on local host. How should I set my site so that it only runs on my single PC?
Even if anybody copy my code files and database files to his/her own PC it should not run on their PC. How to do this?
The one way I know is by using the IP address. but I not quite sure about this method works or not.
If someone gains access to your source code then there is nothing that you can do to stop them.
When hosting it on your own you can prevent external access but beyond that there is nothing you can do.
You can use an encoder script to encrypt your source code, and some of these come with an ability to lock down to MAC address. I think they are all commercial solutions, though; start with IonCube and SourceGuardian. Zend might have something as well.
I would imagine each of these solutions would have comprehensive tutorials on their respective sites. Your workflow is basically to check out a copy of your source code from version control, and encode that folder as part of your build process.
Technically, encrypted code can be reverse-engineered, since the encryption key is built into the code. However, it is a lot of work for someone to do so, and even if they decode it, they won't have your comments or your meaningful variable/method/class names.
Make sure no one gains access to that PC (where your application resides). Only in that case you can protect your application from being run by unauthorized person. Once you take this security measure then you can easily disable your application from being accessed from any other LAN computers by using your IP. This is how professional servers works so should you.
You can change the webserver binding to localhost 127.0.0.1 only.
Alternative way you can create a filter rule that the server only accepts remote from localhost/127.0.0.1
With apache you can do this by .htaccess or directory/server rules.
When you want to share that code, you need to encrypt it with zend-guard or equal tools. there is also some licence management inside it, where you can bind licences to machines.
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.
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'].