More Progress on Tsugi
5 views
Skip to first unread message
Charles Severance
Mar 5, 2026, 5:25:38 PM (9 days ago) Mar 5
to Tsugi Developers
Hi all,
I continue to move Tsugi forward in terms of security and cleanup. I am highly motivated to get ahead of the expected end of support in PHP 9 for “trans_sid” which is the the foundation of cookiless session support in PHP.
The good news is that as I have been laying some groundwork for keeping Tsugi working when PHP removes cookiless session support, it is looking increasingly doable and in some ways “kind of elegant”. If things keep going well - we might be ready to turn off trans_sid in PHP perhaps this summer - a year before PHP 9 will jam it down our throats :)
The high level is that with trans_sid and some clever javascript Tsugi almost works like a Single Page Application (SPA). Whether you have noticed or not, Tsugi maintains its session in an iframe without cookies, Tsugi *already* can have different sessions in multiple iframes simultaneously and can have different sessions on different tabs! It has been kept working for over 10 years even though PHP broke trans_sid in a few releases minor releases during the PHP 7.x era. :)
The first thing you will see if you stay close to master is that the session name for the LTI sessions is no longer PHPSESSID - so you won’t see PHPSESSID as a GET parameter any more. If you upgrade your LTI launches will end up with session ids on the URL but it will look as follows:
https://www.dj4e.com/mod/tdiscus/?_LTI_TSUGI=56ef51e85e621cef8eeb611a91f51f79
You won’t have to do anything - Sessions as a result of LTI launches will just be named differently by the LTI code in Tsugi.
Separating these is good so the cookie and cookiless sessions live in a separate namespace. We don’t want to the cookie session id to be mistakenly used for an LTI session or vice versa. Naming them differently helps make sure we don’t confuse them in the parts of PHP that automatically handle sessions for us.
Other small improvements include better recovery from expired sessions. Instead of sending users to www.tsugi.org with a useless message - users can be set directly back to Canvas, Sakai or their LMS with a message to relaunch. These are the kinds of “tidy up” things that will be fixed as we look over the session handling closely and take advantage of modern things like service workers and sessionStorage to make things work better. Modern browsers are harsh when it comes to cookies - but there are new features that we can use if we write the code to use them,
Like everything in Tsugi - change will be gradual and evolutionary with an eye not to force you to upgrade unless you want to. I will dogfood all the changes in my production servers long before you see them. I want to keep Tsugi working on as wide a range of versions of PHP as I can. I am hopeful that I can have a version of Tsugi that runs both on late 8.X PHP and early 9.x PHP - but that will be up to the PHP gods and how many dumb unnecessary breaking changes they drop into PHP 9.0.
I would mention that if you are super far behind on your PHP, Linux, and Tsugi versions - you might want to imagine catching up at some point. There are security issues that are getting fixed - no giant holes - just cleaning things up before they become a problem. Also there are a lot of Accessibility fixes going into the master that won’t be back ported. At least in the US there is a lot of fuss about Accessibility and it is best if Tsugi if well above average in accessibility and I keep improving Tsugi support for accessibility because it is (a) not too hard and (b) kind of fun with AI :)
As always - questions always welcome.
/Chuck
I continue to move Tsugi forward in terms of security and cleanup. I am highly motivated to get ahead of the expected end of support in PHP 9 for “trans_sid” which is the the foundation of cookiless session support in PHP.
The good news is that as I have been laying some groundwork for keeping Tsugi working when PHP removes cookiless session support, it is looking increasingly doable and in some ways “kind of elegant”. If things keep going well - we might be ready to turn off trans_sid in PHP perhaps this summer - a year before PHP 9 will jam it down our throats :)
The high level is that with trans_sid and some clever javascript Tsugi almost works like a Single Page Application (SPA). Whether you have noticed or not, Tsugi maintains its session in an iframe without cookies, Tsugi *already* can have different sessions in multiple iframes simultaneously and can have different sessions on different tabs! It has been kept working for over 10 years even though PHP broke trans_sid in a few releases minor releases during the PHP 7.x era. :)
The first thing you will see if you stay close to master is that the session name for the LTI sessions is no longer PHPSESSID - so you won’t see PHPSESSID as a GET parameter any more. If you upgrade your LTI launches will end up with session ids on the URL but it will look as follows:
https://www.dj4e.com/mod/tdiscus/?_LTI_TSUGI=56ef51e85e621cef8eeb611a91f51f79
You won’t have to do anything - Sessions as a result of LTI launches will just be named differently by the LTI code in Tsugi.
Separating these is good so the cookie and cookiless sessions live in a separate namespace. We don’t want to the cookie session id to be mistakenly used for an LTI session or vice versa. Naming them differently helps make sure we don’t confuse them in the parts of PHP that automatically handle sessions for us.
Other small improvements include better recovery from expired sessions. Instead of sending users to www.tsugi.org with a useless message - users can be set directly back to Canvas, Sakai or their LMS with a message to relaunch. These are the kinds of “tidy up” things that will be fixed as we look over the session handling closely and take advantage of modern things like service workers and sessionStorage to make things work better. Modern browsers are harsh when it comes to cookies - but there are new features that we can use if we write the code to use them,
Like everything in Tsugi - change will be gradual and evolutionary with an eye not to force you to upgrade unless you want to. I will dogfood all the changes in my production servers long before you see them. I want to keep Tsugi working on as wide a range of versions of PHP as I can. I am hopeful that I can have a version of Tsugi that runs both on late 8.X PHP and early 9.x PHP - but that will be up to the PHP gods and how many dumb unnecessary breaking changes they drop into PHP 9.0.
I would mention that if you are super far behind on your PHP, Linux, and Tsugi versions - you might want to imagine catching up at some point. There are security issues that are getting fixed - no giant holes - just cleaning things up before they become a problem. Also there are a lot of Accessibility fixes going into the master that won’t be back ported. At least in the US there is a lot of fuss about Accessibility and it is best if Tsugi if well above average in accessibility and I keep improving Tsugi support for accessibility because it is (a) not too hard and (b) kind of fun with AI :)
As always - questions always welcome.
/Chuck
Reply all
Reply to author
Forward
0 new messages