SitePoint Sponsor

User Tag List

Results 1 to 14 of 14
  1. #1
    SitePoint Zealot
    Join Date
    Oct 2003
    Location
    Denmark
    Posts
    129
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Include common file

    Often in my applications I need to include common files on every page, say configuration.php and the database file.

    Consider the following directory tree:

    /public/index.php
    /public/contact.php
    /public/invoice/index.php
    /public/invoice/invoice.php
    /secure/config.php
    /secure/database/MDB2.php

    When php runs as cgi .htaccess is not a viable solution to either auto_prepend_file or make a php_value include_path.

    The - I guess - I am left with the solutions to include the file from the scripts.

    Either:

    1) hardcode the direct path into require('/hard/coded/path/config.php');
    Not an attractive solution if there are hundreds of pages and you decide for some reason to change server.

    2) use $_SERVER['DOCUMENT_ROOT'] and make a new file named include with the following content:

    PHP Code:
    set_include_path(get_include_path() . PATH_SEPARATOR '/my/include/path/');
    require(
    'config.php');
    require(
    'database/MDB2.php'); 
    3) use a relative path to the DOCUMENT_ROOT with the before mentioned file.

    Solution 2 and 3 however uses more included files than the first solution. How do you do it?

  2. #2
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    this is what I have done previously. Similar to number 1.

    Have one page in your main directory, which has all of your includes in. At the top of that page, give the common direct path for these includes (the paths which are in ALL of the typical includes) as a variable.

    e.g, your 'allinc.php' would look like:
    PHP Code:
    $dirpath "hard/coded";
    require(
    $dirpath "/config.php");
    require(
    $dirpath "/path/db_connect.php"
    This helps when you have alot of includes. If you change host, simply change $dirpath to the host's directory.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  3. #3
    SitePoint Zealot
    Join Date
    Oct 2003
    Location
    Denmark
    Posts
    129
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    arkinstall --> this is what I have done previously. Similar to number 1.

    Previously. What are you doing now, then? And how do you call this file from all the other files - using relative directory paths or using DOCUMENT_ROOT?

    And is it not a security hazard to include a file with all your includes in the DOCUMENT_ROOT - or is this just a myth?
    Last edited by lsolesen; Dec 11, 2006 at 15:43. Reason: Wanted to add a question.

  4. #4
    SitePoint Zealot
    Join Date
    Oct 2003
    Location
    Denmark
    Posts
    129
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Since noone answered, I assume that it is on a security hazard to have an include file in the DOCUMENT_ROOT.

  5. #5
    Worship the Krome kromey's Avatar
    Join Date
    Sep 2006
    Location
    Fairbanks, AK
    Posts
    1,621
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So long as all your included files go through the PHP parser (i.e. have the extension .php or something else that the web server is set up to run through PHP), then having them in your web server's path is not a threat since PHP will parse them anyway and any sensitive data (such as database connection credentials) will not be sent to the user. Just to be safe, you can request each file directly through you web browser and examine what's sent back to you.
    PHP questions? RTFM
    MySQL questions? RTFM

  6. #6
    SitePoint Wizard silver trophy
    Join Date
    Mar 2006
    Posts
    6,132
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    the DOCUMENT_ROOT variable is provided by the webserver, so it may not always exist under different enviornments.

    im liking a relative path from the executed file to a config file. the config file then does a dirname(__FILE__); on itself to setup the application root. paths are then built from this.

  7. #7
    SitePoint Addict
    Join Date
    Oct 2006
    Posts
    210
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    For my projects, each source file includes other files that it depends upon. I also don't want to require the source files to know where the other files are located. At the beginning of a transaction, I usually want to execute some common code. So source files that are referenced by a URL include a common file. This common file adds the include directories to the PHP INI include_path variable:

    ini_set( 'include_path', $includePaths . ':' . ini_get( 'include_path' ) );

  8. #8
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lsolesen View Post
    When php runs as cgi .htaccess is not a viable solution to either auto_prepend_file or make a php_value include_path.
    First thing I wonder, is why you'd ever want to run PHP as CGI? Even then - You can still set values directly in the php.ini file.

  9. #9
    SitePoint Zealot
    Join Date
    Oct 2003
    Location
    Denmark
    Posts
    129
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think php will always run as CGI. My host says it is the most secure setting for php. I don't have control over the php.ini file, so that I cannot do. I can set include_paths on runtime though, but I need to include the common file which does that, and that was the question for this thread.

  10. #10
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lsolesen View Post
    I think php will always run as CGI. My host says it is the most secure setting for php. I don't have control over the php.ini file, so that I cannot do. I can set include_paths on runtime though, but I need to include the common file which does that, and that was the question for this thread.
    I'm by no means an expert in server configuration, but I haven't seen CGI around in this century. Running PHP as a module gives access to a lot of features, which I wouldn't want to be without. For what I know, it seriously boosts performance as well. The thing about security sounds to me like your host is just too lazy to set things up properly. Have they turned on safe-mode too? I think I'd consider switching to another provider on this ground alone.

    Otherwise you're basically stuck with creating a file in the webroot, which sets the include_path and then include this in all files. A bit tedious, but not that much of a problem I'd say.

  11. #11
    Worship the Krome kromey's Avatar
    Join Date
    Sep 2006
    Location
    Fairbanks, AK
    Posts
    1,621
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lsolesen View Post
    I think php will always run as CGI. My host says it is the most secure setting for php. I don't have control over the php.ini file, so that I cannot do. I can set include_paths on runtime though, but I need to include the common file which does that, and that was the question for this thread.
    You're being fed a line - there's no appreciable difference in security between running as a module and running as a CGI. And as kyberfabrikken points out, running PHP as a module gives you access to many features not available in CGI. I think I'd second the motion that you look for a different host, as your current one seems either unknowledgable or lazy.
    PHP questions? RTFM
    MySQL questions? RTFM

  12. #12
    SitePoint Wizard silver trophy
    Join Date
    Mar 2006
    Posts
    6,132
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    as far as i know, things like suexec and suphp are not available when php runs as an apache module. cgi is required. this is huge from a security standpoint as php doesnt have to run as the nobody user which is the same across all accounts on the server. you get to run it as your own user, and enjoy being able to tighten up your filesystem permisssions as a result.

    i dont like having to make my php files world readable so php can read it as an apache module. that means everyone else on the server can read them too. bad! same with an upload directory being writable.

    this is why safe mode was created, but safe mode only affects php.

    not to say this solves all shared server security issues, but its a huge step in the right direction.

  13. #13
    Worship the Krome kromey's Avatar
    Join Date
    Sep 2006
    Location
    Fairbanks, AK
    Posts
    1,621
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hrm... didn't realize that. Surely there's got to be a way to run PHP as a module and still gain similar security benefits on a shared server. Personally, I run Apache as its own user (conveniently named apache), but I do have my own server.

    Something that might still work in a shared environment, though, is if all the files are owned by a group that Apache belongs to (e.g. apache, which is the group my Apache runs under), and then set the file permissions to be 770. Can't recall off the top of my head if a user can create files that would be owned by a group he/she is not a member of (using of course umask settings), so not sure if this type of model would help in a shared server environment.
    PHP questions? RTFM
    MySQL questions? RTFM

  14. #14
    SitePoint Wizard silver trophy
    Join Date
    Mar 2006
    Posts
    6,132
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    i too am far from an expert on server config and only have a basic understanding of unix filesystem permissions, but i have to assume theres a very good reason why i see shared hosting companys going to suexec/suphp instead of running apache modules, despite this costing them money. since the entire php interpretor is loaded for each request with cgi php, less accounts per server are possible due to higher resource use. i think fastcgi helps alleviate this to some extent though.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •