I'm a Java (SE, EE) developer and I have been working with these techs for almost 6 years, I have also worked with php for non-web apps.
Now I'm required to build a site in php but I have googled a lot and I can't find a standard folder structure for a php site. As may you know in Java EE there is a defined structure and with the web.xml you can define security in order to allow or deny access to folders in the web root.
So the question is: Is there a standard folder structure to bring security in a php site?
If there is not, how can I prevent access to folders in my site, without the need to use .htaccess nor moving my folders to a private area in the web server?
There is no defined structure for PHP projects. Application frameworks invariably use well-defined structures, but that is decided individually by each framework. In addition, the developer can easily work outside these structures (the price being that "automatic" features of the framework might no longer work in some cases).
In order to prevent access to directories in your site you have to do one of the things you mentioned: either use web-server-level mechanisms such as .htaccess or move the directories outside the web root entirely.
That said, in many cases there is no explicit need for such security: by strictly limiting the pieces of code that can produce immediate effects (typically down to just one front controller that boots up the application) and making sure that data is contained inside PHP code (so that the web server will not reveal the contents of files) you effectively render direct access from the outside worthless.
Related
I am making a SEO project using PHP where I need to crawl every pages/directories of a website. But for this, I have to know or list all the directories of that website. Is it possible?
Can we do it with PHP?
No. HTTP provides no way for a client (regardless of the programming language it is written in) to ask for directory listings.
This is why search engines crawl links and make use of sitemaps.
A PHP program could inspect the directory structure of the file system of the computer it is running on, but even that wouldn't give you a good view in the general case as most websites are not simply a bunch of files served up by mapping URLs directly onto a filesystem (for example, the Front Controller design pattern is quite common).
Some people have reported issues with accessing, setting, or getting the right value from baseUrl() in a view script. But I'm wondering why it is necessary to use it at all, at least in a situation like mine where the ZF application is on a virtual private host (Amazon EC2) where I have full control of the directory structure and apache rewrite rules, as well as routes.
I know, for example, that in the filesystem foo.jpg lives in public/images/foo.jpg, and that the application's mod_rewrite will direct all requests to public - so in my view scripts it's a lot simpler/clearer and more efficient to write something like
<img src="/images/foo.jpg" />
instead of
<img src="<?php echo $this->baseUrl();?>/images/foo.jpg" />
What sort of future-proofing robustness or other benefit does the use of baseUrl() really provide? So far I haven't used it at all, and had no problem. But I've inherited some code that uses it, and my inclination is to strip out those uses whenever I'm editing a view script that contains them. Would I regret that later?
Used this way, it's not really useful, but on the other hand, using it this way
echo $this->baseUrl('/images/foo.jpg')
might prove to be useful in the future since you can add logic before printing the URL. Imagine that in a few years your website grows way more than you expected and you have to move all your static content to a Content delivery network (CDN) you will have to manually (or with search and replace) correct all your images/css/js instances URLs. With the baseUrl() (or as name it assetUrl()) you would just have to add your CDN's url and it will be fixed everywhere in your application.
EDIT
I found a use for the baseUrl() in the code you inherited :
It would allow you to add a common URL part to all of your links and references, in the case that your site is not at the root of the domain
i.e. : www.mysite.com/zf-app/
In your config file you would just have to add
resources.frontController.baseUrl = "/zf-app/"
for it to work, and all of your links would be prepended with that part
Perfect example. I have a couple of basic Zend-y utilities I built on separate systems. On my test platform, I just virtual host them all each with their own document root. Generally I access these tools over a remote web browser but that requires I VPN to the system running it as I didn't create these tools to be on anything more than a subnet and don't really want to expose them to an internet facing site.
So along comes android phones and things like bitweb server that allows you to run a lighttpd, php and mysql in minimalized forms on a pocket cell phone. Only problem is, it's not really set up to be powerful enough to virtual host on android operating systems.
No problem, it will allow for basic aliasing, so I just move all the tools each into their own sub-directory on my sdcard and use lighttpd mod_alias definitions to point to each and then create re-write rules for each subdirectory. But that led me to this post and others like it to fix all the static urls that pointed to href="/some/path/to/static/content"
I even had to update some urls to zend tools that were absolute paths to utilize {view}->url() calls instead.
By adding the baseUrl calls to the front of the static content, and using the view url() method for calling controller actions, I can now move the entire Zend MVC for any one of the independent tools into any directory I want and have them run from as deep in the web-tree as I desire. Zend does the rest and all it takes is 2-3 properly formatted entries in the lighttpd conf file.
I'm having a bit of an application structure design dilemma.
I have created a web app that creates online surveys. It all works fine, but I would now like to create a new site that does different types of online surveys. This new site will be pretty much 95% similar in terms of layout, logic, functions, etc.
Rather than duplicate all the code from the current web app, I'd like the new app to share in the "fountain of knowledge" created by the current app - so to speak.
Can anyone enlighten me with their experiences of doing this sort of thing? Their best practices?
As a rough guide, I'm currently thinking of using symlinks for all the major logic files (library.php, functions.php, etc), and then deciding which logic to use based on which URL the user logged-in from.
Does that sound like a good or bad idea?
Would it be any better or worse to divide the whole system in to 3 sites, with the site in the middle containing all the common elements and logic? This middle site would have no independent use - it would be used from either of the 2 applications looking for functionality and assets, etc.
Any help and experience on this matter is very much appreciated indeed.
I'm very wary of going down a dead-end solution.
Kind Regards,
Seb
Good solution if:
you host your website yourself and creating symlinks between differents virtual hosts is not a problem
you won't have to make significative changes between the 2 websites
But instead of using symlinks, I could take advantage of PHP's include_path directive and put the common libraries in this path. This way, just write your includes relative to this path, the files will be accessible from any site you want on the same server.
The second advantage of using include_path is you can bypass any open_basedir directives which wouldn't allow you to include files which are not in the same virtual host base dir.
This is how I'd do it...
Create a core library.
Create you 2 site directories.
Create site specific code folders in
each site.
Create core library folders in each
site that simlink to the main core
library created.
We have a custom PHP/MySQL CMS running on Linux/Apache thats rolled out to multiple sites (20+) on the same server. Each site uses exactly the same CMS files with a few files for each site being customised.
The customised files for each site are:
/library/mysql_connect.php
/public_html/css/*
/public_html/ftparea/*
/public_html/images/*
There's also a couple of other random files inside /public_html/includes/ that are unique to each site. Other than this each site on the server uses the exact same files. Each site sitting within /home/username/. There is obviously a massive amount of replication here as each time we want to deploy a system update we need to update to each user account. Given the common site files are all stored in SVN it would make far more sense if we were able to simply commit to SVN and deploy to a single location direct from there. Unfortunately, making a major architecture change at this stage could be problematic. In my mind the ideal scenario would mean creating an account like /home/commonfiles/ and each site using these common files unless an account specific file exists, for example a request is made to /home/user/public_html/index.php but as this file doesnt exist the request is then redirected to /home/commonfiles/public_html/index.php. I know that generally this approach is possible, similar to how Zend Framework (and probably others) redirect all requests that dont match a specific file to index.php. I'm just not sure about how exactly to go about implementing it and whether its actually advisable. Would really welcome any input/ideas people have got.
EDIT AllenJB's comment reminded me that we have previously explored AliasMatch as a potential solution to this, we ended up with an general.conf file for a user that looked something like this:
php_admin_value open_basedir "/home/commonfi:/home/usertes:/usr/lib/php:/usr/local/lib/php:/tmp"
php_admin_value include_path "/home/commonfi"
AliasMatch (.*).php /home/commonfi/public_html/$1.php
AliasMatch (.*).html /home/commonfi/public_html/$1.html
You can set this up via the Apache configuration - you probably want Alias, but there are several options:
http://httpd.apache.org/docs/2.2/urlmapping.html
You certainly can build a "cascading" system as you describe (load local file, if that doesn't exist, load global file). The complexity is that the files are loaded in different ways (using include() in PHP, through the web, ... maybe even more ways?)
Filesystem includes
If the includes/ consist of files containing one PHP class each, you could use an autoloader like Zend Framework does. The autoloader would look first for a custom version of the include file, and if it doesn't find one, include the global version instead. I happen to have such an autoloader handy if you need code to start with.
If the includes don't match the one-class-per-file structure, you would have to build a custom include() function that fetches the local version of the file or, failing that, the global one.
Pseudo-code:
function fetch_path($name)
{
if (file_exists(LOCAL_DIRECTORY."/$name")) return LOCAL_DIRECTORY."/$name";
if (file_exists(GLOBAL_DIRECTORY."/$name")) return GLOBAL_DIRECTORY."/$name";
return false;
}
Web resources
The second part is going to be the web part (i.e. Web URLs with local or global files). I think this should be pretty easily solvable using the -f switch in a .htaccess file. You would build a rule that rewrites failed requests (!-f) to the local web resources directory (example.com/css/main_stylesheet.css) to the global one /home/commonfiles/public_html/main_stylesheet.css). You would need to fiddle around with Apache's server config to be able to rewrite local requests to the commonfiles directory, but it should be possible.
That is maybe worth a separate question.
I run multiple websites all running off of a single installation of CodeIgniter on my server (separate application directories and a single system directory). This has been working fabulously and I don't see any reason to change it at this point.
I find myself writing library classes to extend/override CI all of the time and many times if I find a bug or improve effeciency I have to go back to several websites to make the same adjustments at risk of a typo that breaks one of the websites. Because of this it requires that I change each file and then test that site for bugs.
I have been pondering a solution of using a single libraries directory in a central location and symlinking all of my websites to that central directory. Then when I make a file change it will immediately propagate to all of the downstream websites. It will still require that I test each one for errors, but I won't have to make the changes multiple times. Anything that is specific to a single website will either be a non-shared file (still in the linked directory just not used elsewhere) or can be put in a local helper.
Also, I keep separate 'system' directories by CI version so I can migrate my websites independently if necessary--this central libraries file would be attached to a specific version to reduce possible breaks.
Does anyone see potential issues or pitfalls from taking this approach? Has anyone accomplished this in another direction that I should consider?
Thanks in advance!
I think this actually makes sense :] Go for it. Even on official CodeIgniter page, they mention it's possible.
Also, I don't see one reason why there should be any problem.
Edit: they touch the problem of multiple sites here: http://codeigniter.com/user_guide/general/managing_apps.html
also:
http://codeigniter.com/wiki/Multiple_Applications/
http://www.exclusivetutorials.com/setting-multiple-websites-in-codeigniter-installation/
How to Handle Multiple Projects in CodeIgniter?
http://codeigniter.com/forums/viewthread/56436/
I have a single system directory and separate application directories for my CI apps. In order to share libraries and some view templates between my apps, I have created a "Common" directory, in the same folder as the CI system and with the same structure as a regular app folder and used symlinks, but you can modify the Loader class so that it looks in the Common folder too. My setup looks something like this:
/var/CodeIgniter/
/var/Common/
/var/Common/config/
/var/Common/controllers/
...
/var/Common/libraries/
...
/var/www/someapp/
/var/www/someotherapp/
...
I'm not sure how you handle publishing your sites (assuming you actually do any of that), but I'd look into version control. For example, in SVN you can make external to another svn directory (or file) and then just update the current svn directory which grabs the external file. This approach gains one benefit from the others, which is when you modify the common library, the others aren't immediately affected. This prevents unwanted breaks before you have time to go test all the sites using the common library. You can then just update each site's folder whenever you are ready to test the changes. This is "more work", but it prevents code duplication AND unwanted breaks.
I wrote a MY_Loader to do exactly that.
http://ellislab.com/forums/viewthread/136321/