It can be found in the feature/session branch and is the last thing I want finished before the 3.0 release. To everybody reading this: please test it and give some (useful) feedback. :) Tests with non-mysql DBs in particular would be really useful.

Implemented features:

• Locking (this is mandatory, no drivers without locking will be implemented; locking for non-MySQL/Postgre DBs though is done through sysvsem, which means there's no locking on Windows)
• Lazy writes (only write data to storage if it was changed)
• 'files' & 'database' drivers

Planned/todo features & other stuff that might get implemented:

• Redis & Memcache(d) drivers
• Not sure if extending the library works at this time, but this certainly needs more work
• Optional session data encryption
• Other drivers?
• Tests? (we've had issues with PHPUnit burping with "headers already sent" messages when we send cookies)
• PHP should validate incoming session IDs (they need to be all alphanumeric chars), but still - double check that to avoid SQL injections
• Automatic regeneration of IDs
• session.use_strict_mode functionality

BC breaks:

• Flash/temp/user-data can collide & are all actual $_SESSION vars
• Changed table structure for database storage
• No cookie storage (no, it will not happen, you must use server-side storage)
• No user-agent matching - it's user input and therefore ineffective and pointless
• Database storage can't be used with a persistent connection (to avoid deadlock and to allow concurrency)

Issues/PRs that this resolves/supersedes:

• #1344
• #1375
• #1780
• #1940
• #2476
• #2702
• #2923

This is the HMVC solution from #357, further refined and with thorough unit tests added.

The former incarnation was recommended by @philsturgeon, who suggested several features and refinements along the way. All of the substantive changes - especially the CodeIgniter class and modifications to Config, Router, and Loader - have been stable and working in a production environment for over a year and a half now.

Almost all core classes have unit test coverage, and specifically those with new features or significant changes are all covered, with strong isolation and virtually every code path tested. Convenience functions for vfsStream have also been added to CI_TestCase.

A new README in the system directory enumerates the entire application lifecycle in detail to aid in comparison with the existing bootstrap process.

This implementation aims to be fully backward compatible with version 2.1. Great care has been taken to ensure that upgrading users can continue to use the framework in the same way they used to, even if they don't take advantage of the HMVC feature.

P.S. - Don't be frightened by the number of new lines of code in this request - 2/3 of that is new unit test code.

This is a refactoring of the original CodeIgniter Session library as a driver library. It adds a native PHP session driver for those who prefer that route, while keeping all the neat features of original CI sessions and a couple new features suggested on UserVoice. This code has been thoroughly tested and running stable on St. Petersburg College servers for many, many moons.

Bon Appetit!

Hi Guys!

I had a chance to test CodeIgniter against XSS attack. I have found few things that might be interested for you guys:

I have created a test-bed here: http://xssplayground.net23.net/clean10.html

The area is protected by CodeIgniter but for testing purpose OUTPUT reflects in Standard HTML, Script, Attribute and URL context. In the following manner, in my test-bed output reflects in different context.

Output reflects here (Standard HTML Context): <?php echo cleanCode($_POST['name']); ?> <br><br>

Output reflects in attribute context <div class='<?php echo cleanCode($_POST['name']);?>'>I am an attribute context</div> <br><br>

Output reflects in URL context <a href='<?php echo cleanCode($_POST['name']);?>'>I am URL context</a> <br><br>

Output reflects in script context <script> var a = '<?php echo cleanCode($_POST['name']);?>'; </script>

The following injection will BYPASS CodeIgniter in "attribute" and "URL" context:

'; onmouseover=confirm(location);//

OR

'; onmouseover=confirm(cookie);//

In CodeIgniter's black-list you guys are checking against "document.cookie" and "window.location". The same purpose can be achieved by using cookie and location word! In above cases, if I inject

'; onmouseover=alert(window.location);//

I got the following output which stops XSS:

Attribute context: <div class='\'; onmouseover=alert&#40;[removed]&#41;;//'> URL context: <a href='\'; onmouseover=alert&#40;[removed]&#41;;//'>

Also in Chrome, the following injection bypassed URL context only:

j a vas cript:confirm(1);

If I simply inject javascript:alert(1) then CodeIgniter works perfectly and removed javascript but in the above manner, injection works.

Let me know, if I missed something :)

Regards

@soaj1664ashar

This isn't so much of an issue but more of an open question as to where unit testing support is heading for CI3.0.

It's awesome that unit tests are now a part of CI core, and it's great that the branch has been merged in and everything's starting to look good and official. I'm excited.

As you'll all know, currently the tests are in /tests. While this is fine, that folder seems to only facilitate system tests. What about application tests? It would make sense to move the /tests directory into /system/tests and have an /application/tests directory with a sample test inside it.

Is there a framework in place for application tests? There'll need to be mocks setup, methods to override core bits of CI functionality etc.

Is there anything in there that I'm missing to allow for this yet? If not, want me to look into it?

A while back when I was on the team I suggested we moved from 5.1 to 5.2. This made sense two or three years ago when this branch was meant to be "out soon" but time has moved on a little bit.

When people first started grumping about 5.2 being used I explained that I didn't think it was so bad for various reasons. I know that people use CodeIgniter on versions of PHP that are WAY out of date, and I know that even 3 years ago moving from 5.1 to 5.2 pissed people off.

What has made me spin on a dime here is that the .travis.yml does not actually test against 5.2 at all, and of course it can't because vfStream has a 5.3 dependency.

On top of that, PHPUnit probably needs 5.3 too depending on the version travis is supplying you with.

SO!

If you aren't testing against 5.2, you really really cannot release with docs saying that you support 5.2. CodeIgniter was always a cowboy framework with zero tests and that is turning around. In the past were dangerous untested releases done without warning. It was a bit of a nightmare, and I had to run back from the pub one day to patch and retag a version that somebody at EllisLabs had released without warning which had some bugs on one version of PHP. Without 5.2 in the .travis.yml version matrix once again I'd say you absolutely cannot say you support 5.2.

Instead of trying to find a way to test on 5.2, I'd urge you just to pop up the requirements to 5.3.

This may well still work on 5.2 and the only place it will fail is if a developer tries to run composer update, but that is only for testing, and the tests wont work anyway.

I'm not going crazy here. I think PHP 5.4 would be nice, but I know that these things need to be done slowly. If you lot want to go further than carry on, but everyone else should try and avoid complaining that the level of progress is not enough.

This patch allows back references of routes with a "php:" prefix to be processed with php, original style routes are unaffected by these changes. You can use original style routes and "php:" prefixed routes in the same route config file.

The encryption library has some remaining issues. It bluntly shoves data thru mcrypt_decrypt without checking data integrity. This can result in loss of data, even wrong variables, or worse.

i propose, next to prepending the $init_vect to the data, to also prepend a hash_hmac() from the data. This way the integrity of the to decode data can also be validated.

in this new setup encrypt->decode() can return false if the hash_hmac does not compute (e.g. the data was tampered with).

edit: this would probably cause problems with backwards compatibility with older/existing data. http://www.cryptofails.com/post/70059597528/codeigniter-encryption-is-not-authentication

As of 2.0.3, visibility is set to protected on the active record reset functions (_reset_select(), _reset_write()). I realize this conforms cleanly with the previously-unenforced private status of these functions -- but do we actually need/want protected visibility now that we're enforcing visibility in PHP5?

Seems to me that there should be a way to uniformly clear query-related active record bits from controllers/models/libraries and opening up these functions is an easy way to do that.

Reference: system/database/DB_active_rec.php - Lines 1995 and 2027

Throughout testing over the PDO drivers, was used on this build process : http://goo.gl/VR1a8

By now, on SQLite, MySQL and Postgre, all function was verified and work as expected.

@narfbg @lonnieezell @michalsn @MGatner @paulbalandan @samsonasik

Thank you for maintaining CI!

Recently, CI3 repository has less activities, but many users wish CI3 is maintained and support php8+, if it is possible. There are many candidates to help maintaining CI3 in forum, but no one has been selected yet. I also would like to help maintaining CI3 repository.

Anyway, I would like to talk about the future of CI3. (add maintainers, switch to 3.2.0+ or continue 3.1.12+, php8+ support, and so on)

Out of nowhere (on 12/1/22) , my app running on AWS decided to go into a hard loop while trying to load the bootstrap in Codeigniter.php in the above version under php 7.4.27. The UI is never loading due to this. There were no significant changes in the app.

It gets to require_once BASEPATH.'core/CodeIgniter.php at the bottom of index.php and keeps going back to this line. Thus the app never gets to run.

Any idea how to fix this?

Error: Message: str_replace(): Passing null to parameter #3 ($output) of type array|string is deprecated

You need to replace at line no. 457 in system/core/Output.php

$output = str_replace(array('{elapsed_time}', '{memory_usage}'), array($elapsed, $memory), $output);

with this $output = $output ? str_replace(array('{elapsed_time}', '{memory_usage}'), array($elapsed, $memory), $output): "";

The following code

public function ruri() {
    echo $this->uri->ruri_string();
}

generates this error message in php 8.1:

A PHP Error was encountered
Severity: 8192

Message: ltrim(): Passing null to parameter #1 ($string) of type string is deprecated

Filename: core/URI.php

Line Number: 641

Backtrace:

File: C:\project\path\application\controllers\Test.php
Line: 91
Function: ruri_string

File: C:\project\path\index.php
Line: 320
Function: require_once

This also affects other functions that use ruri_string, like $this->form_validation->run()

I noticed that although the test suite (tests/ directory) is present on the git branches, they are not kept on the tags. So when checking out a tag, we actually don't have the test suite

$ git log 3.1.13

commit bcb17eb8ba53a85de154439d0ab8ff1bed047bc9 (tag: 3.1.13)
Author: Andrey Andreev <[email protected]>
Date:   Thu Mar 3 15:21:49 2022 +0200

   [ci skip] 3.1.13 release

commit 2042929bab8ffc14faf6193de0107b7f95abbdaf (upstream/master)
Author: Andrey Andreev <[email protected]>
Date:   Thu Mar 3 15:09:04 2022 +0200

   [ci skip] Doc updates for 3.1.13 start and changelog entry for #6107

And in the bcb17eb8ba53a85de154439d0ab8ff1bed047bc9, all test suite is removed

Would it be possible to keep the test suite also on the tags?