I am developing an application in Code Igniter with a friend. Because both of us have different database logins on our machines, we have different "config/database.php" files.
How can I tell Git that both of us have different database configurations? Right now, we are getting merge conflicts every time we pull because "config/database.php" differs for us.
I usually rename the /application/config/database.php file to /application/config/database.default.php (versioned) and add the original path to the .gitignore file. Then, each developer copies the default (unversioned file) back to the original path and edits per their local settings.
This becomes an extra step in the server setup process, but it saves the grief you mention.
Have a single file that selects config based on an environmental variable. Set that variable in your server's config.
<?php
if (getenv('WHOS_CONFIG') == 'mine') { … } else { … }
and in server config (which you wouldn't verison, otherwise same problem arises again :)
e.g. for Apache:
<VirtualHost *>
SetEnv WHOS_CONFIG mine
…
Alternatively, have a common database.php config file that includes database.local.php file that is not versioned. The latter would override variables you need.
Two options are:
Don't version control this file anymore (I leave git-command to your research)
Use the .gitignore file
As result you'll have file on old place, butit will not interfere with "another" file anymore
We usually put database configuration files in the .gitignore file to avoid these issues. It's a good idea anyway not to put these config files with their user/passwords in git.
We'll frequently keep a config/database.yml.template file (we're using rails) as the basis for folks to copy to config/database.yml and then edit to their local machine. The database.yml filename is put in the .gitignore file (which is shared under version control).
Basics on gitignore can be seen here.
Additional info, including pitfalls to avoid at: Ignore files that have already been committed to a Git repository
Related
Something wrong with my assets configuration, it looks to /usr/lib/cgi-bin/assets, which is wrong I guess. How to fix it?
Yii setup is initial.
Apache config:
Nginx config:
I recently also had similar problem with missing folder assets (I don't know how that happened since I have installed Yii2 multiple times and that occurred just once). The difference was only different path to it.
What solved my issue is creation of that folder in specified path (which is /usr/lib/cgi-bin in your case and it should be an empty folder, no need to write anything in it).
After that, Yii2 system should generate all widgets' JavaScript and CSS files automatically (assuming your server allows that). Try to access the website and if you still have the same issue (which shouldn't be the case anymore?), check if there are any files/folders in your newly created assets folder.
The Bolt documentation mentions setting up configuration files for each environment, but doesn't explain how to make it happen.
When you have multiple environments for the same site, like development, staging, or production, you’ll want parts of the config to be the same, and some different per environment. You’ll probably have different database info and debug settings. This can be accomplished by splitting the config.yml file. Put all settings you share over all environments in the default config.yml, you can commit this in your version control system if wanted. Every setting which is different per environment, or which you do not want in version control (like database info), you put in config_local.yml. First config.yml is loaded and then config_local.yml, so that config_local.yml can override any setting in config.yml.
Of course I have no problem creating an additional config file, but how do I tell Bolt which environment it's running in and which file it ought to load?
Turns out Bolt is completely unaware of its environment. It always loads config.yml followed by config_local.yml, regardless of domain name.
From Config.php, starting at line 226:
protected function parseGeneral()
{
// Read the config and merge it. (note: We use temp variables to prevent
// "Only variables should be passed by reference")
$tempconfig = $this->parseConfigYaml('config.yml');
$tempconfiglocal = $this->parseConfigYaml('config_local.yml');
$general = Arr::mergeRecursiveDistinct($tempconfig, $tempconfiglocal);
The solution to my problem is to never allow config_local.yml to get deployed.
The config_local.yml file is intended for development use so that you can override configuration setting that might be committed to your VCS in production use.
So, i'm a total noob with codeigniter but i'm getting by.
I have a domain name on iPage. Currently, I am using codeigniter w/ my codeigniter project inside htdocs which is inside XAMPP. Everything is working great on localhost, but I am totally lost on where to start concerning how to put my project onto my web hosts server.
There is not much to it.
The following part, does not really belong here, but I guess I like to start from the beginning.
You need a domain name and hosting space(with a php server ofcourse).
The hosting provider will provide you with ftp access and a control
panel to access your files. You need to add nameservers to your
domain name to associated it with your hosting space.
www.yourdomain.com/ will point to your hosted files. (This might take a couple of days to take effect).
To answer your question:
Now, you can simply upload the contents of your project to your home
directory on the hosting server. You can organize it the way you want
with subfolders etc. You'll also need to make server specific changes
like mentioned here
You might also need to check if any php libraries need to be enabled on your server.
CodeIgniter is installed in four steps:
Unzip the package.
Upload the CodeIgniter folders and files to your server. Normally the index.php file will be at your root.
Open the application/config/config.php file with a text editor and set your base URL. If you intend to use encryption or sessions, set your encryption key.
If you intend to use a database, open the application/config/database.php file with a text editor and set your database settings.
If you wish to increase security by hiding the location of your CodeIgniter files you can rename the system and application folders to something more private. If you do rename them, you must open your main index.php file and set the $system_path and $application_folder variables at the top of the file with the new name you’ve chosen.
For the best security, both the system and any application folders should be placed above web root so that they are not directly accessible via a browser. By default, .htaccess files are included in each folder to help prevent direct access, but it is best to remove them from public access entirely in case the web server configuration changes or doesn’t abide by the .htaccess.
If you would like to keep your views public it is also possible to move the views folder out of your application folder.
After moving them, open your main index.php file and set the $system_path, $application_folder and $view_folder variables, preferably with a full path, e.g. ‘/www/MyUser/system’.
Reference: https://www.tmdhosting.com/codeigniter-hosting.html
I am a PHP newbie and a have a php security question. Is it possible for somebody to get the source code of a php script file running on a server with default configuration? If so, what is the best way to be protected? I am asking this because I happened to download a php file when I requested a page from a site and what triggered my concerns. I think that maybe apache configuration was wrong and served that file to me like a simple file but I am not sure. Also what is the best place to keep "sensitive" data such as database or smtp configuration?
Thank you,
Alex
For the most sensitive information, I'd suggest putting it outside of your web root folder, and including it through "require" or "include". This way, even is some configuration gets botched on the server, the visitor will only get served the line "include('secret_stuff.php');" and not the actual script.
Exactly what David Dorward said but i would advise you take a look at the following patch(s) that would modify apache to not send source code's regards if there is a misconfiguration.
http://mirror.facebook.net/facebook/patches/ap_source_defense.patch
Patch like so:
cd apache-1.3.x
patch -p1 -i ap_source_defense.patch
More Patches from Facebook Development Team: http://mirror.facebook.net/facebook/patches/
The best way to protect your much needed source is to place them outside the public root directory, as if apache is running it will not be able to serve files directly from the folder up public_html
for example:
C:/server/apache/
C:/server/apache/htdocs/
C:/server/apache/htdocs/includes/
People can specifically view the files my going to
http://hostname.tld/includes/
but having the directory structure of:
C:/server/apache/
C:/server/apache/includes/
C:/server/apache/htdocs/
and then within
C:/server/apache/htdocs/index.php
you have
<?php
require_once('../includes/config.php');
?>
this should protect all major files bar the view file (index.php)
If the server is not configured to handle PHP files, then it will treat them like any other unknown file (and serve them as either text/plain or application/octet-stream.
PHP support is, as far as I know, always provided as an extension or external program (for CGI, FastCGI, etc) and never as a built in for an HTTP server.
If the server is properly configured to run PHP code, then people without direct access to the server cannot view the PHP source code. You don't have to do anything else.
It is only because that server was not configured to run PHP, and instead served it as text, that you could see the source.
If you have this line in your apache.httpd.conf file,
AddType application/x-httpd-php .php
Apache should deal with data, rather than showing them...
Also you need to start php services.
What you describe as "default configuration" is a webserver without php installed (or with php disabled). In these cases, it is certainly possible to download the php script.
Make sure php is installed (as it will be on ~100% of production php servers) and/or block access to your configuration file with an .htaccess file like this:
<FilesMatch "^config.php$">
Order allow,deny
Deny from all
</Files>
If you want to be extra-tricky (and work even on servers where .htaccess files are ignored), prefix the configuration file with .ht, like .ht.config.php. Most Apache(and some other webserver) configurations will refuse serving files beginning with .ht. However, in general, the only way you could be sure no webserver serves your file is to move it to a directory outside of the server's document directory. On most hosts you or your php script won't be able to access those though.
Your second problem are misconfigurations. There's not much you can do, albeit there might(?) be options to construct a rewriterule to prevent accidential accessibility.
The best prevention however is to keep all scripts outside of the DOCUMENT_ROOT. Just leave a single index.php there, and include all dependencies from there. This is also the best strategy to avoid leaking of configuration data (also don't use ini files for sensitive data, but always .php scripts).
Another worry are shared hosting servers however. All concurrent users on a server can read out your scripts (if not through PHP then via Perl/bash CGIs). Nothing you can do about that, unless you change to a professional hoster which supports running everthing through suexec and thus allowing individual permissions.
Well, "default configuration" is a vague term, but as long as the web server is configured to parse .php files through PHP, you should be fine from that angle. If your scripts themselves happen to parse other PHP files (for eg. a template system) then you need to make sure there aren't any loopholes in that too, since the PHP scripts have full access to your files on the server.
Assuming these are taken care of, you don't need to keep the "sensitive" data in any special place -- just put them in your .php files, but make sure all your scripts end in .php (for eg. config.inc.php) so that they are always parsed via PHP and not sent as plain text.
This may be a really stupid question...I started worrying last night that there might be someway to view PHP files on a server via a browser or someother means on a client machine.
My worry is, I have an include file that contains the database username and password. If there were a way to put the address of this file in to a browser or some other system and see the code itself then it would be an issue for obvious reasons.
Is this a legitimate concern?
If so how do people go about preventing this?
Not if your server is configured right. I think discussion on how that is done belongs on serverfault.
To add on to the other answers:
If you use a file extension like .inc there's indeed a higher risk. Can you open the file directly in your browser?
The most important advice is missing:
Only the files that should be accessed by a browser, should be in a publicly accessible location. All the other code (and configuration) should be in a completely separate directory.
For example
root
- webroot
- includes
- config
Only 'webroot' is exposed by your webserver (apache). Webroot can for example contain a single index.php, along with all your assets (javascript, css, images).
Any code index.php needs to load comes from 'includes' and all the configuration from 'config'. There's no way a user could ever directly access anything from those 2 directories, provided this is done correctly.
This depends on the file extension you have given the include file.
If the extension is one that is known and executed by the web server, it will be protected. If you browse to the file, the server will try to execute the code rather than just returning it as plain text.
If the extension is not known by the web server it will serve it as plain data, so anyone (who can guess the file name) can browse to the file and see the source code.
A Directory Traversal Vulnerability can used to obtain files off of the remote mahine. Alternatively you can use MySQL based sql injection to read files using load_file(). You can also test your system with w3af's urlfuzzer which will look for "backup files", such as index.php.zip. Also make sure that all files have .php extensions, a .inc can be viewed from the public. I would also disable Apache directory listing.
Normally there should be no way to view the PHP files remotely... it would be absolutely pointless. This completely depends on what web server you are using and how it's setup though.
Having looked around I can see that it is possible to protect a directory via the .htaccess by adding these lines:
Order allow,deny
Deny from all
This apparently protects the directory so that only local non web-access is possible.
This allows me to keep my includes in a subdirectory of the main site directory which is good for organisation and it can be used on the projects where I do not have access to folders outside the web root.
Does anyone else use this method?
Just for good measure I've put the directory permissions to execute only.
And the include extension is PHP as suggested by others.