I'm trying to query environment variables that i have set my .bashrc file (i'm running Ubuntu 14.04) in a PHP scripts that run's under Apache server.
When i query the getenv('MY_VAR_NAME') or $_ENV['MY_VAR_NAME'] while accessing the page, it seems that those variables are missing..
My guess is: when the script is been executed the user is www-data, so 'MY_VAR_NAME' is not accessible.
Is there any procedures / best practices to this kind of problems ?
Thanks
My guess is: when the script is been executed the user is www-data, so 'MY_VAR_NAME' is not accessible.
Your guess is correct. :)
Is there any procedures / best practices to this kind of problems ?
What most programmers would do is to have a configuration file containing these variables. You would store the configuration file in some area where the PHP scripts could get to it -- whether that's in a home directory somewhere, in /etc. or in some other place such as in the web root or a directory near it.
Different frameworks take different approaches to the format of the configuration files -- some are PHP scripts, some are YAML files, some are windows/DOS format INI files, some are XML, some are JSON, etc.
Personally I like the idea of doing this:
Store in a simple INI file only the configuration required to access the database.
Store all of the remaining configuration in a database table, and build an editor for the parts that you need to be able to edit.
Cache the contents of the configuration database table in memcached.
Whichever method you use is up to you, however, and will vary depending on the needs of your application.
Related
Is there a way to dynamically find a user's cgi-bin path using PHP and write a file to it?
For instance, I want to write a PHP application that also uses a Perl script for additional functionality (will not break without it), and on first run I want to get the path for cgi-bin or whatever the user's directory is named, and write the script into the directory so that it can be invoked by the application, with minimal installation required by the user (i.e. upload application to a directory, then run index.php).
Is this possible? Or am I dreaming far beyond what I can actually do?
The simplest solution I see to this would be to use a regex to check for a directory named /cgi/ starting at the user's root directory, however, this doesn't seem like an entirely reliable method
__FILE__ gives you under both Perl and PHP the name of the currently executed file.
There is no sane way.
A server can be configured to execute CGI programs in zero, one or many different locations, none of which have to have "cgi" in the name.
You could try parsing the server configuration to identify which (if any) locations are set up that way, but you would have to write a separate parser for each server, and each one would be very complex. Even if you limit things to Apache, then you would have to deal with filtering based on virtual hosts, <file>, <directory>, <location>, ScriptAlias, .htaccess, etc.
I am developing a website which provides the option that clients can upload their PHP scripts to a specific directory on my server. I want to make sure that my system is secure, and thus I do not want people to be able to use those PHP scripts to edit or view files outside of the directory they are uploaded to. In other words, if there is a file at public_html/directory1/foo.php, it should only be able to edit and view files in public_html/directory1, and should not be able to edit or view files anywhere else on the system. Is there any way of doing this?
This is super dangerous. Technically there are ways to do this if you know your way around linux/windows user and group configuration, Apache configuration, and PHP configuration. You'll need to run Apache under a user with extremely specific permissions and configure PHP to forbid certain types of commands (most notably the exec/system commands, but there are a lot of other ones that are likely to get you in trouble).
I'd strongly suggest you try to figure out a way to avoid giving your users the right to upload files to a folder where they'll be evaluated by the server as PHP. There's just too many things that can go wrong, and too many settings that can be overlooked.
If you do decide to go this route, do a lot of reading on secure PHP configuration and Apache Privilege Separation.
Since PHP is a server side script, I belive you'll find it hard to properly secure your system. Having said that, you can limit those files by running the apache server by a user which have no access to other directories, check SElinux for more info. please note that it's really hard to do so, you might forget even one file which can be used later to hack the system.
A better way might be running these server on top of a VM, so that even if someone hijacks the VM, you could always shut it down and restore it's data.
I'm currently working on a script for our linux hosting company. We need to store variables such as versions and last update checks in a config.ini file which needs to be accessed and written to according to any updates made by the updater script.
I really need help writing the variables to a config.ini file (and later overwriting or changing the variables when they are updated), creating the config.ini file and reading the variables from the config.ini file.
The variables get stored at different times and not all at once, so one array won't work. I also have if statements, so some variables will be put in the file in certain situations and in other situations, there will be different variables in the file.
Example:
Server1 has game1 installed.
Server2 has game2 installed.
Script checks for game1, then checks database for latest version, compares with the config file. If config file is blank or old, updates and then changes config file version to database version. Repeats again for each game. If the game is not there, no variables stored and skip to the next step.
I'm battling a lot with trying to read and write to the file at separate intervals without overwriting the previous lines.
Would be awesome to get some support.
Regards,
Skowt
I guess you want ideas. Try using yaml, xml, sqlitedb to store your config settings. XML might be bit hard since you have to read and write. To me yaml files seems like a good options. I haven't tried PHP yaml function yet, symfony has a good yaml component.
Another options as I mentioned is to use a sqlitedb might come in handy if you have a lot of complicated configs.
Ok this might seems a bad idea or an obvious one. But let's imagine a CMS like PHPBB. And let's imagine you'd build one. I'd create just 1 file called PHPBB.install.php and running it it will create all folders and files needed with PHP. I mean, the user run it just once and every file and folder of the app is created via the PHP file.
Why to do this?
Well mostly because it's cleaner and you are pretty much sure it creates everything as you wish (obliviously checking everything about the server first). Also, having all the files backed-up inside a file you would be able to restore it very easily by deleting everything and reinstalling it running again PHPBB.install.php. Backing-up files like this will allow you to also prevent errors: How? When an error occurred in a file, this file is restored as it was and automatically re-run.
It would be too heavy!
The installation would happen only once and you'd be sure the user will not forget to place the files correctly. The error-preventing will worth the cause and it would also happen only once.
Now the questions:
Does this technique exists? If so, What's its name?
Why would you discourage it?
As others have said, an installer.
It requires the web server to have permission to write to the filesystem, and ends up having the files owned by the user the web server runs as. Even when one has the ability to change filesystem permissions, it's usually a longer process than just extracting an archive and having the initial setup verify permissions.
Does this technique exists? If so, What's its name?
I'd advise to read about __halt_compiler(). It allows you to mix PHP code with non-php data which is not parsed, so you may have PHP code ("installer") and binary data (e.g., compressed contents of all the files) in single PHP file.
1 - Yes, there is a single install file in PHPBB. You run through an online wizard defining your settings and then it installs automatically.
http://www.phpbb.com/support/documents.php?mode=install&version=3&sid=908f5766fc04868ccb985c1b1e6dee4b#quickinstall
2 - The only reason to discourage it would be if you want the user to understand exactly how the system works. Automatically installing it means the user has no need to understand the nitty gritty of it all - of course, many see this as a good thing.
My friend asked me to update a PHP application that his company uses. I found out that the application uses .ini extension for DB configuration file. The file contains DB host address, username, and password!!. The problem is that I can access the file on web-browsers.
I am trying to understand why. Is there any particular reasons to use a regular php file with .ini extension??? I just don't get it.
Readability is one of the main reasons I've used ini filies for php script configs in the past. People who are not coders have run into an ini file at least once before, and can understand what it is much easier than even a simple php file.
The issue of ini files being readable by everyone can be prevented by server side configuration, or even better, by simply adding a single line of code inside a comment line at the top of the file.
That way php will output an 'Direct access forbidden' when the file is accessed via a browser, and the ini file will continue to function as before.
You can use Zend_Config_Ini. It is comfortable and easy. Just simply do not put config files where any user can reach them (for example public_html).
INI files are just one way of dealing with configuration, perhaps the developer came from a Windows-developing background and used whatever he was familiar with :). Besides, PHP offers a convenient way of parsing INI files through the parse_ini_file function.
You'll want to make sure the .INI file is not accessible from the web though. Move it below the docroot so your PHP script can still access it, but random browsers cannot.
For what it's worth, PHP has traditionally used php.ini to configure PHP. So maybe it's some kind of legacy thing?
Seems like this is just former programmer's wish to use different file type for configuration. If there is no other uses for this file, rename it to *.php and forget it. If not, configure webserver to parse ini as php or, better, move it to directory, not reachable from web-server.