Will phpCAS work with php 7.1?

[johanv]

I recently was looking into issue dokuwiki/dokuwiki#1904 with CAS-authentication in dokuwiki using the authplaincas extension, which uses phpCAS. phpCAS replaces the session ID by a 13-character string, and dokuwiki doesn't like session ID's smaller than 22 characters.

In the discussion on the issue, @mprins pointed out that in php 7.1 session ID's should have a length of at least 22. So I guess php 7.1 might break phpCAS. I didn't try it out though.

See also esn-org/authplaincas#9.

[jfritschi]

I guess this is something that we can fix.

The only reason we this strange mapping of CAS Ticket to session ID is that we need to have a mapping between CAS Ticket ID and PHP session to allow for a single lockout without having and database..

My idea to fix this would be use sha256("ST-YXXXX" + random_seed) to generate the session ID in the future. This would however require everyone to configure their own seed once during setup. We could also just use the domain/host as additional seed value.
Maybe better we use a combination: the domain by default and allow extra hardening via manual seed? This would be better if we want to slip it into the next patch.

@adamfranco: Any thoughts on this?

[mmarlett]

Yes, this breaks on php 7.1

[jfritschi]

I'm working on a patch

[grahamb]

Is there a timeframe for a release that works on PHP 7.1?

[kourylape]

Any update on this? This seems to be generating a lot of similar issues, so it seems pretty desirable.

[adamfranco]

My idea to fix this would be use sha256("ST-YXXXX" + random_seed) to generate the session ID in the future. This would however require everyone to configure their own seed once during setup. We could also just use the domain/host as additional seed value.
Maybe better we use a combination: the domain by default and allow extra hardening via manual seed? This would be better if we want to slip it into the next patch.

Is there a need for the random seed? hash("sha256", "ST-YXXXX") should give an appropriate-length session-id for short tickets as well as long tickets (#248, #224). A random-seed would certainly give increased entropy to make guessing the session-id harder, but might not be necessary when the CAS server returns a longer session-ticket value. Maybe making the random-seed optional would be best: It would be unneeded for CAS servers returning long tickets, would work ok with any ticket-length without modifying the application configuration, and still allow applications to upgrade their entropy if they are faced with a CAS server returning short tickets.