PHP 8.3.1 Warning Errors session ini_set settings

[Zohaib Akram]

Hi Chuck

I am doing upgradation from php 7.4 to PHP 8.3.1 and i am using the master copy of tsugi in my application. I am getting deprecation and waning errors in tsugi config file

Deprecated: Creation of dynamic property Tsugi\Config\ConfigInfo::$memcached is deprecated in /var/www/html/sc-lti/tsugi/config.php on line 463

Warning: ini_set(): Session ini settings cannot be changed after headers have already been sent in /var/www/html/lti-project/tsugi/config.php on line 465

Warning: ini_set(): Session ini settings cannot be changed after headers have already been sent in /var/www/html/lti-project/tsugi/config.php on line 466

Warning: ini_set(): Session ini settings cannot be changed after headers have already been sent in /var/www/html/lti-project/tsugi/config.php on line 470

Warning: ini_set(): Session ini settings cannot be changed after headers have already been sent in /var/www/html/lti-project/tsugi/vendor/tsugi/lib/include/setup.php on line 88

Warning: session_start(): Session cannot be started after headers have already been sent in /var/www/html/lti-project/index.php on line 399

What should i do to avoid these warnings. How i can handle these type of errors? Can you please help

Zohaib

[Charles Severance]

This has been fixed in master:

https://github.com/tsugiproject/tsugi/commit/ffc437da39f2104f8922035db0d4d4b3148b126c#diff-8a9d065b19bab61b871271eb3eace1c98506ab8d9f1ce60f2ee67fc7133db9f1

Just do a git pull and all should be well.

Thanks.

/Chuck

Hi Chuck

Zohaib<lti-error.png>

--
You received this message because you are subscribed to the Google Groups "Tsugi Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tsugi-dev+...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/tsugi-dev/9c3c839d-4d47-4a5f-8833-8688140dae9an%40apereo.org.
<lti-error.png>

[Zohaib Akram]

Thanks Chuck for fixing this issue.

Now also i am getting the below errors in master. I also attached the screenshot

Deprecated: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in /var/www/html/sc-lti/tsugi/vendor/tsugi/lib/src/Core/LTIX.php on line 805

Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/sc-lti/tsugi/vendor/tsugi/lib/src/Core/LTIX.php:805) in /var/www/html/sc-lti/tsugi/vendor/tsugi/lib/src/Core/LTIX.php on line 808

Deprecated: Calling get_class() without arguments is deprecated in C:\xampp\htdocs\sc-lti\tsugi\vendor\google\apiclient\src\Http\REST.php on line 58

[Charles Severance]

Zohaib,

Do another “git pull

This one is a bigger one because I had to advance the version of google/apiclient and that caused other things to advance as well. 

If you look at 

https://github.com/googleapis/google-api-php-client

You will see that Google had to update their code in the past two weeks because of PHP 8.3 :)

This also fixes a dependabot warning for phpseclib.

It updates a lot of files - but I think is low-risk.  I made a pre-upgrade branch in case this has any problems (which I don’t expect).

https://github.com/tsugiproject/tsugi/tree/pre-gc-upgrade-2023-01-22

Please test and let me know.

(By the way) Are you using the Google Classroom code?  If so, I would like to know more about your experiences.

Thanks.

/Chuck

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/tsugi-dev/9bdfc401-2eb2-48e8-ac99-e4d999befeb7n%40apereo.org.
<Screenshot 2024-01-22 145041.png><Screenshot 2024-01-22 150355.png>

[Zohaib Akram]

Hi Chuck

I am getting some more deprecation warning in the master branch of tsugi  while i was doing testing LTI 1.3 launch from canvas after PHP upgradation from 7.4 to 8.3.1 . Can you please help me into that. Below are the details

Deprecated: openssl_encrypt(): Passing null to parameter #1 ($data) of type string is deprecated in /var/www/html/sc-lti/tsugi/vendor/tsugi/lib/src/Crypt/AesOpenSSL.php on line 37

Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/sc-lti/tsugi/vendor/tsugi/lib/src/Crypt/AesOpenSSL.php:37) in /var/www/html/sc-lti/tsugi/vendor/tsugi/lib/src/Core/LTIX.php on line 808

[Charles Severance]

Zohaib,

Sorry this one took a little longer.  I wanted to upgrade one of my environments to PHP 8.3 in case there were a bunch of these errors and I could fix them all at once.

I fixed this in master *and* tested it in my own PHP 8.3 environment.

Let me know if it works.

/Chuck

On Feb 1, 2024, at 4:21 AM, Zohaib Akram <techniso...@gmail.com> wrote:

Hi Chuck

[Zohaib Akram]

Thanks Charles for your help.

It is working now.

[Charles Severance]

On Feb 7, 2024, at 3:48 AM, Zohaib Akram <techniso...@gmail.com> wrote:

It is working now.

That is great news - thanks for finding the few little things that broke in 8.3 so the rest of us won’t bump into them when we upgrade PHP.

/Chuck

[Syed Mushran]

Hello Dr. Chuck,

After this commit, it appears that the sessions become dysfunctional when two or more instances of Tsugi are running. In the config-dist.php file, the value for `$CFG->memcache` is set, but in LTIX.php, we are checking for `$CFG->memcached`. I suspect this mismatch is causing it to fail to find a session.

Any assistance or direction regarding this matter would be greatly appreciated.

Thanks,

Syed Mushran

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/tsugi-dev/C61A196A-4BA0-4A28-86BA-E5051ED29811%40umich.edu.

[Charles Severance]

Syed,

Thanks.  I have not run any Tsugi servers in clustered environments so I sadly am not testing this 24x7 like I used to.   Sadly Tsugi is so performant that I have not had it behinf a load balancer for while.

Looking at this - iit is most likely that LTIX.php is correct and config-dist.php is wrong.  Let me know if you disagree.

I will look into it a bit and come up with a fix - but your input is very welcomed.  And if youare running a load balancer - you can test.

Is this a new or existing system, if this is an existing system - which of the two configuration settings are you using?

Thanks.

/Chuck

On Feb 13, 2024, at 2:38 AM, Syed Mushran <syedm...@gmail.com> wrote:

Hello Dr. Chuck,

After this commit, it appears that the sessions become dysfunctional when two or more instances of Tsugi are running. In the config-dist.php file, the value for `$CFG->memcache` is set, but in LTIX.php, we are checking for `$CFG->memcached`. I suspect this mismatch is causing it to fail to find a session.

<714a6be0-2b1c-4689-96b1-5c70973774c2.png>

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/tsugi-dev/CANA3ND25qjOC1n2Sn%3DMEEavjmCUUgqbZWxcu2ERbaFYjySBaSw%40mail.gmail.com.

[Charles Severance]

Syed,

I fixed it in:

https://github.com/tsugiproject/tsugi/commit/6724e1af08f30498edc4d2e303bb84be81dccabd

But you need to set $CFG->memcached *and* add a segment of code to your config.php:

https://github.com/tsugiproject/tsugi/blob/master/config-dist.php#L448

It turns out that the code in LTIX.php - restore session is not the code that actually restores the session.

When you are running multiple servers, the code in config.php tells PHP to store the sessions using either memcache or memcached. 

They both use a memcached server - memcache is a pure PHP implementation and memcached is a PHP+C implementation.  Both work well.  You need to install whichever one you plan to use with apt-get on ubuntu.  My Ubuntu install scripts install both.  

If this is non-Linux (i.e. windows), I might prefer memcache as it does not need any non-php libraries dropped in.

Back to the restoreLTISession() in LTIX.php, that code does not restore the session - PHP restores the session - restoreLTISession() was an experiment to see if when PHP could not restore a session, I would try to restore it manually.  In all my testing, I don’t think my super complex recovery code in LITX.php ever found a lost session.

I *am* using memcached all the time on my production servers even though none of my servers are load-balanced any more.  It speeds up single instance installs as well, keeping load off the database and local file system.

So if you git pull, you should be able to add the $CFG->memached option *and* the code to config.php and you should be lad balancing all day long.

Let me know how it goes.

/Chuck

P.S. The removal of the memcached config variable was part of my PHP 8.0 cleanup.  Thanks PHP 8 :)

On Feb 13, 2024, at 2:38 AM, Syed Mushran <syedm...@gmail.com> wrote:

Hello Dr. Chuck,

After this commit, it appears that the sessions become dysfunctional when two or more instances of Tsugi are running. In the config-dist.php file, the value for `$CFG->memcache` is set, but in LTIX.php, we are checking for `$CFG->memcached`. I suspect this mismatch is causing it to fail to find a session.

<714a6be0-2b1c-4689-96b1-5c70973774c2.png>

[Syed Mushran]

Hello Dr. Chuck,

Thank you for your prompt response, as usual! I just wanted to share my findings with you, and I'm pleased to see that our conclusions align. Below is the draft of the email I had prepared:

In my earlier response, I referenced a comment in your code stating "Prefer memcache over Memcached" in ConfigInfo.php. However, I had been utilizing MemcacheD before our PHP 8.3 upgrade, and it functioned seamlessly without any problems.

Nevertheless, I've modified the variable in ConfigInfo.php and reintroduced the following code snippet to ensure its functionality.

if ( isset($CFG->memcached) && strlen($CFG->memcached) > 0 ) {
    ini_set('session.save_handler', 'memcached');
    ini_set('session.save_path', $CFG->memcached);
    // https://github.com/php-memcached-dev/php-memcached/issues/269
    ini_set('memcached.sess_locking', '0');
    ini_set('memcached.serializer', 'php');
    ini_set('session.serialize_handler', 'php_serialize');
}
 

Thank you for your ongoing assistance, and may you continue to thrive!

Thanks,

Syed Mushran

[Charles Severance]

On Feb 14, 2024, at 1:49 AM, Syed Mushran <syedm...@gmail.com> wrote:

Thank you for your prompt response, as usual! I just wanted to share my findings with you, and I'm pleased to see that our conclusions align.

Nice.

In my earlier response, I referenced a comment in your code stating "Prefer memcache over Memcached" in ConfigInfo.php. However, I had been utilizing MemcacheD before our PHP 8.3 upgrade, and it functioned seamlessly without any problems.

I saw that comment and before I fixed things, I needed to figure out why (a) I deleted memcached, (b) wrote that comment, and (c) why (like you) I had been using memcached all along.

It was indeed a puzzle.

Then I realized that the *only* real reason to prefer memcache (not d) was a simpler install (back sometime long ago).  Once I updated my install scripts to install both (I love Ubuntu) - that comment was in essence moot - so I updated the comments in ConfigInfo and config-dist.php - so as not to confuse my future self (again) :)

Let me know how the cluster stuff works for you.   Things like Tsugi upgrades, database upgrades, and tool additions have a few little differences in a multi-server load balanced / auto scale environment.  But since I all my servers are well sized for their loads, I don’t need to auto scale for now.  So keep an eye on things.

Thanks.

/Chuck