Hello all,
the CfP for ApacheCon Europe 2005 is open:
http://www.apachecon.com/2005/EU/index.html/e=MjAwNS9FVQ
submission deadline: 22h30 EST Friday, 04 March 2005
ApacheCon Europe 2005 will be held from July 18th to 22nd in
Stuttgart/Germany.
/Georg
--
PHP Internals - PHP Runtime Developme
David Zülke wrote:
Guys, I'm sure I'll annoy the heck out of some on this list, but there's
still the question whether PHP should prevent any case of dumbness on the
developer side. Whatever we do, some developers out there will be way more
idiotic than we can ever imagine. And if any company chose
On Feb 6, 2005, at 6:51 PM, Edin Kadribasic wrote:
On Sunday, Feb 6, 2005, at 23:07 Europe/Copenhagen, George
Schlossnagle wrote:
I disagree. The fact that XSS attacks remain one of the largest
issues plaguing large so-called enterprise sites points to data
validation being a hard thing to rem
On Fri, Feb 04, 2005 at 01:00:23AM -0800, Rasmus Lerdorf wrote:
> And everyone here understands
> that &{ needs to be stripped or entitied as well, right?
"&{"? Can you elaborate what that is and why it's a problem,
please?
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N
On Sunday, Feb 6, 2005, at 23:07 Europe/Copenhagen, George Schlossnagle
wrote:
I disagree. The fact that XSS attacks remain one of the largest
issues plaguing large so-called enterprise sites points to data
validation being a hard thing to remember to always do, and to do
'right'.
So how do y
David Zülke wrote:
Guys, I'm sure I'll annoy the heck out of some on this list, but there's
still the question whether PHP should prevent any case of dumbness on the
developer side. Whatever we do, some developers out there will be way more
idiotic than we can ever imagine. And if any company chose
On Feb 6, 2005, at 2:14 PM, Christian Schneider wrote:
Benj Carson wrote:
My opinion may not carry any weight here, as I'm just a user of PHP,
but this discussion has given me a few ideas. As Ron and Val (and
others) have pointed out, there's no way for PHP to know how an
*input* value is going
On Feb 6, 2005, at 5:02 PM, David Zülke wrote:
Guys, I'm sure I'll annoy the heck out of some on this list, but
there's
still the question whether PHP should prevent any case of dumbness on
the
developer side. Whatever we do, some developers out there will be way
more
idiotic than we can ever im
Guys, I'm sure I'll annoy the heck out of some on this list, but there's
still the question whether PHP should prevent any case of dumbness on the
developer side. Whatever we do, some developers out there will be way more
idiotic than we can ever imagine. And if any company choses that 16-year-old
I'm sorry to keep dragging this out..
- A default filter might help, it definitely _will_ cause problems and
lots of programs will need fixing so it's a very double-edged sword.
Making it easy to disable it would result in little more security as
people running into (even minor, i.e. easily fixa
On Thu, 2005-02-03 at 19:58, Terje Slettebø wrote:
> > From: "Stig S. Bakken" <[EMAIL PROTECTED]>
> >
> > On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
> >
> > > Andi Gutmans wrote:
> > > > Comments/Flames/Praises to this list :)
> > >
> > > Just curious: Have you considered adding the operator ov
On February 6, 2005 12:27 pm, Sean Coates wrote:
>
> This would break pretty much every application ever written.
> Consider:
> echo " href="http://www.yahoo.com/";>Yahoo!"; ?>
>
Yeah, I realise the output filter would have to be intelligent. It couldn't
blindly filter every echoed string.
> Y
Benj Carson wrote:
My opinion may not carry any weight here, as I'm just a user of PHP, but
this discussion has given me a few ideas.
Neither does mine.. but...
As Ron and Val (and others) have
pointed out, there's no way for PHP to know how an *input* value is going
to be used. Would it perha
If you think there are a lot of people who want this feature as you propose
it, then I won't oppose such implementation. I guess the only thing I
wouldn't be able to live with would be a default setting after a fresh PHP
install where there is a non-raw filter in place. Beyond that, if there are
a
Benj Carson wrote:
My opinion may not carry any weight here, as I'm just a user of PHP, but
this discussion has given me a few ideas. As Ron and Val (and others) have
pointed out, there's no way for PHP to know how an *input* value is going
to be used. Would it perhaps be better to filter *out
Ron Korving wrote:
It's a very weird idea to me to filter out HTML on input, because the only
place where HTML tags could be abused is in the output. So that's where
filtering should take place, imho. Maybe it's hard to figure out a way to do
this the easiest way, but failing to come up with an out
My opinion may not carry any weight here, as I'm just a user of PHP, but
this discussion has given me a few ideas. As Ron and Val (and others) have
pointed out, there's no way for PHP to know how an *input* value is going
to be used. Would it perhaps be better to filter *output* values?
The s
My problem with this approach is that data is reformatted before being used,
while my philosophy has always been to always store data in it's raw
original version and format when outputting (which would always be
consistent). So in this case, if someone (say in the forum of a website)
starts using
Well, you already have the problem. The filter hook has been in PHP5
for 2 years now and people are using it already. And yes, your code is
likely not to work on those servers if you are expecting raw html tags
to get through.
There are plenty of people who have to operate under a mandated se
Well there you go. A default filter. So I don't know what you mean with "For
the 18th time, nobody is talking about enabling it by default.", because an
administrator might. And I as a developer have no clue. Personally, I don't
see why a webserver admin should need to secure his server through mea
From a developer's perspective I can see your point. But if I am going
to run your application on my server, I want a way to make sure no XSS,
for example, can get through no matter how badly you may have written
the application. That is, the control of my server's security policy
has to be u
I'm not a developer of php, but developing in php, i can say that it'd
be nice to be able to filter *any* data, *if I want to*, not just $_GET,
$_POST etc.. I think it is a good idea to have a easy to use filter api,
but please don't make it an ini setting, so i have to call a function to
get t
For the 18th time, nobody is talking about enabling it by default.
-Rasmus
Ron Korving wrote:
Exactly right!
Who knows what I'm gonna do with my input?
- html output?
- text output?
- pdf output?
- stdout or stderr output?
- binary output?
- output?
- file i/o?
- mysql query?
- mssql query?
- db2
Exactly right!
Who knows what I'm gonna do with my input?
- html output?
- text output?
- pdf output?
- stdout or stderr output?
- binary output?
- output?
- file i/o?
- mysql query?
- mssql query?
- db2 query?
- encryption?
It is a BIG mistake to just assume any of these. And how about the value
TS>>An advantage of function objects in C++ is that they can be used where
TS>>functions are expected. Nevertheless, there are some features that can be
Depending on what you mean of "expected". You can't use such object as a
function pointer, for example. Yes, you can write Object() and make tha
TS>>No, you don't have to go that far. For starters, one could allow function
TS>>(and possibly operator) overloading, based on type hints. The following is
TS>>legal PHP5:
That will already open the can of worms. And make each function call to go
through all the hoops of signature matching.
TS
26 matches
Mail list logo
