Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi Pierre, On Thu, May 12, 2016 at 10:53 AM, Pierre Joye wrote: > My answer is clearly no. We must rather simplified improved the > session implementations and APIs, focusing purely on its core > purposes, managing session data storage and provides interfaces&APIs > to match application needs. We

Re: [PHP-DEV] [RFC] Allow loading extensions by name

On Thu, May 12, 2016 at 2:34 AM, Fleshgrinder wrote: > On 5/10/2016 10:07 PM, Lester Caine wrote: >> I would be most surprised to find windows users running php command >> line, but I suppose I am somewhat out of the loop on that side. All my >> windows users run PHP on a web server and have troub

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

On Thu, May 12, 2016 at 4:13 AM, Yasuo Ohgaki wrote: > Hi Arvids, > I don't force, but CSRF protection is optional. If you don't need it, > don't use simply. You actually do by using ini settings for that, or potentially force it. Now the main issue is not about whether or not csrf is a good th

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi Andrey, On Thu, May 12, 2016 at 7:24 AM, Andrey Andreev wrote: > On Thu, May 12, 2016 at 12:39 AM, Yasuo Ohgaki wrote: >> >> Hi Andrey, >> >> On Wed, May 11, 2016 at 10:40 PM, Andrey Andreev wrote: >> > >> > It assumes, and thus also encourages, that users have an active session >> > at >> >

Re: [PHP-DEV] [RFC] Pipe Operator

Hi! > If the issue is $$ feels too Perl like, what is the alternative? Is > there another way to chain methods cleanly? Well, that's a loaded question. It presumes we already agreed on needing to chain methods using special syntax outlined in the RFC - which we didn't - and the only problem is

Re: [PHP-DEV] [RFC] Pipe Operator

On Mon, May 9, 2016, at 10:21 PM, Stanislav Malyshev wrote: > Hi! > > > |> seems like a common symbol to use, but it admittedly does look a > > So, usage in one semi-obscure language (F#) and one completely obscure > one (Elixir) - Clojure doesn't use |> - and one proposal for Javascript > now qu

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi, On Thu, May 12, 2016 at 12:39 AM, Yasuo Ohgaki wrote: > Hi Andrey, > > On Wed, May 11, 2016 at 10:40 PM, Andrey Andreev wrote: > > > > It assumes, and thus also encourages, that users have an active session > at > > all times - this is bad. You're not supposed to start a session for a > use

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi Andrey, On Wed, May 11, 2016 at 10:40 PM, Andrey Andreev wrote: > Hi, > This gets a -1 from me as well. > > Much has been said already about why this is a bad idea, to the point where > I don't know why there's still discussion around it. But here's one more > reason ... > > It assumes, and th

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi Arvids, On Wed, May 11, 2016 at 5:54 PM, Arvids Godjuks wrote: > 2016-05-11 11:05 GMT+03:00 Yasuo Ohgaki : >> >> Hi Arvids, >> >> On Wed, May 11, 2016 at 4:33 PM, Arvids Godjuks >> wrote: >> > i'm -1 on the CSRF in the sessions at all. Even more -1 on having it on >> > by >> > default and hav

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi Kinn, On Wed, May 11, 2016 at 8:36 PM, Kinn Julião wrote: > You're making confusion between CSRF and Session Hijacking... In any moment > I mentioned about hijacking someone else's session, but to still being able > to CSRF (Cross Site Request Forgery). > > Any other remote source would still

[PHP-DEV] wiki.php.net bug

Hi, wiki.php.net seems to have a bug that prevent saving document. How to reproduce - Edit page - Preview page - Try to save, then it errors Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.p

Re: [PHP-DEV] [RFC] Allow loading extensions by name

On 5/10/2016 10:07 PM, Lester Caine wrote: > I would be most surprised to find windows users running php command > line, but I suppose I am somewhat out of the loop on that side. All my > windows users run PHP on a web server and have trouble even accessing > the command line. > I am using Window

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Post from tablet seems to have gone missing ... On 11/05/16 16:41, Andrey Andreev wrote: > On Wed, May 11, 2016 at 5:46 PM, Lester Caine wrote: > >> On 11/05/16 14:40, Andrey Andreev wrote: >>> Therefore, while the session store *after login* is suitable for token >>> storage, CSRF protection by

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

On Wed, May 11, 2016 at 7:16 PM, Niklas Keller wrote: > > 2016-05-11 17:41 GMT+02:00 Andrey Andreev : > >> >> Your login form too needs CSRF protection. It's a chicken and egg problem. >> > > Not really. As long as you don't have the credentials. > You can't make any requests as the authenticated

[PHP-DEV] Re: Single Stack for all generators

On Wed, May 11, 2016 at 4:54 PM, Dmitry Stogov wrote: > Hi, > > > Nikita, please review the patch > https://gist.github.com/dstogov/06116f1610f45f8152ine3a9927c6c243ac > > It's the next attempt to use the single stack for all generators. > > Now I don't see any problems or BC breaks. > > > In cas

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

2016-05-11 17:41 GMT+02:00 Andrey Andreev : > On Wed, May 11, 2016 at 5:46 PM, Lester Caine wrote: > > > On 11/05/16 14:40, Andrey Andreev wrote: > > > Therefore, while the session store *after login* is suitable for token > > > storage, CSRF protection by default just doesn't belong in ext/sessi

Re: [PHP-DEV] Single Stack for all generators

Looks like there is an "ine" in the link: Correct link: https://gist.github.com/dstogov/06116f1610f45f81523a9927c6c243ac Bob > Am 11.05.2016 um 17:02 schrieb Joe Watkins : > > 404 > > Cheers > Joe > > On Wed, May 11, 2016 at

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

On Wed, May 11, 2016 at 5:46 PM, Lester Caine wrote: > On 11/05/16 14:40, Andrey Andreev wrote: > > Therefore, while the session store *after login* is suitable for token > > storage, CSRF protection by default just doesn't belong in ext/session. > > If I am using php simply to 'add detail' to an

Re: [PHP-DEV] Single Stack for all generators

404 Cheers Joe On Wed, May 11, 2016 at 3:54 PM, Dmitry Stogov wrote: > Hi, > > > Nikita, please review the patch > https://gist.github.com/dstogov/06116f1610f45f8152ine3a9927c6c243ac > > It's the next attempt to use the single stack for all generators. > > Now I don't see any problems or BC bre

[PHP-DEV] Single Stack for all generators

Hi, Nikita, please review the patch https://gist.github.com/dstogov/06116f1610f45f8152ine3a9927c6c243ac It's the next attempt to use the single stack for all generators. Now I don't see any problems or BC breaks. In case "yield" is used as an expression in context of function call. e.g. var

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

On 11/05/16 14:40, Andrey Andreev wrote: > Therefore, while the session store *after login* is suitable for token > storage, CSRF protection by default just doesn't belong in ext/session. If I am using php simply to 'add detail' to an element of a page that does not require the client to be logged

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

On 11/05/2016 14:07, Kinn Julião wrote: So following your example then. You could place an HTML page on a completelu different site... maybe this page: https://gist.github.com/kinncj/6ad5f5ef8d8c36eb5f844fb802a67b7a#file-attacker_example_net :-) Neither of the files in that gist are demonstrati

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi, This gets a -1 from me as well. Much has been said already about why this is a bad idea, to the point where I don't know why there's still discussion around it. But here's one more reason ... It assumes, and thus also encourages, that users have an active session at all times - this is bad. Y

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

So following your example then. You could place an HTML page on a completelu different site... maybe this page: https://gist.github.com/kinncj/6ad5f5ef8d8c36eb5f844fb802a67b7a#file-attacker_example_net :-) As I mentioned in comments there: /* >From this point, this attack will only work if: 1 - CO

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

On 11/05/2016 13:22, Kinn Julião wrote: CSRF is not related to spam or rate limiting, it is related to impersonation. A spam bot can simply repeatedly request new HTML forms and scrape out the hidden input. The Spam bot was just an example, contering his own example. And it still a cross site

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

On 11/05/2016 09:13, Yasuo Ohgaki wrote: Why SESSION_CSRF_POST, 'csrf_validate'=>SESSION_CSRF_POST]); ?> and protect CSRF attacks against POST requests are bad for PHP and its users? 1) Because it gives users a false sense of security. If you say "turn this on and don't think about CSRF", an

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

And again, I'm bashing against/based in his poor example for asynchronous requests... On May 11, 2016 8:22 AM, "Kinn Julião" wrote: > > CSRF is not related to spam or rate limiting, it is related to > impersonation. A spam bot can simply repeatedly request new HTML forms and > scrape out the hidd

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

> CSRF is not related to spam or rate limiting, it is related to impersonation. A spam bot can simply repeatedly request new HTML forms and scrape out the hidden input. The Spam bot was just an example, contering his own example. And it still a cross site request... Either if it comes from a bot

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

On 11/05/2016 12:36, Kinn Julião wrote: You're making confusion between CSRF and Session Hijacking... In any moment I mentioned about hijacking someone else's session, but to still being able to CSRF (Cross Site Request Forgery). CSRF generally implies tricking an authenticated user into making

Re: [PHP-DEV] [RFC] Allow loading extensions by name

Le 11/05/2016 à 06:59, Joe Watkins a écrit : Morning, In this case, it is currently impossible to write a single configuration file that will work in both environments, forcing developers to manually maintain two separate versions of the file. I'm aware this has been mentioned in this thread,

Re: AW: [PHP-DEV] [RFC] Allow loading extensions by name

On 11/05/16 12:53, François Laupretre wrote: > Le 11/05/2016 à 08:20, Christian Stoller a écrit : >>> -Ursprüngliche Nachricht- >>> Von: François Laupretre [mailto:franc...@php.net], Gesendet: >>> Dienstag, 10. Mai 2016 15:23 >>> >>> Please read and comment : >>> >>> https://wiki.php.net/rf

Re: AW: [PHP-DEV] [RFC] Allow loading extensions by name

On 11/05/2016 07:20, Christian Stoller wrote: Why not just naming them *.so on all platforms While it can't be relied on, a file suffix does communicate something about the type of the file. Someone might list the downloads for an extension as "foo.so (for Linux/Unix); foo.dll (for Windows)"

Re: AW: [PHP-DEV] [RFC] Allow loading extensions by name

Le 11/05/2016 à 08:20, Christian Stoller a écrit : -Ursprüngliche Nachricht- Von: François Laupretre [mailto:franc...@php.net], Gesendet: Dienstag, 10. Mai 2016 15:23 Please read and comment : https://wiki.php.net/rfc/load-ext-by-name Regards François Why not just naming them *.so

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

You're making confusion between CSRF and Session Hijacking... In any moment I mentioned about hijacking someone else's session, but to still being able to CSRF (Cross Site Request Forgery). Any other remote source would still be able to use your "example". "A is using your own site's contact form

Re: [PHP-DEV] Re: [RFC][VOTE] Nullable Types

On 11/05/16 12:26, Lester Caine wrote: > On 10/05/16 21:26, Levi Morrison wrote: >> It can affect the results. >> >> function foo(?Foo $param) {} >> >> If any code out there is calling foo with null then that code will now >> break if you remove the question mark. > > Cart before Horse comes t

Re: [PHP-DEV] Re: [RFC][VOTE] Nullable Types

On Wed, May 11, 2016 at 12:26 PM, Lester Caine wrote: > On 10/05/16 21:26, Levi Morrison wrote: > > It can affect the results. > > > > function foo(?Foo $param) {} > > > > If any code out there is calling foo with null then that code will now > > break if you remove the question mark. > > Car

Re: [PHP-DEV] Re: [RFC][VOTE] Nullable Types

On 10/05/16 21:26, Levi Morrison wrote: > It can affect the results. > > function foo(?Foo $param) {} > > If any code out there is calling foo with null then that code will now > break if you remove the question mark. Cart before Horse comes to mind ... If the function is going to fail if y

Re: AW: [PHP-DEV] [RFC] Allow loading extensions by name

On 11/05/16 07:20, Christian Stoller wrote: > Apache modules on Windows also have the .so suffix. THAT was what I was forgetting ;) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolv

Re: [PHP-DEV] [RFC] Allow loading extensions by name

On 11/05/16 05:59, Joe Watkins wrote: > The idea that we could one day have a configuration file for both > platforms seems like a pipe dream, so this can't really be considered a > "step closer" to that; It's never going to happen. That is my thought as well. Getting windows installations of PHP

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

On 11/05/2016 05:46, Joe Watkins wrote: I would not vote in favour of a patch that does not include support for AST, that's a completely different feature. Arguably, with the right choice of extension methods, an implementation requiring a single scalar could be extended to support arbitrary

[PHP-DEV] Re: outRe: [PHP-DEV] [RFC] [VOTE] PHP Attributes

Dmitry, > The difference is small, but attributes standardize syntax and provide standard storage with simple API. It's too small. If we go ahead now and introduce constants or strings as the only supported form of attribute, we will never get anything more than that. > I don't know about such h

[PHP-DEV] outRe: [PHP-DEV] [RFC] [VOTE] PHP Attributes

On 05/11/2016 11:42 AM, Joe Watkins wrote: Dmitry, > Except the fact, that doc-comment content don't have to conform to any rules Nor does an attributes value that is just a string, that isn't validated by compiler ... it doesn't *have* to conform to any rules. That's exactly what people

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

On Wed, May 11, 2016 at 10:42 AM, Joe Watkins wrote: > Dmitry, > > > Except the fact, that doc-comment content don't have to conform to any > rules > > Nor does an attributes value that is just a string, that isn't validated by > compiler ... it doesn't *have* to conform to any rules. > > That's

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi Yasuo! 2016-05-11 11:05 GMT+03:00 Yasuo Ohgaki : > Hi Arvids, > > On Wed, May 11, 2016 at 4:33 PM, Arvids Godjuks > wrote: > > i'm -1 on the CSRF in the sessions at all. Even more -1 on having it on > by > > default and having any INI settings that affect how engine processes > data in > > ru

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

Dmitry, > Except the fact, that doc-comment content don't have to conform to any rules Nor does an attributes value that is just a string, that isn't validated by compiler ... it doesn't *have* to conform to any rules. That's exactly what people are voting for though, that seems to be what peopl

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi, Sorry for scattered mails. On Wed, May 11, 2016 at 5:05 PM, Yasuo Ohgaki wrote: >> What I personally would be for, is a CSRF aPI module that comes as default, >> like the Password API one, that gives ability to generate good quality CSRF >> tokens and manage it. Token generation is automati

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi all, On Wed, May 11, 2016 at 5:05 PM, Yasuo Ohgaki wrote: > On Wed, May 11, 2016 at 4:33 PM, Arvids Godjuks > wrote: >> i'm -1 on the CSRF in the sessions at all. Even more -1 on having it on by >> default and having any INI settings that affect how engine processes data in >> runtime. >> Peo

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi Arvids, On Wed, May 11, 2016 at 4:33 PM, Arvids Godjuks wrote: > i'm -1 on the CSRF in the sessions at all. Even more -1 on having it on by > default and having any INI settings that affect how engine processes data in > runtime. > People just don't learn until they shotgun themselves I guess.

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

On 05/11/2016 10:27 AM, Stanislav Malyshev wrote: Hi! Personally, I'm for AST as well, but it's possible to get the same power translating string values of attributes into AST in the hooks. Extending this, it's also possible to get the same power just extracting phpdocs and applying AST to t

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

On May 11, 2016 1:54 PM, "Yasuo Ohgaki" wrote: > > Hi Pierre, > > On Wed, May 11, 2016 at 2:19 PM, Pierre Joye wrote: > > On May 11, 2016 11:46 AM, "Yasuo Ohgaki" wrote: > > > >> Thank you for your comments. I've updated the RFC. You might like this > >> version. > >> > > > > I still think we sh

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi internals, i'm -1 on the CSRF in the sessions at all. Even more -1 on having it on by default and having any INI settings that affect how engine processes data in runtime. People just don't learn until they shotgun themselves I guess. What I personally would be for, is a CSRF aPI module that c

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

Hi! > Personally, I'm for AST as well, but it's possible to get the same power > translating string values of attributes into AST in the hooks. Extending this, it's also possible to get the same power just extracting phpdocs and applying AST to them. -- Stas Malyshev smalys...@gmail.com -- PHP

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

On 05/11/2016 09:57 AM, Joe Watkins wrote: Dmitry, > but it's possible to get the same power translating string values of attributes into AST in the hooks. Aware. Enough of the complexity is already the responsibility of the consumer of the attributes. It's already possible to get strin