[RFC] [Discussion] Deprecate GET/POST sessions

1 month ago by Ayesh Karunaratne — view source

unread

Hi Internals,

I would like to start a discussion on a new RFC
https://wiki.php.net/rfc/deprecate-get-post-sessions

Please let me know whether the idea is clear and the RFC is understandable.

In particular, I am looking for any feedback as to why this is a bad
idea. The primary motivation behind this RFC is to reduce potential
security pitfalls.

Regards,
Kamil Tekiela

Hi Kamil,

I quite like the idea, and I think the RFC motivation, impact, and the
scope is clear as well.

The PHP 8.4 deprecations RFC also proposes to deprecate SID constant;
perhaps it's something worth mentioning in this RFC too?

1 month ago by Rob Landers — view source

unread

Hi Internals,

I would like to start a discussion on a new RFC
https://wiki.php.net/rfc/deprecate-get-post-sessions

Please let me know whether the idea is clear and the RFC is understandable.

In particular, I am looking for any feedback as to why this is a bad
idea. The primary motivation behind this RFC is to reduce potential
security pitfalls.

Regards,
Kamil Tekiela

For what it is worth, I’ve used this with great success on Google’s http-based job system in their cloud. Whether that is a good idea or not, I have no idea. But I suspect I’m not the only one that has relied on this behavior.

— Rob

1 month ago by Gina P. Banyard — view source

unread

Hi Internals,

I would like to start a discussion on a new RFC
https://wiki.php.net/rfc/deprecate-get-post-sessions

Please let me know whether the idea is clear and the RFC is understandable.

In particular, I am looking for any feedback as to why this is a bad
idea. The primary motivation behind this RFC is to reduce potential
security pitfalls.

Regards,
Kamil Tekiela

I think this makes sense to me.
I would possibly move the deprecation of the SID constant from the mass deprecation RFC to this one, as I would be very odd to have this accepted but not the latter.

Best regards,

Gina P. Banyard

1 month ago by Kamil Tekiela — view source

unread

---------- Forwarded message ---------
From: Anton Smirnov arokettu@outlook.com
Date: Sun, 3 Mar 2024 at 19:56
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
To: Kamil Tekiela tekiela246@gmail.com

Greetings!

I'm sorry for addressing you directly, if you can forward this message
to internals I'd be grateful. It seems outlook is still banned and I
can't re-subscribe with any other email (tried outlook, gmail, vivaldi
and a small private service)

Hi Internals,

I would like to start a discussion on a new RFC
https://wiki.php.net/rfc/deprecate-get-post-sessions

Please let me know whether the idea is clear and the RFC is
understandable.

In particular, I am looking for any feedback as to why this is a bad
idea. The primary motivation behind this RFC is to reduce potential
security pitfalls.

Regards,
Kamil Tekiela

Greetings!

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 think if you're making this hack impossible, you should provide an
alternative non-hackish way to do this.

Maybe just keep use_cookies = Off

A wild idea:

Add a temporary config

by default; current behavior;

throws a deprecation right from the introduction

cookies.use_post_get = On

do not set the session from POST and GET

cookies.use_post_get = Off

Remove it in 9 with the rest

keep use_cookies in PHP 9 with the updated meaning

I don't think it's a good solution but maybe it can spark a better one

Best,
Anton

1 month ago by Kamil Tekiela — view source

unread

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.

1 month ago by Anton Smirnov — view source

unread

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

1 month ago by Mel Dafert — view source

unread

From: Anton Smirnov arokettu@outlook.com
Date: Sun, 3 Mar 2024 at 19:56

Greetings!

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 think if you're making this hack impossible, you should provide an
alternative non-hackish way to do this.

Maybe just keep use_cookies = Off

A wild idea:

Add a temporary config

by default; current behavior;

throws a deprecation right from the introduction

cookies.use_post_get = On

do not set the session from POST and GET

cookies.use_post_get = Off

Remove it in 9 with the rest

keep use_cookies in PHP 9 with the updated meaning

I don't think it's a good solution but maybe it can spark a better one

Best,
Anton

I think the better option is to make this explicit and add a config along the lines of automatic_session_detection (name to be bikeshed) defaulting to On, and in your use-case setting it to Off explicitly.

Regards,
Mel

1 month ago by Kamil Tekiela — view source

unread

Hi Everyone,

Upon consideration of your comments, I have decided to adjust my RFC.
Please see the updated version
https://wiki.php.net/rfc/deprecate-get-post-sessions

Changes include:

session.use_cookies will not be deprecated
session.trans_sid_tags, session.trans_sid_hosts,
session.referer_check will get deprecated too (although I am not sure
how to implement the deprecation message yet)
the SID constant will also be deprecated as part of this RFC
mentioned that output_add_rewrite_var() will remain unaffected

Regards,
Kamil

23 days ago by Kamil Tekiela — view source

unread

If there are no more comments, I would like to put this RFC to vote in
the next two days.

23 days ago by Claude Pache — view source

unread

Le 4 avr. 2024 à 01:08, Kamil Tekiela tekiela246@gmail.com a écrit :

If there are no more comments, I would like to put this RFC to vote in
the next two days.

Hi,

In session_start(), it is possible to override ini settings like that:

session_start([ 'use_cookies' => '1', 'use_only_cookies' => '1', 'referer_check' => '' ]);

The relevant options should also be deprecated in that context.

A clarification: Suppose that I have session.use_only_cookie = 1 in my ini file (no deprecation warning), and I call ini_set("session.use_only_cookie", "1") in my code (no-op). Will the ini_set(...) invocation trigger a deprecation warning?

—Claude

21 days ago by Kamil Tekiela — view source

unread

In session_start(), it is possible to override ini settings like that:
session_start([ 'use_cookies' => '1', 'use_only_cookies' => '1', 'referer_check' => '' ]);
The relevant options should also be deprecated in that context.

Yes, they are. You can see that in my draft PR
https://github.com/php/php-src/pull/13578

A clarification: Suppose that I have session.use_only_cookie = 1 in my ini file (no deprecation warning), and I call ini_set("session.use_only_cookie", "1") in my code (no-op). Will the ini_set(...) invocation trigger a deprecation warning?

As mentioned in the RFC, only changing the option to the deprecated
value triggers the deprecation. You can verify this using my draft PR.
Similarly, if your INI file triggers a deprecations due to for example
session.use_only_cookie=0 and then in your PHP file you change it
using ini_set("session.use_only_cookie", "1") or using the argument to
session_start(), it will only trigger the deprecation during startup
and not during runtime of the script.

1 month ago by Bruce Weirdan — view source

unread

Hi Kamil

I would like to start a discussion on a new RFC
https://wiki.php.net/rfc/deprecate-get-post-sessions

Please let me know whether the idea is clear and the RFC is understandable.

It would probably make sense to also list session.trans_sid_tags and
session.trans_sid_hosts as
deprecated. And mentioning that output_add_rewrite_var() is
unaffected wouldn't harm either.

--
Best regards,
Bruce Weirdan mailto:weirdan@gmail.com