Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
>1. In session_start(), it is possible to override ini settings like that:
>
>```php
>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
> 2. 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.
Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
> Le 4 avr. 2024 à 01:08, Kamil Tekiela a écrit :
>
> If there are no more comments, I would like to put this RFC to vote in
> the next two days.
Hi,
1. In session_start(), it is possible to override ini settings like that:
```php
session_start([ 'use_cookies' => '1', 'use_only_cookies' => '1',
'referer_check' => '' ]);
```
The relevant options should also be deprecated in that context.
2. 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
Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
If there are no more comments, I would like to put this RFC to vote in the next two days.
Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
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
Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
>From: Anton Smirnov >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: > >1) 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 > >2) 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
Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
Hi Kamil On Mon, Mar 4, 2024 at 4:43 PM Kamil Tekiela wrote: > 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:weir...@gmail.com
Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
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
Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
> > 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?
Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
-- Forwarded message - From: Anton Smirnov Date: Sun, 3 Mar 2024 at 19:56 Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions To: Kamil Tekiela 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) On 02/03/2024 23:10, Kamil Tekiela wrote: > 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: 1) 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 2) 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
Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
On Saturday, 2 March 2024 at 21:10, Kamil Tekiela wrote: > 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
Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
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.
Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
On Sat, Mar 2, 2024, at 22:10, Kamil Tekiela wrote: > 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
[PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
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
