I just noticed a PHP config parameter called allow_url_include, which allows you to include a PHP file hosted elsewhere as you would a locally. This seems like a bad idea, but "why is this bad" is too easy a question.
So, my question: When would this actually be a good option? When it would actually be the best solution to some problem?
Contrary to the other responders here, I'm going to go with "No". I can't think of any situation where this would make a good idea.
Some quick responses to the other ideas:
Licensing : would be very easy to circumvent
Single library for multiple servers: I'm sorry but this is a very dumb solution to something that should be solved by syncing files from for example a
sourcecontrol system
packaging / distribution system
build system
or a remote filesystem. NFS was mentioned
Remote library from google: nobody has a benefit to a slow non-caching PHP library loading over PHP. This is not (asynchronous) javascript
I think I covered all of them..
Now..
your question was about 'including a file hosted elsewhere', which I think you should never attempt. However, there are uses for allow_url_include. This setting covers more than just http://. It also covers user-defined protocol handlers, and I believe even phar://. For these there a quite a bit of valid uses.
The only things I can think of are:
for a remote library, for example the google api's.
Alternately, if you are something like facebook, with devs in different locations, and the devs use includes from different stage servers (DB, dev, staging, production).
Once again during dev, to a third party program that is in lots of beta transition, so you always get the most recent build without having to compile yourself (for example, using a remote tinymce beta that you are going to be building against that will be done before you reach production).
However, if the remote server goes down, it kills the app, so for most people, not a good idea for production usage.
Here is one example that I can think of.
At my organization my division is responsible for both the intranet and internet site. Because we are using two different servers and in our case two different subdomains then I could see a case for having a single library that is used by both servers. This would allow both servers to use the same class. This wouldn't be a security problem because you have complete control over both servers and would be better than trying to maintain two versions of the same class.
Since you have control over the servers, and because having an external facing server and internal server requires seperation (because of the firewall) then, this would be a better solution than trying to keep a copy of the same class in two locations.
Hmm...
[insert barrel scraping noise here]
...you could use this is a means of licensing software - in that the license key, etc. could be stored on the remote system (managed by the seller). By doing this, the seller would retain control of all the systems attempting to access the key.
However, as you say the list of reasons this is a horrifying idea outweigh any positives in my mind.
Related
I just read the Twelve-Factor App, which looks like a pretty comprehensive set of rules to apply in a web-based application. It uses python or rails in its examples, but never php... I was wondering which factors of the manifesto can be applied to PHP projects and how?
Thanks
Short answer:
All points apply to PHP as the twelve factor app manifesto refers specifically for web apps.
PHP has a very hard time complying to twelve factor, in particular in the items 2, 7, 8 9 (as a side effect of 7 and 8) and 12 (partially). Actually that's the first really grounded argument I have heard in the whole "PHP sucks" rant that is common on the Ruby and Python communities (don't get me wrong, I think Ruby and Python are better languages, but I don't hate PHP, and definitively hate the "my language is better" rants.)
Being that said, it may be that your PHP project is not a web app or SaaS, but just a simple website, so you may just deem that twelve factor is not a need.
Long answer: A point-by-point analysis would be:
Codebase: not an issue
Dependencies: the way PEAR works goes quite against this point, as pear dependencies are installed system wide and usually you don't have a consolidated manifesto to declare them. Is also usual for a PHP setup to require you to add packages to your OS installation to get some libraries available. Finally AFAIK there isn't a tool in PHP to provide isolation like "virtualenv", "rbenv" or "rvm" (or if it exists is not popular among the PHP community) Edit: Composer (http://getcomposer.org/) seems to do the right regarding dependencies, it still doesn't isolate the PHP version, but for all the rest it should be fine.
Config: some PHP frameworks are not very well suited to do this, but there are certainly others that do well, so it's not a flaw of the platform itself
Backing Services: shouldn't be much of an issue, despite maybe having to hack some frameworks a little in order to manage the services as resources
Build, release, run: this is totally appliable to PHP as this definitively doesn't concern only "compiling". One may argue that several projects and hosting platforms on the PHP community abuse of direct FTP, etc. but that's not a flaw of PHP itself, and there is no real impediment on doing things right regarding this item.
Processes: This definitively concerns to PHP. PHP is quite capable of running purely stateless processes (the emphasis is on the word stateless), and actually several frameworks make your life easy for it. For example, symfony provides out-of-the-box session management with memcached or database storage instead of regular sessions
Port binding: Over simplyfing it, this point basically demands you to reverse proxy and have the actual webserver embedded on the app instead of being a separated component. This puts PHP in a very hard position to comply. Despite there are ways to do this (see the reply about using PHP as FastCGI) that's definitively not the most common nor the best supported way to serve a PHP app as it is on other communities (e.g. Ruby, Node.js).
Processes: This is not impossible in PHP. However several elements put PHP in a hard position to comply. Namely the lack of good support for items 6 and 7; the fact that the PHP API to spawn new processes isn't really very nice to work with; and specially the way Apache's mod_php handles their workers (which is by far the most common deployment schema for PHP)
Disposability: If you use the right tools there is nothing inherent on PHP to prevent you from creating fast, disposable, tidy web and worker processes. However I believe that since the underlying process model is hard to implement as per points 7 and 8, then 9 becomes a bit cumbersome as a side effect
Dev/prod parity: This is very platform agnostic, and I would say one of the hardest to get done right. PHP is no exception to this rule, but it doesn't have a particular impediment either. Actually most of the tools named on the manifesto can be applied to a PHP project
Logs: Having your app agnostic of the log system on the execution environment is totally doable on PHP
Admin processes: The most important flaw of PHP regarding this point is its lack of a REPL shell. Regarding the rest, several frameworks like Symfony allow you to program admin tasks (e.g Doctine-based database migrations) and run them on the same environment as your "regular" web envionrment.
Since the PHP community is evolving, it may be that it has already righted some of the wrongs mentioned.
Build, release, Run: Applicable to compiled code which is not the case in PHP. So this
point is not something you need to look at.
I don't claim any authority on this 12 factor stuff, but my read of that section is that the author would disagree. It's not just about compiling, it's about managing dependencies both in the small (the snapshot of the code) and in the large (any libraries the code uses).
Imagine you're a new dev and they say, "Okay, this is a custom php app, so...
a) The custom code is really two subprojects, which are in repo A and repo B.
b) You'll need to create a directory layout like so, and then
c) check the code for each subproject out into this subdirectory and this subdirectory.
d) You'll also need these three open source PHP libraries:
version 3.1 of library Foo,
version 2.3 of library Bar, and
version 5.6 of library Bat.
e) download them from their home project sites and unpack them, then copy them into this directory, that directory, and the other directory.
f) then you'll need to set these configurations in the external library,
g) and these configs in our two custom code projects.
h) once that's all done, tar/gzip it all up, upload it up to the QA server and untar it into htdocs.
There's no compiling going in that set of steps, but you can bet there's a lot of building.
Getting all of that set up and working is the build step.
Using tar/gzip to take a snapshot of the working build is the release step.
SCP'ing/unpacking it into the QA server's htdocs directory is the runtime step.
You might say that some of those steps above are unnecessary - the libraries should be deployed at the system level and merely imported. From the 12factors.net site I'd say the author prefers you to import them uniquely and individually for the app. It sidesteps dependency versioning problems at the cost of more disk space (not that anybody cares). There are more hassles in managing all those dependencies as local-to-the-app, but then that's the point of the build/release/runtime scheme.
It might have changed since you read it - there are a few PHP examples now, although a few of them seem like negations of the twelve-factor concept.
One of the ways that normal mod_php sites violate twelve-factor comes with VII. Port binding. From the manifesto:
The twelve-factor app is completely self-contained and does not rely on runtime injection of a webserver into the execution environment to create a web-facing service. The web app exports HTTP as a service by binding to a port, and listening to requests coming in on that port.
However, apache/php can be coaxed into this worldview with something like this:
https://gist.github.com/1398498
Not perfect, but it works for the most part. To test it out, install foreman:
gem install foreman
then run it in the directory you cloned the gist into:
foreman start
then visit
http://localhost:5000/foo
DO NOT TAKE THIS POST AS A REFERENCE, THIS WAS WRITTEN IN 2011, MANY THINGS HAVE CHANGED SINCE THEN... THE WORLD OF PROGRAMMING IS IN CONSTANT EVOLUTION. A POINT OF VIEW OF 2011 IS NOT NECESSARILY STILL VALID IN 2018.
I just read a few lines of each points and here goes my analysis of the document:
Codebase: Everyone, php or not should have a codebase even for the little projects
Dependecies: PHP uses includes and code libraries that you should always be able to port easily by simply copying the code to a server. Sometimes you use PEAR and then if the server doesn't support it, you have to copy and install pear manually. I use Zend Framework most of the time, so it's just copying the code of the framework with the ftp upload.
Config: It is common for php apps to have a writable config file that you store configurations into. Where you store it is your choice as a developer, but it is usually either at the root of your app or in a settings/config folder.
Backing Services: PHP does use backing service most of the time such as MySQL. Other common services depending on your app are twitter and facebook. You use their API to communicate with them and store/retrieve data to work with.
Build, release, Run: Applicable to compiled code which is not the case in PHP. So this point is not something you need to look at.
Processes: HTTP is stateless and is SERVED,thus, you usually have no process apart from the web server. This is not entirely true as a webservice may be bundled with applications you package with or create for it. But, for the sake of standards, you usually don't have to use processes in the web world.
Port binding: PHP doesn't apply to port binding at all because it is not a process that hooks to an address, Apache, NGinx or Lighttpd does that for you. Reading #6/7 makes me understand that a website could never be a Twelve-Factor app.
Concurrency: Again this point treats about processes which do not apply to PHP web pages. This point applies to the server serving the content.
Disposability: This point discusses about how fast a process should be. Obviously, PHP web sites not being a process shouldnt apply but always note that your website should execute pages as fast as possible... Always think about this block or that block of code and see if it is optimized.
Dev/Prod Parity: This point is crucial in any app development. You never want to have a large gap between two app versions or upgrading can become a hassle. Furthermore, never create client specific versions of an app. Always find ways to allow your app to be configured/customized at the template level so you can keep your app as close as possible to all installed versions everywhere.
Logs: Logs are always a good thing to have, they allow you to follow the process of your code without having to output it to screen. My favorite tactic is to "tail -f logfile" inside of a linux console and look at what is happening as i execute my code.
Admin processes: Not applicable, in php, you don't have processes, but you do have pages that you can secure with usernames and passwords.
Where i begin to work, they are using a Remote Desktop Conection, to transfer files and manage the server, but that seems to me really insecure and a good way to cause errors and take down the apache/php/mysql stack.
I was proposing FTP to transfer files more easyly (and secure compared to the other way) but started reading about php deployment. It seems pretty easy on Linux, but on windows i havent found out wich is the best way to do it..
So far i think git on the server, and comit to it from the developer is my best shot, but what about database deployment?
Phing/jenkins/capistrano seem overly complex.. but will try if you guys think is good
The approach I am using is database migration scripts. They look like this
db-update-001.sql
db-update-002.sql
I have a script which sequentially executes them and creates *.ok file for each if it's successful. *.sql files contain "alter" statements and are stored in Git. The .ok files are not stored, so if you distribute changes, you need to imprint only those without .ok files.
I use this file: https://github.com/atk4/atk4/blob/master/tools/update.sh
but since you are in MS environment, you might need to do something different.
While MSRDP is not the most secure protocol around, its a very long way aead of FTP.
FTP is intrinsically insecure - it sends passwords as clear text. It's also a PITA to manage across a stateful firewall even where you can ensure consistent PASV behaviour.
However you do need a method for transfering files which can be scripted / automated.
I'd go back and have a long hard look at the available deployment tools - I can't comment on how well the other products compare with phing, only having used the latter - however mostly I've used stuff developed in house.
Since you really should be using a version control system - I'd recommend considering using it as your file delivery mechanism too.
I am using wamp server to develop a website using php, mysql, PDO, html and css.
My wamp server is using PHP 5.3.5, MySQL 5.5.8 and Apache 2.2.17, I am also using InnoDB for transactions.
Considering that my internet hosting provider has at least these versions of php, mysql, apache, and supports InnoDB will the website I build act in the exact same way.
Is it possible to design a website in wamp and then expect several errors when going live? And if so how is this overcome?
Thanks.
As others note, there are many potential hiccups (but I view them as learning opportunities.) But I've done it this way for over five years and have yet to find a difference that wasn't easily overcome. Just stick to the middle of the road, use defaults as much as makes sense, and have fun. It's a great way to explore the platform.
There are many things that can go wrong, most of them having to do with how the web server and PHP are built and configured.
The simplest example is PHP's safe mode: there are many things that safe mode does not allow, and turning it off may not be an option if you are on a shared host. Another example is which extensions are enabled in PHP (your app may require one which the host does not have).
Of course this is all moot if you rent the whole server (or a VM), as in this case you will be able to do whatever you please.
For completeness, I have to mention that there might be platform-specific differences in behavior resulting from the same library (which PHP uses to provide some functionality) compiling into different behavior on different platforms (think platform sniffing in C with #ifdef). I have been bitten by this in the past, but the possibility is not large enough to worry about it beforehand.
A lot of the issues can be worked around by moving constants into config files, like Jon says. Some issues will be less in your control and harder to diagnose. For instance, the output buffer control may be configured differently outside the DocumentRoot you have access to. This can cause confusing problems when you try to write headers out when other content has already been sent out. Similar issues with the timeout numbers, etc.
I am planing to build a website using PHP to be hosted on the public internet with decent user load (between 1000 to 5000). I am using FreeBSD as a server and I configured Apache, PHP and MySQL from scratch.
With proper configuration, is it safe to use such a server, or should I go with some web framework? I am asking as I've heard few horrible things about PHP.
If it is safe, does PHP get too complex when the size of the site increases beyond a certain point?
I know Facebook uses PHP; are there any other big websites that use PHP?
Last, is it recommended to use some PHP framework or should I stick to plain old PHP?
PHP works fine for just about any size server. The question isn't really the programming language but the infrastructure you set up. 1000-5000 users is not very many unless they are all banging on the site at the same time. Are they doing a lot of DB queries or consuming a lot of CPU resources? If so, then you may want to look at a dedicated MySQL server for the DB queries.
I have nothing against frameworks. However, you are usually shoehorning your problem into their solution. Careful design on your part with common routines, etc., are usually just as good as a framework in my opinion. However, some people are more comfortable working within a framework because it removes some of the plumbing issues.
A lot of large sites use PHP. It may not be obvious because they hide the extension of the scripts in the URLs.
With proper configuration PHP is fine. However if youre new to php and server administration you might want to read up on configuring php as well as Apache for security. Youll also need to read specifics on configuration for performance as well but you need to have an app to test before its really worth doing that beyond some basics.
As far as using a framework or just basic PHP that depends totally on you. a framework is othing more really than a set of useful code and structure to accomplish alot of tasks. If you dont use a framework youre going to have to write code that meets similar requirements, so you might save time using a framework. Generally you are going to sacrifice performance in trade for having to design/write less code. You need to decide yourself if a framework (and which one) is right for the project.
In terms of sites that use php... There are a ton... Facebook, Yahoo Bookmarks, Daily Motion, parts of MySpace (at one time, not sure if its still the case), anything running Drupal or Wordpress... PHP is more than capable.
PHP is just a tool and choice of framework does not really makes your application secure or fast, unless you understand the principles of web security and how things works.
Facebook is good example of what php is capable of in hands of processionals. And there are plenty of websites that capable to handle 10K visitors a day on a single low end server.
With the current issues with Network Solutions sites being hacked, I'm in need of a tool (preferably freeware) that I can install into my site and it will email me the second a file change/update occurs.
Any recommendations welcome :)
This site is on a shared server hosting package.
You can't install a true IDS on shared hosting, this is the host's responsibility.
An hack-ish solution:
You could create a script that ran periodically (using cron or some other mechanism), that would checksum all files, and compare the checksums with a previously stored record, then notify you if there are differences.
To find out if your script itself was deleted by the attack (1), you must also create a script sitting on a remote server (something like Google App Engine, perhaps), that pings your shared-server-script, and checks if it gets an expected result (a hash based on given time, perhaps) – if not, it emails you.
(1) This is actually quite unlikely, most attacks don't delete files
http://www.la-samhna.de/samhain/
However this won't work on shared hosting, so you'll need either a vps or a dedicated server
I've used Tripwire before. It worked really well. ...its not freeware.
You could find some good options by searching the term "IDS" or "Intrusion Detection System"
I second the suggestion of Joel L above - usually any cron job output is emailed to the address you pick when you set up the cron job.
If you rarely change themes or plugins, then this is a good way to go.
When you do make a change, you can just update the "baseline" checksum values.
I need to check out the mute screamer plugin, though, that may be best.
The best free and open source Intrusion Prevention System (IPS) for web application (as in a Web Application Firewall WAF) is Mod_Security. But no system will stop it all. Espically with Wordpress because it won a pwnie award for being so insecure. I would think seriously about ditching Wodrpess for any other blog engine.
Another option which is best suited if you are in a shared hosting enviroment is to use PHP-IDS. The name is a bit deceptive, its actually a regular expression based IPS. All of the regular expressions used by PHP-IDS have been ported to Mod_Security. Mod_Security provides a much better level of protection(ips) and logging(ids).
i originally wrote this in a comment on the rook's answer, but it might get lost in all that noise;
phpids indeed looks interesting as it can
be used in a shared server hosting
environment, which in general will
not be the case for tripwire or mod_security.
interestingly, there is a wordpress
plugin which nicely integrates (an
older version of) phpids in
wordpress, so that might be worth
looking into.
Rook: I think it is probably because WordPress security flaws get patched quickly once discovered. This do mean that anyone running an install must watch for new releases and install them as quickly as they can.
You could version the site with subversion/git/etc - doing a simple 'svn status' or 'git status' would allow you to tell if the source files had changed - however it obviously won't catch any modifications someone may have made to the database content, and it'll get a little messy when someone updates plugins (or wordpress itself) - as so much will have changed.
take a look at http://www.guardio.net uptime and file integrity monitoring