I'm very new to php and web , now I'm learning about oop in php and how to divide my program into classes each in .php file. before now all I know about php program, that I may have these files into my root folder
home.php
about.php
products.php
contact.php
So, whenever the client requests any of that in the browser
http://www.example.com/home.php
http://www.example.com/about.php
http://www.example.com/products.php
http://www.example.com/contact.php
No problem, the files will output the proper page to the client.
Now, I have a problem. I also have files like these in the root folder
class1.php
class2.php
resources/myFunctions.php
resources/otherFunctions.php
how to prevent the user from requesting these files by typing something like this in the browser ?
http://www.example.com/resources/myFunctions.php
The ways that I have been thinking of is by adding this line on top of every file of them exit;
Or, I know there is something called .htaccess that is an Apache configuration file that effect the way that the Apache works.
What do real life applications do to solve this problem ?
You would indeed use whatever server side configuration options are available to you.
Depending on how your hosting is set up you could either modify the include path for PHP (http://php.net/manual/en/ini.core.php#ini.include-path) or restricting the various documents/directories to specific hosts/subnets/no access in the Apache site configuration (https://httpd.apache.org/docs/2.4/howto/access.html).
If you are on shared hosting, this level of lock down isn't usually possible, so you are stuck with using the Apache rewrite rules using a combination of a easy to handle file naming convention (ie, classFoo.inc.php and classBar.inc.php), the .htaccess file and using the FilesMatch directive to block access to *.inc.php - http://www.askapache.com/htaccess/using-filesmatch-and-files-in-htaccess/
FWIW all else being equal the Apache foundation says it is better/more efficient to do it in server side config vs. using .htaccess IF that option is available to you.
A real-life application often uses a so-called public/ or webroot/ folder in the root of the project where all files to be requested over the web reside in.
This .htaccess file then forwards all HTTP requests to this folder with internal URL rewrites like the following:
RewriteRule ^$ webroot/ [L] # match either nothing (www.mydomain.com)
RewriteRule ^(.*)$ webroot/$1 [L] # or anything else (www.mydomain.com/home.php)
.htaccess uses regular expressions to match the request URI (everything in the URL after the hostname) and prepends that with webroot/, in this example.
www.mydomain.com/home.php becomes www.mydomain.com/webroot/home.php,
www.mydomain.com/folder/file.php becomes www.mydomain.com/webroot/folder/file.php
Note: this will not be visible in the url in the browser.
When configured properly, all files that are placed outside of this folder can not be accessed by a regular HTTP request. Your application however (your php scripts), can still access those private files, because PHP runs on your server, so it has filesystem access to those files.
Related
I'm currently coding an Admin Panel, and for the sake of organization, I've made it so that all of the pages are located in a sub-directory instead of the root directory and I want to access these pages in the sub-directory from the root link. For example, the index.php is in the root directory and is accessible from:
http://localhost/index.php
But the rest of the pages are located in a sub-directory like so:
//What the current link is
http://localhost/pages/page.php
//What I want the link to be
http://localhost/page.php
Some of my pages are in sub-directories of the sub-directory like so:
//What the current link is
http://localhost/pages/page1/page.php
//What I want the link to be
http://localhost/page1/page.php
As you can see, I simply want to eliminate the primary sub-directory from the link, which is pages.
I've looked around on the internet and from what I can tell, this is achievable through .htacess but I couldn't find anything that worked.
You certainly won't find a perfect solution you can simply copy and paste to solve all your tasks. That expectation is a strange on. Instead you are expected to actually understand how the tools you want to use work and to be able to find your own solution. For that there really are enough good examples here on SO and in addition there is an __excellent_ documentation of apache's rewriting module available with just two mouse clicks.
Anyway, her is a suggestion, you still may have to tweak it to your situation:
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/?(.*)$ /pages/$1 [END]
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
This rule will work likewise in the http servers host configuration or inside a dynamic configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a dynamic configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using dynamic configuration files (".htaccess"). Those dynamic configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).
I'd like to know if there is a way of changing the relative document root for extra security. I'll try to explain myself through the following example:
/root
/app
/public
Say an www.example.com request to the web server would point to the root folder.
I was wondering if there was a configuration, for instance through an .htaccess file located in said root folder, that would make the server point to the public folder instead, therefore having any remote paths always be relative to said public folder.
In this instance, www.example.com/app would request an app folder inside of public, instead of an app folder inside of root, leaving the latter to be inaccessible from a remote url request.
In the same manner, www.example.com/public would request a public folder inside of our root public folder and so forth.
I've read various topics like this one that mention using a custom .htaccess configuration to achieve something similar, but it requires the manual configuration of the request url in said file, while my intention is for it to work without further configuration no matter where you host the application.
Another possible solution I've seen is doing a hard redirect through the .htaccess file, which does not solve anything actually.
Feel free to edit this post as I might have had a hard time trying to get my point across.
You can use this simple .htaccess file:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_URI} !^/public/
RewriteRule ^(.*)$ /public/$1 [L]
</IfModule>
Any request on your server will point to the public folder.
Inside the public folder you can add an extra .htaccess file handling your site rules.
Also you can Host multiple sites on One webserver. You can combine making VirtualHosts and Alias using mod_alias mentioned before
In this example is suposed to have your own server (either dedicated or VPS)
By using Virtualhosts you can tell to the webserver when you recieve a request to www.example.com to serve content from a specific folder.
An example Virtualhost of it is:
<Virtualhost *:80>
ServerName ^domain_or_ip^
DocumentRoot ^path of the public folder^
DirectoryIndex index.php home.php index.html index.htm
ErrorLog ^path for a file containing php errors^
CustomLog ^path for logging whitch browser and ip visited your site^ combined
</Virtualhost>
I suggest that you point your server to the public folder anyhow, as it is much more secure, you could see that all frameworks behave the same way, they all have a "public" folder where the server points to.
In the public folder you have one point of entry to your scripts, like
index.php
and from this entry you will communicate with your application.
Of course you can still work the way you requested, and it will work great, but who knows maybe you will miss something and someone could access and view your "inner" files.
You're on Apache web server? If I understand correctly, you're looking for Virtual Directories. Usually, we have to put our web application inside the document root of Apache in order to make the application accessible from the network. However, there is a trick to make the web application still accessible even though we put it outside of Apache's document root. Please read up on that here: http://w3shaman.com/article/creating-virtual-directory-apache
Credits to W3Shaman.com, obviously.
I need to know if after creating the .htaccess file I have to call it within the index page, knowing that the main page is unique (only index.php) and all pages are taken from a database.
The web server that I use Apache.
The file with filename .htaccess is an extension to the webserver configuration (most commonly httpd.conf) that is loaded automatically by Apache when a file or script is loaded or executed in the directory, or any child-directories, where the .htaccess file is placed.
Furthermore, php scripts (or any scripts for that matter) have no knowledge at all of the existence of a .htaccess, nor should they care. They can be depended on configuration settings however, eg. any rewrite rules that pipe all incoming requests through a so-called front-controller (most commonly index.php), but they do not know of it's existence. Any configuration could also be placed somewhere else in the configuration tree.
For further info I'd advise you to read about Apache, or webservers in general, and learn how a common (http) request is fulfilled. It'll give you some understanding of what the .htaccess file exactly does, and does not, and how it is related, or unrelated, to any scripts.
You don't need to explicitly call the htaccess file from any of the php pages
htaccess rules will automatically apply to all the files and sub folders within the specific folder where htaccess file is placed
You cannot call the .htaccess file, it is an instruction set to the server on how to handle requests (amongst other things). You should place it in the root directory and Apache will look for it automatically when a request to the server is made for any webpage or other file.
You can also have a .htaccess flie in each folder (directory) to control requests specific to it.
I want to map URL in my localhost XAMPP into custom files.
For example:
localhost/index.php --> d:\xampp\htdocs\index.php (default)
localhost/normal/data.php --> d:\xampp\htdocs\normal\data.php (default)
localhost/view/userinfo.php --> d:\xampp\htdocs\view.php?p=userinfo (custom)
localhost/view/welcome.php --> d:\xampp\htdocs\view.php?p=welcome (custom)
So, basically, all URL that goes into inside view path will be mapped to view.php files with the filename.php (minus the .php) as its query parameter. There's actually no physical folder view, and no physical files userinfo.php and welcome.php inside the folder.
The reason that I need to do this is that so I can pass all the pages that viewing data into an "application frame" that will wrap the page with header, menu, and footer, and I don't need to give header, menu, and footer call in each page. I might have the actual files userinfo.php that I can $include_once, or I might not (I can just generate it from within the view.php), but hey, that's one of the power of this kind of framework, right? And, if someday I need to change this structure, I can change it from just within one file (view.php), not all.
Can I do this in PHP and XAMPP? How? I've noticed that some website seems to used this practice (URL which have no actual files or even path at all), but when I try to read tutorial for it, I got confused.
URL mapping in PHP?
The accepted answer listed 3 links to learn about URL rewriting. Mostly they're written for Apache in Linux, and mostly they pull all the possible scenario and configuration that I got confused which one I really need with all those long documents and technical jargon. I need just the practical step of my specific problem, and then, I will be able to start from there to explore myself if I have more advanced needs. Please help.
if you do want to go down the mod rewrite route adding the following to an .htaccess file in the site root should do it. You will need to make sure mod rewrite is on for XAMPP and I can't help you there I'm afraid. As you can see it rewrites the url, not the windows filename - so it would work on any OS.
The ([a-z]*) means it will take any filename.php with lowercase letters and redirect to /view.php?p=$1 where the $1 will be replaced by filename.
the [L,R] (L means last rule so stop processing if any more are reached, and the R means redirect (it will change the url in the browser). Use P instead to reverse Proxy (the user will still see the url they requested but the server will serve the correct file) - This will require mod_proxy as well.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} ^view/
RewriteRule ^view/([a-z]*).php$ /view.php?p=$1 [L,R]
</IfModule>
XAMPP uses apache so the rewrites would work the same in Windows as they do in Linux. You could place a .htaccess in the site root directory with some rewrite rules.
However, using PHP
in d:\xampp\htdocs\view\userinfo.php you could include the line
<?php
header('Location: http://localhost/view.php?p=userinfo');
?>
But this must be before any thing is echoed to the screen (even whitespace).
You can use the Apache module mod_rewrite to edit requests before they hit PHP. You want to put something like the following in a .htaccess file in your htdocs directory.
RewriteEngine on
RewriteCond %{REQUEST_URI} ^view/
RewriteRule ^view/(.*)\.php.*$ view.php?p=$1 [L,QSA]
QSA means Query String Append. This means that if there are any GET parameters set on the original request they will be appended to the end of the new request too.
Note that this assumes that Apache is configured with AllowOverride enabled and the mod_rewrite module loaded.
I am restyiling my own php mvc framework.
I have every request handled by /index.php by default, which triggers the mvc process of routing, executing the request and returing a proper view. Each request is routed according to a single 'q' GET parameter, drupal style, like
/index.php?q=anApplication/aController/theAction/arg1/.../moreArguments
This works pretty good, and makes the clean url thing easy via mod_rewrite. Ok.
I have a directory tree like this:
/public
|----themeName
|--------|
|----page.tpl
|----content.tpl
|----etc.
/private
|----sourceDirectory
|----moreSources
What i dont want is files stored in private and public directories to be served directly like an HTTP request: i dont want something like
mySrv/public/themeName/page.tpl
to show a dead template, or any resource that is not an image, bypassing my core handler - index.php.
I think i could achieve something with a rewrite configuration like this
RewriteEngine on
RewriteBase /
RewriteRule ^(.*)$ index.php?q=$1 [QSA,L]
but then the framework would only work on mod_rewrite-enabled sites, because this will rewrite all existing and non-existing resources.
What i am asking for is: is there another way to make EVERY request served by a resource (such an index.php) of my choice, existing or non-existing ones?
Thank you
Just store all your templates etc outside of the public_html folder.
This will allow PHP to have access, but the outside world cannot get to the file.
The easiest and more portable way would be to pull everything except your index.php out of the document root. PHP can still include files and do everything else.
I have not tried this, but if you put an index.php outside the old document tree
---/ app / new-index.php
|
/ public /
|
/ private / ...
|
index.php
and then add at the beginning of new-index.php
<?php
chdir('..');
require 'index.php';
?>
and finally reconfigure Apache so that the DocumentRoot actually becomes /app, then everything should work as before -- except that any URLs but '/' stop making sense for Apache, and all can be made to land on a suitable ErrorDocument 404.
Note: "everything should work", except HTTP redirections. You can read a non-interpreted PHP file from the FS, but you can no longer get its interpreted content from, say, Apache on localhost. Also, you ought to verify that any existing code does not make use of the DOCUMENT_ROOT global variable; if necessary you may overwrite it.