Some people said that setting the timezone would increase computational speed for date/time functions. I don’t know if that’s true, but at least we can make sure the app knows for what timezone is working… 😛

Now, let’s move on to the configuration file. As we are working in the development environment, we will find the config.php inside application/config/development directory.

Changing the language

English, the new lingua franca (as in… is not french anymore). Of course, the english may be an important language, but if you are creating a site for people that don’t speak english, you might as well go and find the line:

PHP

1

$config['language']='english';

… and change it to your application’s language:

PHP

1

$config['language']='romanian';

Now, if you do this, you must have your language files ready. If you don’t have the language files, you can at any time translate the files from english into your language, by following these steps:

1. Create a directory having as name your language name inside application/language (in my case, romanian). The folder structure would look like this:

INI

1

2

3

4

5

6

7

8

9

10

11

12

13

application

-config

--development

---autoload.php

---config.php

---database.php

---routes.php

--production

--testing

-language

--romanian

system

index.php

2. Go into the directory system/language/english and copy all the files that are there.

4. Start translating every file you find in there taking care to keep unchanged the variables that are kept inside the {} curly braces.

Now you would have a directory structure as below:

INI

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

application

-config

--development

---autoload.php

---config.php

---database.php

---routes.php

--production

--testing

-language

--romanian

---calendar_lang.php

---date_lang.php

---email_lang.php

---form_validation_lang.php

---ftp_lang.php

---imglib_lang.php

---index.html

---migration_lang.php

---number_lang.php

---pagination_lang.php

---profiler_lang.php

---unit_test_lang.php

---upload_lang.php

system

index.php

Composer integration

Now, in version 3 of CodeIgniter, you can use composer to install new packages (of course, you can also use Composer with the version 2 of CodeIgniter). In the config.php, which can be found in application/config/development, you can find a line that will tell the CodeIgniter if it should look for a Composer package auto-loader script in application/vendor/autoload.php. If you plan to keep the default settings, all you will have to do is change $config[‘composer_autoload’]to TRUE.

Sessions, cookies, security…

Sessions, cookies and security is something an application always needs, considering the fact that the internet is a real jungle full of dangers from all sides.

Encryption

Also, if you think you will use the Encryption class, you must set an encryption key.

The encryption key must be a random string of 32 characters. If you can’t think of any random string of 32 characters, google to the rescue. Do a search for codeigniter encryption key generator, and you might find some sites that can propose you some keys. I found two, which look good:

Now, copy the random string and put it as value to the $config[‘encryption_key’].

Preventing XSS

I don’t know about you, but I always used to set the $config[‘global_xss_filtering’] to TRUE. This seem to be a bad practice, as the xss filtering should only be made on output, and not on the input. So, if you are smart, you should disable the global_xss_filtering, and only use the XSS filtering only before you output to the browser something that comes from your users.

Cross Site Request Forgery

Putting it simply, anyone can create a form on a different site than yours and send the POST data to your application. To protect you from this to happen, you can at any time create a hidden field that will keep a token (a random string that is unique). That token will also be registered in session data of your visitor so that when a submit of your form happens, the two tokens will be compared to verify if the form was submited from your site.

So, let’s change a few lines inside the config.php:

PHP

1

2

3

4

5

6

$config['csrf_protection']=TRUE;

$config['csrf_token_name']='csrf_sitecom_token';

$config['csrf_cookie_name']='csrf_sitecom_cookie';

$config['csrf_expire']=7200;

$config['csrf_regenerate']=TRUE;

$config['csrf_exclude_uris']=array();

As you can see, with $config[‘csrf_exclude_uris’] you can exclude some URIs from using CSRF token.

And that’s it with the config.php. I sure hope I didn’t forget something.

Make cache and logs directories writable

Make sure the cache and logs directories, which can be found inside application directory, are writable.

Great infos Avenir, about global_xss_filtering I read in the config file that This feature is DEPRECATED and currently available only for backwards compatibility purposes. Is there any replace for this feature? Thanks

Hello, you misunderstood. We are not talking about the xss filtering that is deprecated. It’s the global xss filtering that is discouraged. You can still use xss filtering on your output. The thing is that the global xss filtering started from a misunderstanding regarding the security in PHP. You don’t have to clean every data that comes in contact with your application. You only have to clean the data that is outputed by the application, and only validate/filter data that is inputed. Keep in mind the mantra: “Filter input, clean(sanitize) output”.

Is the part about setting the timezone in the bootstrap file still relevant in CI3?

I found this in the config.php

/*
|———————————————————————
| Master Time Reference
|———————————————————————
|
| Options are ‘local’ or any PHP supported timezone. This preference tells
| the system whether to use your server’s local time as the master ‘now’
| reference, or convert it to the configured one timezone. See the ‘date
| helper’ page of the user guide for information regarding date handling.
|
*/
$config[‘time_reference’] = ‘local’;