What is bootstrap.php? I got a project that in the .htaccess reads SetEnv AE_BOOTSTRAP /full/path/to/_app/bootstrap.php
However, that file does not exist in the project... Is this something from PHP?
No, bootstrapping is not a part of PHP. Rather it is a file that is generally ran at installation time, or with PHP for every request, that takes care of making sure everything is included and general startup procedures are taken care of.
You can find more information about BootStrapping here .
It's not a PHP feature but just some code that is executed at the start.
With regards to computer technology, “bootstrap PHP code” means creating a bootstrapper that handles all the dynamic requests coming to a server and apply the true MVC (Model View Component) framework so that in future you can change the functionality for each unique component or application without changing the entire code or application.
This file should be on the server otherwise, nothing can be assigned via code...
bootstrap.php is just a conventional name for a PHP file that loads up your project environment. If you have a .htaccess that's pointing to one that doesn't exist, that sounds like garbage left over from a dead software installation.
That's probably a line from a previous (or current) php framework, which would use that constant to define the path to their bootstrapping script.
A Bootstrap is a script consisting of multiple clasees definitions in a single file, to reduce overhead of large variety of classes.
Related
I've been recently learning about REST APIs (concretely using MySQL and PHP) so it's hard for me to understand basic concepts since most of the sites I check have more advanced solutions.
My doubt is the following: I know that an endpoint is the place where we get the data, but I'm not sure about the URI format, sometimes I've seen it as a php file path and other times it doesn't have an extension, but I don't know which one is correct, or if both are.
In case the URI format has no file extension (like performing a GET in the endpoint /api/update), do I forcefully have to have a "controller" file to which all the URIs are redirected and treated depending on the case, or is there a better way to handle them?
I've also been asked to make a script to run a backend app and a frontend and backend app, as in a script that will execute everything when launched (calling other scripts if necessary and so on) but I don't know what they mean exactly by that or how to do it. I thought that having a index.php (for example) in which you can have a couple of buttons that would trigger the requests was already it but it's not, so what is it exactly?
Sorry for the basic questions but I've looked many solutions in here and other websites and I still can't grasp the concept.
Thanks in advance.
The answer to this question is yes. Common practice is to have a PHP application use the front controller pattern, where a single publicly available script (usually index.php) is solely responsible for delegating all incoming requests to the appropriate part of your application (your actual "controllers"), often relying on server configuration to do the actual "redirecting" (rewriting, allowing for omitted file extensions and "pretty url's"). This design approach is common because most popular frameworks support it out of the box, from the Laravel and Symfony big boys, to microframeworks like Slim, Silex and Lumen. Perhaps giving these frameworks a try will help you understand how this works and how they do it.
Not sure if I understand your question correctly, but it sounds like you are being asked to provide/implement a deployment script; a script that runs a set of commands in order to easily install, bootstrap and start the entire application. Think of commands like composer install, commands that initialize/seed the database, or commands that build your frontend assets. The actual commands are specific to the application, but the goal is to easily provide a fresh installation and deployment of your application by executing a single script. These scrips are usually sh scripts executed from the command line.
Going to try and mess around with forms of secure login now, and the php files that connect to the database are going to be stored above the web root, public_html, so they cannot be publicly accessed.
My first question is that people are saying you cannot invoke this php file with Javascript.
That makes sense because Javascript runs client-side and could expose information, but this leaves me a bit confused on how to invoke this php file securely.
Should I have another php file below the web root that invokes the content-sensitive one above the web root?
Would this be achieved with "../../some-folder-above-web-root/some-php-above-web-root.php", and if so isn't that revealing to the location of the php file in the web root? Or doesn't it's location matter since people cannot access it (.. hackers).
All in all I really just want to know how to communicate to a script above the web root, properly and securely.
Yes, you are correct. There should be a PHP file below the web root that will access the secured PHP files above the web root. In Zend Framework, there is a single index.php file, called the bootstraper, which does many things including:
set the error display level
set the include paths
define global constants
read the configuration files
load the library classes
get the front controller
configure the database connection
determine the route, per RESTful url's, and MVC
set Exception handling
call the requested controller
I would highly suggest using an MVC framework, they are industry standard, and have pre-built functionality for many common problems including secure logins. Zend Framework implements Access Control Lists style security, though you can easily role your own. Other notable frameworks are Drupal, Yii, Codeigniter, Symphony, CakePHP, and Joomla.
Other best practices for security are:
filter all file uploads based on mimetype, NOT file extension or filetype
filter all POST and GET data, based on the database table column type and length
sanitize all SQL strings before running them
change all the default login passwords on your servers, ex: Apache, MySQL, FTP, SSH, SVN, etc.
learn how to configure php.ini, httpd.conf, etc.
disable any services, modules, and plugins, not being used in your framework, PHP, Apache, and MySQL
fuzz your code
use unit tests
learn a bit about penetration testing
you can give those files READ ONLY permission for other, something like 754 (all permissions for root, read and execute for group, read only for other) for example, then you can read its contents using for example file_get_contents and a absolute path.
A common way to do this is have a config file (with the sensible info inside) outside the public web dir, read it using a absolute path, and then use it as variables.
If you want to EXECUTE a script outside the public web path you have to give EXECUTE permission to 'other' which isn't much secure.
Also regarding your question about javascript, it ins't about security: javascript code won't be executed in the server, where the file with sensible info is, it will be executed on the client browser, so there's nothing to read there.
I have a series of web sites all hosted on the same server with different domains. I want to host some common PHP scrips and then be able to call these from the other domains.
Im am a bit fresh with my php so pls excuse code attempts - I have tried iterations of the following which may try and help you understand what I am aiming for!
from within php tags ...
include('http://www.mydomain/common_include.php?show_section=$section');
$show_section = $_GET['show_section'];
include('http://www.mydomain/common_include.php');//Then $show_section would be available to the included file/cod
Finally I have tried pulling in the include which contains a function then trying to run that include from the parent script.
I would much prefer to keep this PHP
orientated rather than getting
involved with the server (file
systems etc (but I can change
permissions etc)
I can but would prefer not to just upload the same library to each of the domains separately
I understand PHP is run on the server hence maybe problematic to include scripts across onto another server.
Thanks in advance.
#
EDIT
OK OK - I get that its bad practice so will not do it....THANKS VERY MUCH FOR THE QUICK ANSWERS.
However is there any other recommendations of how to esentially show this basic php app on all of the sites with out haveing to add the files to the root of each site? Just to prevent massive script duplication...(thinking out loud call the scripts in from a db or anyother soloutions)
Again thanks for your assistance
That would be a huge security risk if you could just include remote PHP files to your own projects. The PHP gets parsed before the server sends it to you so cross-domain includes would only contain the output the script generates. The only way to include PHP files so that they can be executed is via local filesystem.
If you look at PHP.net's documentation about include, you can find this:
If "URL fopen wrappers" are enabled in PHP (which they are in the default configuration), you can specify the file to be included using a URL (via HTTP or other supported wrapper - see List of Supported Protocols/Wrappers for a list of protocols) instead of a local pathname. If the target server interprets the target file as PHP code, variables may be passed to the included file using a URL request string as used with HTTP GET. This is not strictly speaking the same thing as including the file and having it inherit the parent file's variable scope; the script is actually being run on the remote server and the result is then being included into the local script.
Which pretty much explains the whole thing.
The root of the original question seemed to be the poster's concern about using a PHP script or plugin on multiple sites and then having an onerous task each time it needs to be updated. While trying to include PHP files across sites is a bad idea, it is a better plan to structure your script to be as self contained as possible. Keep the entire plugin contained in one directory.... and ensure your function calls to utilize it are as well formed as possible - clean, well named functions, uniform naming conventions and a well thought out plan for what parameters each function needs. Avoid using global variables.
Ideally you should then have quite an easy time each time you need to update the plugin/script in all locations. You can even set up an automated process that will upload the new directory containing the plugin to each site replacing the old one. And the function calls within your code should rarely if ever change.
If your script is big enough you might implement an automatic update process like the more recent versions of Wordpress use. Click a button and it updates itself. In the past, updating a dozen sites running Wordpress (as an example) was a massive pain.
That is very bad practice.
Actually you're including not PHP but just HTML code.
Include files, not urls. It is possible for the same server.
Just use absolute path to these files.
Apart from the fact that it's a bad practice you should first check if include allows URLs if you really want to do that.
If however all the sites that need to use the script, you could put the script somewhere in a directory accessible by the user that executes php and add that dir to the php.ini include_path property (can also be done at runtime)
(Or you could create a php extension and load it as extension)
If you have root rights on that server, you could just use absolute path from filesystem root, but most hostings won't let you do this.
I have a custom built application framework written in PHP which I have been tasked to optimize. This framework is a shared codebase which loads MVC "modules" to provide various functionality. Each module is a directory containing multiple PHP classes for controllers and models and PHP files for views.
The entire framework loads for almost all requests, including images and stylesheets. This is because the modules are designed to be self contained packages, and they may contain images, stylesheets, javascripts or other static files within them. Because of this, there is overhead in serving what would normally be a very simple request because the system has to load all the modules just to determine what modules are available from which to pull static files.
The general process for handling any given URI is as follows:
All base system classes are included
A global exception handler and some global variables are set
A system-wide configuration file is read. (This is a file filled with PHP statements to set config variables)
A connection to the database is made
The modules folder is scanned via opendir() and each module is verified to be valid and free of syntax errors, and then included.
A second configuration file is loaded which sets up configuration for the modules
A new instance of each module is created (calling it's __construct() method and possibly creating other database connections, performing individual startup routines, etc)
The URI is examined and passed off to the appropriate module(s)
Steps 1 - 7 will almost always be exactly the same. They will always perform the exact same operations unless new modules are installed or the configuration file is changed. My question is, what could be done to optimize the process? Ideally, I'd like some sort of way of handling multiple requests, similar to the way KeepAlive requests work. All the overhead of initializing all modules seems like a waste just to readfile() a single image or css file, just to have that same overhead again to serve another request.
Is there any way to reduce the overhead of a framework like this? (I don't even know if anyone can help me without studying all the code, this may be a hopeless question)
It's generally a bad idea to tie up a dynamic web server thread serving static content. Apache, IIS, Nginx, et. al. already do everything you need to serve up these files. If each static asset is located somewhere within the public docroot and has a unique URL, you shouldn't need to worry about PHP being involved in loading them.
Furthermore, if you can ensure that your cache-related headers (ETag, Last-Modified, etc.) are being generated correctly, and each client should only request each file once. Free caching == win!
Is there a reason all of the modules need to be loaded for every request? Why not allow controllers to specify which modules they require to be loaded, and only load those which are requested?
Why not move step 8 before step 5? Examine the URL first, then load modules based on the results.
Another one:
each module is verified to be valid and free of syntax errors, and then included.
Are you really syntax checking files before including() them? If so, why is this necessary?
I was going to ask what the best way to do this is, but then decided I should ask whether or not it is even necessary. I have never seen it done in JSP development, but it appears to be common practice in PHP. What is the reasoning behind this, and if I do not protect against this, what else should I be taking into consideration?
The reason this is more common in PHP than other similar languages has to do with PHP's history. Early versions of PHP had the "register_globals" setting on as a default (in fact, it may not have even been a setting in really early versions). Register_globals tells PHP to define global variables according to the query string. So if you queried such a script thusly:
http://site.com/script.php?hello=world&foo=bar
... the script would automatically define a variable $hello with value "world" and $foo with value "bar."
For such a script, if you knew the names of key variables, it was possible to exploit the script by specifying those variables on the query string. The solution? Define some magic string in the core script and then make all the ancilliary scripts check for the magic string and bail out if it's not there.
Thankfully, almost nobody uses register_variables anymore, but many scripts are still very poorly written and make stupid assumptions that cause them to do damage if they are called out of context.
Personally, I avoid the whole thing by using the Symfony framework, which (at least in its default setup) keeps the controllers and templates out of the web root altogether. The only entry point is the front controller.
If you include everything from outside web root then it's not an issue as nothing can be loaded directly.
Well, This is to prevent sensitive includes from being sent to the web-server directly. It's certainly not an all-inclusive security measure, but it could help with your particular setup.
If however, your user was in a position to include the file from their own script, it won't help at all
I emit a 404 page, not as a serious security measure but only because I don't like leaking information about the internals of a site, even the names of internal files.
But if the file just contains functions then there's no real harm in omitting the check.
It also isn't just a security feature in php but more of how many MVC based PHP sites function. If for example in SugarCRM you were to call a module file directly the page load would fail because the controller, view and model were not previously loaded and you'd have no db config/connection information either, so to make sure all dependencies are loaded the users is forced through a known entry point - i.e. index.php
I just found an approach in the .Net MVC system that you could replicate for PHP using Apache Rewrites, .htaccess files or if you are using IIS, a web.config file.
As the MVC pattern doens't need the user to directly access aspx files these are not served and a 404 is sent instead. If you have a naming convention for included files "inc.php" for example you could redirect *.inc.php requests to a 404 for specific folders - in Apache Rewrite supply R=404 at the end of the rule will return that HTTP status to your client.
Some of these examples may help: Apache Rewrite Examples
As already mentioned in some of the other answers, you shouldn't need to do this. If a file isn't supposed to be served up by the web server, you shouldn't leave it within the web folder. Includes should be placed in a directory outside the web root.
Apart from that, the proper way to tell the user that a page doesn't exist, is by emitting a status 404, using:
header("HTTP/1.0 404 Not Found");
exit;
If you don't do this, it is hard for non-humans (Eg. search-engines) to distinguish between a regular page and a non-page.
This is very important because if you are editing your site running Google Toolbar, it will find your inner php files and then put them into search results. At best this will create an awkward experience for users but if you are a sloppy programmer, could reveal database connection information.