On 03/03/2024 23:33, Kamil Tekiela wrote:
> Hi Anton,
>
>> As I know some session-related middlewares force custom-only session_id
>> handling by setting
>>
>> use_cookies = Off
>> use_only_cookies = On
>>
>> and then using session_id(...) directly
>>
>> Example:
>>
https://github.com/middlewares/php-session/blob/master/src/PhpSession.php#L137
>
> I was not aware that some frameworks do that. But I don't understand
> how this works. IMHO if you disable the use of cookies, but you also
> tell PHP to use only cookies it creates an impossible scenario. Isn't
> that right?
>
> The way I understand it is that there are 2 ways of propagating
> session ID: cookies and GET/POST. You can tell PHP to use both or
> either one of them, but not neither.
>
> Only cookies:
> use_only_cookies = On
> use_cookies = On
>
> Only GET/POST:
> use_only_cookies = Off
> use_cookies = Off
>
> Both:
> use_only_cookies = Off
> use_cookies = On
>
> The remaining 4th combination should create an impossible scenario.
> Does it mean to use neither option?
>
> I can change the proposal to deprecate only use_only_cookies=Off and
> session.use_trans_sid=On and leave session.use_cookies alone, but I
> just can't think of a situation when leaving that setting in PHP would
> make sense.
>
> I am probably missing something very important and I would appreciate
> it if someone could explain to me what it is. I wouldn't want to
> deprecate something that is used in popular frameworks.
Hi Kamil
The remaining 4th combination creates the situation when session
creation is always a responsibility of the userland code.
(by using session_id($id))
In the link I provided it is done by PSR-7/15 purists that think that
only the request emitter should handle headers, not PHP itself and it
includes cookie headers.
For non-purists it is still a useful scenario, for example it allowed to
use SameSite attribute on a session cookie before PHP 7.3
