On Fri, February 15, 2008 8:54 am, Eric Butera wrote:
> On Thu, Feb 14, 2008 at 3:52 PM, Richard Lynch <[EMAIL PROTECTED]> wrote:
>>
>>
>> On Mon, February 11, 2008 9:59 am, Eric Butera wrote:
>> > On Feb 11, 2008 10:44 AM, Per Jessen <[EMAIL PROTECTED]> wrote:
>> >> Eric Butera wrote:
>> >>
>>
Let us look at XSS now. http://sla.ckers.org/forum/list.php?2 Looks
like there are quite a few of those too. If Google/Yahoo can't stop
this stuff how are us mere mortals supposed to?
In my experience, the bigger the organisation, the more mere mortals.
Also, a small team has a much bet
Eric Butera wrote:
> Let us look at XSS now. http://sla.ckers.org/forum/list.php?2 Looks
> like there are quite a few of those too. If Google/Yahoo can't stop
> this stuff how are us mere mortals supposed to?
In my experience, the bigger the organisation, the more mere mortals.
Also, a small
On Thu, Feb 14, 2008 at 3:52 PM, Richard Lynch <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, February 11, 2008 9:59 am, Eric Butera wrote:
> > On Feb 11, 2008 10:44 AM, Per Jessen <[EMAIL PROTECTED]> wrote:
> >> Eric Butera wrote:
> >>
> >> >> I like it from a coding point of view (it's neat and e
On Mon, February 11, 2008 9:59 am, Eric Butera wrote:
> On Feb 11, 2008 10:44 AM, Per Jessen <[EMAIL PROTECTED]> wrote:
>> Eric Butera wrote:
>>
>> >> I like it from a coding point of view (it's neat and elegant),
>> but I
>> >> don't think it achieves anything else than my initial suggestion
>>
On Sun, February 10, 2008 7:45 am, Jakub wrote:
> is it possible to make something like "gzipped echo"?.
> My idea was:
> $gzOut = gzopen('php://output','w');
> but it fails with an error: Warning: gzopen(php://output) [ href='function.gzopen'>function.gzopen]: could not make seekable -
> php://ou
Stut wrote:
>> Make any PHP-based script available without usage-restriction, and
>> you've got yourself a DDOS potential. Using exec() doesn't change
>> anything.
>
> I would argue that it makes it easier since creating and tearing down
> processes is a pretty expensive operation for most OS's,
Per Jessen wrote:
Stut wrote:
Per Jessen wrote:
Eric Butera wrote:
You should never use exec & friends when there is another way around
the problem. It is a security concern.
Why is it a security concern to execute another bit of code?
I really fail to see any security concern in doing e.
Stut wrote:
> Per Jessen wrote:
>> Eric Butera wrote:
>>
>>> You should never use exec & friends when there is another way around
>>> the problem. It is a security concern.
>>
>> Why is it a security concern to execute another bit of code?
>>
>> I really fail to see any security concern in doi
Eric Butera wrote:
>> Why is it a security concern to execute another bit of code?
>> I really fail to see any security concern in doing e.g.
>>
>> exec('gzip -c /tmp/myinputfile')
>>
>
> In the real world would that be your exact usage? Would the file to
> be compressed be a variable by chance?
Per Jessen wrote:
Eric Butera wrote:
You should never use exec & friends when there is another way around
the problem. It is a security concern.
Why is it a security concern to execute another bit of code?
I really fail to see any security concern in doing e.g.
exec('gzip -c /tmp/myinp
On Feb 11, 2008 11:58 AM, Per Jessen <[EMAIL PROTECTED]> wrote:
> Eric Butera wrote:
>
> > You should never use exec & friends when there is another way around
> > the problem. It is a security concern.
>
> Why is it a security concern to execute another bit of code?
>
> I really fail to see any s
Eric Butera wrote:
> You should never use exec & friends when there is another way around
> the problem. It is a security concern.
Why is it a security concern to execute another bit of code?
I really fail to see any security concern in doing e.g.
exec('gzip -c /tmp/myinputfile')
/Per Jes
On Feb 11, 2008 11:11 AM, Eric Butera <[EMAIL PROTECTED]> wrote:
> On Feb 11, 2008 11:08 AM, Daniel Brown <[EMAIL PROTECTED]> wrote:
> should work fine
>
> if you don't have to. :)
which is my point. ;-P
--
Daniel P. Brown
Senior Unix Geek
--
PHP General Mailing List (http://www.
On Feb 11, 2008 11:08 AM, Daniel Brown <[EMAIL PROTECTED]> wrote:
should work fine
That is enough of a point, right? Why even take the risk if you don't
have to. :)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
On Feb 11, 2008 10:59 AM, Eric Butera <[EMAIL PROTECTED]> wrote:
> You should never use exec & friends when there is another way around
> the problem. It is a security concern.
Only as much as the design of the script allows.
Properly-filtered code (including using escapeshellarg() and
escape
On Feb 11, 2008 10:44 AM, Per Jessen <[EMAIL PROTECTED]> wrote:
> Eric Butera wrote:
>
> >> I like it from a coding point of view (it's neat and elegant), but I
> >> don't think it achieves anything else than my initial suggestion of
> >> using exec(gzip -c).
> >>
> >
> > Except for that little th
Eric Butera wrote:
>> I like it from a coding point of view (it's neat and elegant), but I
>> don't think it achieves anything else than my initial suggestion of
>> using exec(gzip -c).
>>
>
> Except for that little thing where you shouldn't be using execs in
> public facing code.
Why not?
On Feb 10, 2008 2:33 PM, Per Jessen <[EMAIL PROTECTED]> wrote:
> Andrés Robinet wrote:
>
> > How about something like this? (Needs debugging and testing, but...
> > just a hint after all)
> >
> > >
> > ob_start("ob_gzhandler");
> >
> > while ($someString = getTheNextPartOfTheLargeFile()) {
> > ech
Andrés Robinet wrote:
> How about something like this? (Needs debugging and testing, but...
> just a hint after all)
>
>
> ob_start("ob_gzhandler");
>
> while ($someString = getTheNextPartOfTheLargeFile()) {
> echo $someString;
> ob_flush();
> }
>
> ?>
I like it from a coding point of view
> -Original Message-
> From: Jakub [mailto:[EMAIL PROTECTED]
> Sent: Sunday, February 10, 2008 1:36 PM
> To: php-general@lists.php.net
> Subject: Re: [PHP] Gzipped output
>
> That would do the trick if it was allowed at the server but it
> isn't :( And i
That would do the trick if it was allowed at the server but it
isn't :( And it's not my server and I can't change its settings.
Jakub Čermák
[EMAIL PROTECTED]
ICQ 159971304
Per Jessen napsal(a):
Jakub wrote:
Yes, I thought about this, but this has a big disadvantage - the
client mu
Jakub wrote:
> Yes, I thought about this, but this has a big disadvantage - the
> client must wait for the file to be fully processed and compressed and
> then he can start downloading. I'd like to let the client start
> downloading the compressed parts while the further parts are still
> being pr
Yes, I thought about this, but this has a big disadvantage - the client
must wait for the file to be fully processed and compressed and then he
can start downloading. I'd like to let the client start downloading the
compressed parts while the further parts are still being processed and
compress
Jakub wrote:
> That script generates a large text file to download, so I thought I
> can gzip it somehow to make the downloads faster. The buffered way (to
> load all the output to some $buffer and then echo
> gzencode($buffer,6);) consumes too much memory.
You could write it to a local file, the
Hello,
is it possible to make something like "gzipped echo"?.
My idea was:
$gzOut = gzopen('php://output','w');
but it fails with an error: Warning: gzopen(php://output) [href='function.gzopen'>function.gzopen]: could not make seekable -
php://output
That script generates a large text file to
26 matches
Mail list logo
