Further update - debugging through this and the original issue gets fixed by changing the column type to a NVARCHAR. However, a further error is thrown because the code is unable to generate a SessionKey so it saves the Session record in the database without an ID. The error is thrown when it tries to update this record using the blank id.

I've tracked it back to these lines in CSecurityManager.php;

public function generateSessionRandomBlock()
{
    ini_set('session.entropy_length',20);       
    if(ini_get('session.entropy_length')!=20)
        return false;

    <other code>

}

The session.entropy_length never gets set so the generateSessionRandomBlock method returns a false. Setting the value in the php.ini doesnt seem to affect it either. From reading the php session docs, this setting was removed in PHP 7.1 : http://php.net/manual/en/session.configuration.php

If I remove the lines of code above from the function, then the function works and successfully returns the id. Note that any observations here apply to PHP 7.2 as my dev box is running 7.2 but our live server is running 7.0.3. I seem to be getting the initial issue both on PHP 7.2 AND 7.0.3.

I'm puzzled as to why the ini_set & ini_get may be failing in both PHP environments? Anyone have any ideas?

Another update :)

the ini_set & ini_get are only failing on my local dev machine (running PHP 7.2.0). I suspect that this is either a configuration issue or there is another issue here that only occurs with the PHP 7.2.0.

On my "live" machine (I have limited access to this box) it runs PHP 7.0.3 and I can see that its successfully creating the Session ID (by sniffing the data going into SQL Server). It isn't saving it to the database, but I suspect that is simply a change of column type - we had made this change but I think my colleague made it in the wrong database.

I intend on making the column change again and then retesting it. I'll update further when thats complete.

You're doing some great job in analyzing the bugs, feel free to submit some PR for the fixes.

Been away for a week, but I have a further update - the change of column type fixes the issue & sessions can be generated. However, I did hit a further code issue that I have a fix for and am preparing for a commit.

When I made the column change from varbinary to nvarchar I began hitting a further issue via the API. The error I was seeing is this: "CDbCommand failed to execute the SQL statement: SQLSTATE[IMSSP]: An error occurred translating string for input param 1 to UCS-2: Error code 0x54."

After a session is generated a record is created with an id (sessionToken) & data (username) fields which are stored in the Sessions table. Subsequent calls to the API use this sessionToken to lookup the username stored in the data field. In my scenario, after retrieving the value from the "data" column, the value was coming back in a different charset - it was appearing as a black diamond with question mark in the debugger.

While stepping through the code to prepare this update, I have found and fixed the issue. The issue is the afterFind() function in the Session class. This code;

    $sDatabasetype = Yii::app()->db->getDriverName();
    // MSSQL delivers hex data (except for dblib driver)
    if ($sDatabasetype == 'sqlsrv' || $sDatabasetype == 'mssql') {
        $this->data = $this->hexToStr($this->data); 
    }

Assumes that the data coming back from a SQL Server database is Hex and so attempts to convert the Hex to String. Its a valid assumption, however, as the column type has been changed to a nvarchar, this code is unnecessary. Removing this code means that it keeps the value from the data field, doesn't attempt to decode it and so works successfully.

I'm going to prepare a code fix and pull request (using my personal account githubLewis). I'll update this ticket when its completed.

thank you very much for the PR

PR complete and available here for review: https://github.com/LimeSurvey/LimeSurvey/pull/1113

In this PR I've also included some defensive coding changes that are required for my development environment (otherwise the code throws errors and is unusable), these aren't required to fix the reported issue.

thx

@c_scmitz : since remote_control save ONLY user name in session database : https://github.com/LimeSurvey/LimeSurvey/blob/8bcc208f02549a848184dab165600ca1471506f3/application/helpers/remotecontrol/remotecontrol_handle.php#L55

Maybe the best solution are : create a remotecontrol model and DB. We just need a pk + timedate + a varchar for this.

If i make the patch for 3.16.X : are you OK to merge it ?
This don't break existing system : transparent for user
Only current script (using a previous sSessionKey) must be reloaded, but after an update : it‘s clearly needed.

I test RC with manually updating data column to text : it's OK.
Since all is broken with mssql : can we just set data column to text ?

I can test session with MsSql DB, but don't do the fix if it's not accepted after.

Remind : i need to update DBVersion for all DB : then develop or master ?

To be tested
https://github.com/LimeSurvey/LimeSurvey/pull/1265

@MerkOne : can you check remote control AND DBsession with https://github.com/LimeSurvey/LimeSurvey/pull/1265 please.

https://github.com/LimeSurvey/LimeSurvey/commit/1a28a4639865647c8756d9b07c740be4e9df35f1

Fix committed to master branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=28970