Hi Mike,
On Wed, Sep 25, 2013 at 2:16 PM, Mike Willbanks wrote:
> Each and every type of prevention measure has consequences and not only
> that but MAJOR consequences. If you are detecting IP changes you rule out
> most if not all major proxy networks that exist. While not first of mind;
> wh
On Tue, Sep 24, 2013 at 8:52 PM, Yasuo Ohgaki wrote:
> Hi,
> On Tue, Sep 24, 2013 at 12:46 PM, Ronald Chmara wrote:
>
>> When you have a group of front-end termination points in a pool, proxying
>> requests off to hundreds of machines for thousands of applications, tying a
>> session to any IP i
On Mon, Sep 23, 2013 at 7:29 PM, Yasuo Ohgaki wrote:
> Hi all,
>
> There isn't any good counter measure session hijack.
> However, we can regenerate session ID if IP address has changed.
> Hijacked users might notice that they have been logged out if session
> ID is regenerated by attackers. There
Hi Alexey,
On Tue, Sep 24, 2013 at 11:22 PM, Alexey Zakhlestin wrote:
> strangely, this RFC is not shown in "In voting phase" section here:
> https://wiki.php.net/rfc
> is that done manually?
>
I should have done this.
Thank you for point it out.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Laruence,
On Tue, Sep 24, 2013 at 11:42 AM, Laruence wrote:
> I don't think this is language concerning issue.
>
> it could be done in user script..
>
Session should be managed as secure as possible.
We can promote better session management in document.
It's an option.
Regards,
--
Yasuo Oh
Hi,
On Tue, Sep 24, 2013 at 12:46 PM, Ronald Chmara wrote:
> When you have a group of front-end termination points in a pool, proxying
> requests off to hundreds of machines for thousands of applications, tying a
> session to any IP is a headache. IMO, sessions are supposed to be tied to
> users
On 09/24/2013 09:50 PM, Robert Stoll wrote:
-Original Message-
From: Joe Watkins [mailto:krak...@php.net]
Sent: Tuesday, September 24, 2013 10:08 PM
To: internals@lists.php.net; Kristopher
Subject: Re: [PHP-DEV] RFC: Anonymous Classes
On 09/24/2013 01:30 PM, Kristopher wrote:
On Tue,
> -Original Message-
> From: Joe Watkins [mailto:krak...@php.net]
> Sent: Tuesday, September 24, 2013 10:08 PM
> To: internals@lists.php.net; Kristopher
> Subject: Re: [PHP-DEV] RFC: Anonymous Classes
>
> On 09/24/2013 01:30 PM, Kristopher wrote:
> > On Tue, Sep 24, 2013 at 8:25 AM, Teren
On 09/24/2013 01:30 PM, Kristopher wrote:
On Tue, Sep 24, 2013 at 8:25 AM, Terence Copestake <
terence.copest...@gmail.com> wrote:
Playing devil's advocate here, could this feature make the language more
expressive?
Take for example an API where you'd typically wrap a method call in
try/catch
On 24 September 2013 14:51, Nicolas Grekas wrote:
> What about allowing a "use" statement on these methods?
>
> $someFoo = "bar";
>
> $object = new class{
> function method() use ($someFoo) { return $someFoo;}
> }
>
> $object->method(); // "bar";
>
I think the idea of anonymous classes is ve
> I am not the tone police, but I don't think such comments are helpful.
Hey, sorry all :)
Not trying to suggest anyone is incapable of writing working code (I know I
am from time to time). I was simply ticking off my objections to the
arguments presented. I'm in favor of "kinder, gentler" interna
On 24/09/2013 17:12, Daniel Lowrey wrote:
> An inability on your part to write working code doesn't equate to "PHP
> should implement this for me"
I am not the tone police, but I don't think such comments are helpful.
Let me be clear: I'm not suggesting we should ignore useful functionality
bec
Let me be clear: I'm not suggesting we should ignore useful functionality
because of poor design decisions made in the past but I am saying that we
should avoid compounding those mistakes by building on top of them. Would a
$_PUT superglobal be helpful? Sure. But is it a good solution to underlying
Thanks Daniel. My thoughts on your response:
> Where does it stop? This is the problem I see with all the requests to
> support for PUT similarly to POST.
Right here with PUT. Providing a RESTful interface is hugely common and $_PUT
is the only one missing to complete REST. PUT is the glaringly
On 24 September 2013 16:59, Daniel Lowrey wrote:
> The bigger issue here is that the superglobals are a leaky abstraction. Any
> HTTP request method is allowed to have an entity body, so should we also
> create $_PATCH and $_PUT and $_ZANZIBAR to handle less-frequently used
> request methods? Whe
> In short, in order to provide a proper REST service that supports
multipart
> form data, we need someway to parse data sent via PUT (data is available
> via php://input, but it needs to be parsed).
Multipart entity parsing is fairly straightforward. You could easily write
a parser in userland to
On 24.09.2013, at 5:41, Yasuo Ohgaki wrote:
> Hi all,
>
> It's been a whole from the discussion.
> I setup vote for RFC: Change crypt() behavior w/o salt.
>
> https://wiki.php.net/rfc/crypt_function_salt
>
> If I missed something, please let me know.
strangely, this RFC is not shown in "In v
I think BC (like requiring salt) are unnecessary given that password_*
functions already exist with salt enabled by default.
But an E_NOTICE isn't a bad idea.
--
William Bartlett
College of Engineering | Cornell University '14
240-432-5189
On Mon, Sep 23, 2013 at 10:47 PM, Pierre Joye wrote:
What about allowing a "use" statement on these methods?
$someFoo = "bar";
$object = new class{
function method() use ($someFoo) { return $someFoo;}
}
$object->method(); // "bar";
On Tue, Sep 24, 2013 at 8:25 AM, Terence Copestake <
terence.copest...@gmail.com> wrote:
> Playing devil's advocate here, could this feature make the language more
> expressive?
>
> Take for example an API where you'd typically wrap a method call in
> try/catch blocks to handle the various "outcom
Playing devil's advocate here, could this feature make the language more
expressive?
Take for example an API where you'd typically wrap a method call in
try/catch blocks to handle the various "outcomes" e.g. a user login, you'd
maybe have a UserDisabled exception, a UserAlreadyLoggedIn exception,
2013/9/24 David Soria Parra
> Lazare Inepologlou schrieb:
> > I use anonymous classes very frequently in Java and in C#, and I would
> say
> > that they are quite useful. However the examples given in the RFC are
> > really bad ones. Why on earth would you need a constructor for an
> anonymous
>
Lazare Inepologlou schrieb:
> I use anonymous classes very frequently in Java and in C#, and I would say
> that they are quite useful. However the examples given in the RFC are
> really bad ones. Why on earth would you need a constructor for an anonymous
> class? Anonymous classes are used to impl
2013/6/4 Ivan Enderlin @ Hoa
>
> On 04/06/13 12:08, Pierre Joye wrote:
>
>> On Tue, Jun 4, 2013 at 10:41 AM, Ivan Enderlin @ Hoa
>> wrote:
>>
>>> Hey :-),
>>>
>>>
>>> On 02/06/13 08:52, Johannes Schlüter wrote:
>>>
It would be a *gigantic* patch, but the userland effects should be
> min
24 matches
Mail list logo
