Carl,
You are going in the wrong direction. There are two sessions - one from the WordPress and one from the LTI tool. Thy are not the same. The launch sequence is like this:
1) WordPress produces a form with the url, key, and secret and the OAuth signature + values
2) The browser POSTs that form to the Tsugi Tool using JavaScript.
3) When Tsugi receives that POST, it checks the key and secret for validity and if the key and secret are correct it makes a new session and puts the Tsugi login information into this new session.
4) Tsugi does a 302 redirect back to itself with the PHPSESSID as a GET parameter. When Tsugi sees the GET request, it looks in the session for the Tsugi login information before it proceeds.
The message you are seeing is because you indeed made a session but it does not have the required Tsugi log in data.
You cannot “transfer” the WordPress session to Tsugi - that won’t work - you just need to launch Tsugi with the URL, key, and secret and let Tsugi do its thing.
I am still trying to figure out why the normal flow does not work for you.
Does each user already have a WordPress account that they are logged in to? The goal of LTI is to be logged in on one system (i.e. WordPress) and pass the log in information to a second system so the second system can *create* an account for that user.
The WordPress LTI Consumer is designed for that use case - Wordpress is being used as an LMS - all the students have WordPress accounts and they want to launch the tool and have those logins follow them to the tool.
Make sense?
/Chuck