Xuefer Tinys wrote:
more choices:
foo_bar(string $key or array $keys, int or string $how)
bar can be one of get,post,request,env,server
foo may be filter? ifilter? (i for input)
may foo be empty? _get _post etc..
$how is default to FILTER_RAW so we have _get("abc") and _GET("abc")
for raw data same
On Feb 1, 2005, at 9:27 PM, Sean Coates wrote:
Ryan King wrote:
Then the constant really just becomes a callback and I can add
anything in that I want.
IMO, this is what array_walk(...) is for.
Especially if pre- and post-filter $_SUPERGLOBALs are made available.
I'm not exactly sure what you're s
more choices:
foo_bar(string $key or array $keys, int or string $how)
bar can be one of get,post,request,env,server
foo may be filter? ifilter? (i for input)
may foo be empty? _get _post etc..
$how is default to FILTER_RAW so we have _get("abc") and _GET("abc")
for raw data same as $_GET['abc'] be
Ryan King wrote:
Then the constant really just becomes a callback and I can add anything
in that I want.
IMO, this is what array_walk(...) is for.
Especially if pre- and post-filter $_SUPERGLOBALs are made available.
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Greg Beaver wrote:
Hi,
I would prefer a more active name like "sanitize" over "filter"
sanitize_input() or clean_input()
Greg
I had a go a while ago at doing something like an input filter:
http://www.trickie.org/cleaner/
It is crap, and Rasmus told me at the time about the input_filter hook,
but
Hi,
I would prefer a more active name like "sanitize" over "filter"
sanitize_input() or clean_input()
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Feb 1, 2005, at 8:10 PM, Sean Coates wrote:
Rasmus Lerdorf wrote:
As someone suggested, if the filter function could do $GET =
filt(GET,'*',FILTER_TAGS) or something to that effect then an
individual script could in one shot filter all GET data even if the
default ini filter wasn't in place.
On Feb 1, 2005, at 4:55 PM, Rasmus Lerdorf wrote:
Nick Loeve wrote:
Rasmus Lerdorf wrote:
I don't actually see it as a per-script thing. Obviously the ini
would be per-dir Apache configurable, but I see this as being
something set across the board on a dedicated server that defines
the security
On Feb 1, 2005, at 4:23 PM, Nick Loeve wrote:
Rasmus Lerdorf wrote:
I don't actually see it as a per-script thing. Obviously the ini
would be per-dir Apache configurable, but I see this as being
something set across the board on a dedicated server that defines
the security policy of that serve
Ilia Alshanetsky wrote:
Given that we'd always need to store the raw request data in memory, can
we provide some mechanism of accessing it that does not require a
function call? If working with integer or floating point based data it
is much faster and simpler to just do (int)/(float) cast rathe
Rasmus Lerdorf wrote:
As someone suggested, if
the filter function could do $GET = filt(GET,'*',FILTER_TAGS) or
something to that effect then an individual script could in one shot
filter all GET data even if the default ini filter wasn't in place.
Might I suggest:
foo_filter($type, $keys, FILTE
Given that we'd always need to store the raw request data in memory, can
we provide some mechanism of accessing it that does not require a
function call? If working with integer or floating point based data it
is much faster and simpler to just do (int)/(float) cast rather then
executing functi
Jay,
I've noticed that you're still using the ini parser in this new code,
would it not be easier and allow for greater code re-use to use the CSV
database and the underlying fgetcsv code?
Ilia
Jay Smith wrote:
Andi Gutmans wrote:
Hey,
I just heard from Wez that PDO is in very advanced stages n
On Wed, 02 Feb 2005 02:00:12 +0100, in php.internals
[EMAIL PROTECTED] (Christian Schneider) wrote:
>Stupid question: Is it safe to pass a variable containing UTF8 to a
>ASCII function like exec()? I think to remember that the encoding makes
>sure that the encoding ensures that none of the ASCII
Jay Smith wrote:
The patch is at http://bugs.tutorbuddy.com/download/browscap.patch.tar.gz .
It's not exactly new VM exciting or PDO exciting (which, if you're reading
this Wez, looks quite nice), but browser detection is something I think PHP
should do well. It is primarily a web scripting languag
Hi,
Isn't that something you can use mod_security for? I don't know of the
availability of that module on a standard host, but on a dedicated
server you could install it.
mod_security (ehmm mod_illusion) is unable to protect PHP applications
because it has more holes than swiss cheese.
Stefan
-
Any volunteers to review and commit this?
At 07:51 PM 2/1/2005 -0500, Jay Smith wrote:
Seems every time I get ready to finally commit the new browscap stuff that
I've been sitting on for 5.1 since forever, something always comes up and
it gets on the backburner.
Since I've been out of the loop for
Yep agreed. We should have something standard in PHP.
And never forget, PHP is cross-web server:)
Andi
At 04:55 PM 2/1/2005 -0800, Rasmus Lerdorf wrote:
Nick Loeve wrote:
Rasmus Lerdorf wrote:
I don't actually see it as a per-script thing. Obviously the ini would
be per-dir Apache configurable,
Rasmus Lerdorf wrote:
Nick Loeve wrote:
Rasmus Lerdorf wrote:
I don't actually see it as a per-script thing. Obviously the ini
would be per-dir Apache configurable, but I see this as being
something set across the board on a dedicated server that defines
the security policy of that server.
I
At 01:31 AM 2/2/2005 +0100, Jochem Maas wrote:
$raw = pfilter(COOKIE,'cook', FILTER_RAW);
Sounds like a good idea (even though the name pfilter reminds me too much
of packet filter :-)). A catch-all could be handy too, e.g.
pfilter(REQUEST, DEFAULT, FILTER_TAGS);
maybe rfilter() - as in 'request
Rasmus Lerdorf wrote:
Well, if you set a global filter you set an extremely strict one. Like
only letting a-z through or the equivalent in your charset, for example.
Want a number? Tough, call the filter function to get at it. The idea
Ah, ok, you can still get the original data but you have
Nick Loeve wrote:
Rasmus Lerdorf wrote:
I don't actually see it as a per-script thing. Obviously the ini
would be per-dir Apache configurable, but I see this as being
something set across the board on a dedicated server that defines the
security policy of that server.
Isn't that something you
On Wed, Feb 02, 2005 at 11:23:23AM +1100, Nick Loeve wrote:
>
> >Rasmus Lerdorf wrote:
> >
> >>I don't actually see it as a per-script thing. Obviously the ini
> >>would be per-dir Apache configurable, but I see this as being
> >>something set across the board on a dedicated server that defines
Andi Gutmans wrote:
> Hey,
>
> I just heard from Wez that PDO is in very advanced stages now (ready for
> beta). I would like to start the PHP 5.1 release process. Due to the lack
> of testing both the new engine VM and PDO have received I would like to
> start with a beta process so that we get
Shane Caraveo wrote:
I thought my suggestion the other week was pretty goodsafe_filter :-)
Hey, no snarky comments from the peanut gallery please! ;) No PHP
function or feature will ever be called safe* again.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, v
Christian Schneider wrote:
Rasmus Lerdorf wrote:
I don't actually see it as a per-script thing. Obviously the ini
would be per-dir Apache configurable, but I see this as being
something set across the board on a dedicated server that defines the
security policy of that server. Shared servers a
Rasmus Lerdorf wrote:
I don't actually see it as a per-script thing. Obviously the ini
would be per-dir Apache configurable, but I see this as being
something set across the board on a dedicated server that defines the
security policy of that server.
Isn't that something you can use mod_secur
The only problem is that this is an extension so it would probably have a
few functions:
filter_input()
filter_validate()
filter_foobar()
Maybe we were only discussing one method but it's likely for others to follow.
I thinks safe_* is a bit general but then again, although naming is the
hardest
$raw = pfilter(COOKIE,'cook', FILTER_RAW);
Sounds like a good idea (even though the name pfilter reminds me too
much of packet filter :-)). A catch-all could be handy too, e.g.
pfilter(REQUEST, DEFAULT, FILTER_TAGS);
maybe rfilter() - as in 'request filter'?
--
PHP Internals - PHP Runtime Devel
Rasmus Lerdorf wrote:
I don't actually see it as a per-script thing. Obviously the ini would
be per-dir Apache configurable, but I see this as being something set
across the board on a dedicated server that defines the security policy
of that server. Shared servers are most likely not going to
Rasmus Lerdorf wrote:
Andi Gutmans wrote:
I definitely like the idea and thing it's important.
I think as far as the filter functions are concerned this is a good
way to go (although I'd change the function name but that's no biggy,
filter_input?). I very much see how filter_input(POST, "email",
Andi Gutmans wrote:
I definitely like the idea and thing it's important.
I think as far as the filter functions are concerned this is a good way
to go (although I'd change the function name but that's no biggy,
filter_input?). I very much see how filter_input(POST, "email",
FILTER_EMAIL) is easi
I definitely like the idea and thing it's important.
I think as far as the filter functions are concerned this is a good way to
go (although I'd change the function name but that's no biggy,
filter_input?). I very much see how filter_input(POST, "email",
FILTER_EMAIL) is easier as opposed to fin
Christian Schneider wrote:
Rasmus Lerdorf wrote:
But the general idea is to provide an optional filter that people can
enable in their ini file. This will strip out any XSS, quotes, braces,
I assume this will include PHP functions to do the filtering as well?
(Forgive me if we already have thi
Rasmus Lerdorf wrote:
But the general idea is to provide an optional filter that people can
enable in their ini file. This will strip out any XSS, quotes, braces,
I assume this will include PHP functions to do the filtering as well?
(Forgive me if we already have this now, I haven't looked at 5
On 1.2.2005 21:20 Uhr, Stephan Schmidt wrote:
Hi,
Andi Gutmans schrieb:
I believe both PDO and Date should be included in the default distro.
I'd like to see xmlreader be bundled as well. It's fast, easy to use and
still very powerful.
Very big +1 from me on that as well. XMLReader needs to be bu
Andi,
good enough for me.
"Andi Gutmans" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Yeah, that's what I meant. I.e. add them to not screw up the API
> afterwards but leave it up to the extensions to implement the callbacks
> when the authors have time pre or post 5.1.
>
Yeah, that's what I meant. I.e. add them to not screw up the API afterwards
but leave it up to the extensions to implement the callbacks when the
authors have time pre or post 5.1.
Andi
At 05:37 PM 2/1/2005 -0500, George Schlossnagle wrote:
On Feb 1, 2005, at 5:36 PM, Andi Gutmans wrote:
When yo
Andi Gutmans wrote:
As time is very short, I suggest to discuss exactly what we want and
then to see if it's possible in a 5.1 time frame.
Can you give a short overview of what you had in mind and how the
end-user would be using the functionality?
Well, I am not starting from scratch here. I hav
On Feb 1, 2005, at 5:36 PM, Andi Gutmans wrote:
When you mean support, basically it's just adding
serialize/unserialize callbacks right? Doesn't mean all extensions
need to implement them?
Those can be 'bugfixes' in point releases?
George
--
PHP Internals - PHP Runtime Development Mailing List
T
When you mean support, basically it's just adding serialize/unserialize
callbacks right? Doesn't mean all extensions need to implement them?
Andi
At 05:21 PM 2/1/2005 -0500, l0t3k wrote:
Andi,
i guess this means that proper serialization support for internal
classes will have to wait till 5.2
As time is very short, I suggest to discuss exactly what we want and then
to see if it's possible in a 5.1 time frame.
Can you give a short overview of what you had in mind and how the end-user
would be using the functionality?
Thanks,
Andi
At 02:10 PM 2/1/2005 -0800, Rasmus Lerdorf wrote:
Andi
Andi,
i guess this means that proper serialization support for internal
classes will have to wait till 5.2 ?
l0t3k
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Andi Gutmans wrote:
I believe both PDO and Date should be included in the default distro. As
far as PDO is concerned I think for each DB if it is selected at
configure time, the relevant PDO extension should also be enabled. So
doing --with-oci8 should enable both ext/oci8 and ext/pdo_oci. This
Don't see a problem with that if it's release quality.
Andi
At 09:20 PM 2/1/2005 +0100, Stephan Schmidt wrote:
Hi,
Andi Gutmans schrieb:
I believe both PDO and Date should be included in the default distro.
I'd like to see xmlreader be bundled as well. It's fast, easy to use and
still very powerfu
On Feb 1, 2005, at 3:20 PM, Stephan Schmidt wrote:
Hi,
Andi Gutmans schrieb:
I believe both PDO and Date should be included in the default distro.
I'd like to see xmlreader be bundled as well. It's fast, easy to use
and still very powerful.
+1
George
--
PHP Internals - PHP Runtime Development Mail
Hi,
Andi Gutmans schrieb:
I believe both PDO and Date should be included in the default distro.
I'd like to see xmlreader be bundled as well. It's fast, easy to use and
still very powerful.
Stephan
--
http://www.php-tools.net
http://www.schst.net
http://pear.php.net
--
PHP Internals - PHP Runtime
Andi Gutmans wrote:
Comments/Flames/Praises to this list :)
All praise PHP 5.1. All praise PDO.
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hey,
I just heard from Wez that PDO is in very advanced stages now (ready for beta).
I would like to start the PHP 5.1 release process. Due to the lack of
testing both the new engine VM and PDO have received I would like to start
with a beta process so that we get feedback.
I know there are stil
How can I write a module for PHP? Any ABC information?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
>> how much does this patch slow execution down? it's one more hash lookup.
>> affect speed of $var or $$var? or both?
>>
> AFAICS, it should make every local-variable (non-global) lookup slower.
> Since it needs to do a lookup in the globals table first.
>
Slows the global ones too, though that c
AFAICS, it should make every local-variable (non-global) lookup slower.
Since it needs to do a lookup in the globals table first.
Xuefer Tinys wrote:
$_GET is solved at compile time, which is good, but this make other
variables bad at execution time?
how much does this patch slow execution down?
52 matches
Mail list logo
