That's actually a very good article and while I don't agree with some
of it (most notably #6, the I love SQL.. I find a good ORM layer to be
a life saver should you ever need to make database structure changes
without having all your apps collapse all over themselves), I
certainly agree with the ma
On Sun, 2007-09-23 at 18:02 +0100, Colin Guthrie wrote:
> Thought ppl here may be interested in this:
> http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html
>
> Originally linked from /.:
> http://developers.slashdot.org/article.pl?sid=07/09/23/1249235
It's funny, eve
Thought ppl here may be interested in this:
http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html
Originally linked from /.:
http://developers.slashdot.org/article.pl?sid=07/09/23/1249235
Col
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: ht
At 9:27 PM +0200 6/20/07, Tijnema wrote:
On 6/20/07, tedd <[EMAIL PROTECTED]> wrote:
If you are worried about evil code being in the image, you could
always resample the image (larger or smaller). Not that I have
personal experience, but I would think that any piece of code that is
resampled is
On Wed, 2007-06-20 at 15:12 -0400, Daniel Brown wrote:
> On 6/20/07, tedd <[EMAIL PROTECTED]> wrote:
> > At 12:53 PM -0400 6/20/07, Daniel Brown wrote:
> > >
> > >No, not the upload and execution, per se, but rather using images
> > >to contain processable PHP code.
> > >
> > >--
> > >Daniel P.
On 6/20/07, tedd <[EMAIL PROTECTED]> wrote:
At 2:32 PM -0400 6/20/07, Guillaume Theoret wrote:
>Thanks for the link.
>
>I got worried for a second that my code could be exploited so I did a
>quick check to make sure that mime-types were correct. (I check the
>mime type to make sure it's an image,
At 2:32 PM -0400 6/20/07, Guillaume Theoret wrote:
Thanks for the link.
I got worried for a second that my code could be exploited so I did a
quick check to make sure that mime-types were correct. (I check the
mime type to make sure it's an image, not the file extension.) I
renamed a .jpg file .
On 6/20/07, tedd <[EMAIL PROTECTED]> wrote:
At 12:53 PM -0400 6/20/07, Daniel Brown wrote:
>
>No, not the upload and execution, per se, but rather using images
>to contain processable PHP code.
>
>--
>Daniel P. Brown
Daniel:
Wow! Now that's something I would like to see -- you do have a de
At 12:53 PM -0400 6/20/07, Daniel Brown wrote:
No, not the upload and execution, per se, but rather using images
to contain processable PHP code.
--
Daniel P. Brown
Daniel:
Wow! Now that's something I would like to see -- you do have a demo?
As far as "legitimate reasons", how about ima
Thanks for the link.
I got worried for a second that my code could be exploited so I did a
quick check to make sure that mime-types were correct. (I check the
mime type to make sure it's an image, not the file extension.) I
renamed a .jpg file .jpg.php and uploaded it and got application/x-php
as
On 6/20/07, Jochem Maas <[EMAIL PROTECTED]> wrote:
Daniel Brown wrote:
> On 6/20/07, Tijnema <[EMAIL PROTECTED]> wrote:
>> Hi all,
>>
>> Just received a mail from phpclasses, which pointed to this very
>> interesting article[1]. Seems good to know for starters ;)
>> The experts around here probab
Daniel Brown wrote:
> On 6/20/07, Tijnema <[EMAIL PROTECTED]> wrote:
>> Hi all,
>>
>> Just received a mail from phpclasses, which pointed to this very
>> interesting article[1]. Seems good to know for starters ;)
>> The experts around here probably already know this way of exploits.
>>
>> Tijnema
>
On 6/20/07, Tijnema <[EMAIL PROTECTED]> wrote:
Hi all,
Just received a mail from phpclasses, which pointed to this very
interesting article[1]. Seems good to know for starters ;)
The experts around here probably already know this way of exploits.
Tijnema
[1]
http://www.phpclasses.org/blog/pos
Hi all,
Just received a mail from phpclasses, which pointed to this very
interesting article[1]. Seems good to know for starters ;)
The experts around here probably already know this way of exploits.
Tijnema
[1]
http://www.phpclasses.org/blog/post/67-PHP-security-exploit-with-GIF-images.html
On Wed, 2006-01-18 at 16:20, Mark wrote:
> Robert Cummings wrote:
> >
> > The implementation is slightly more difficult than what I've just
> > described, but simple enough :)
>
> It's truly ugly, don't you think?
Actually I find it quite elegant, but maybe that's just me :)
Cheers,
Rob.
--
.-
On Wed, January 18, 2006 2:36 pm, Mark wrote:
> Here's a point of debate, should this sort of behavior be allowed?
Of course it should be allowed!
It's a standard computer science technique!
There are entire branches of mathematics / science devoted to
recursive graph theory.
Whole *BOOKS* writ
Robert Cummings wrote:
> On Wed, 2006-01-18 at 15:36, Mark wrote:
>>
>> [-- CLIPPED --]
>>
>> Here's a point of debate, should this sort of behavior be allowed? If it
>> is allowable, how does one support it in any sort of serialized
>> methodology? I have a few ideas but none very pretty. I'm pre
On Wed, 2006-01-18 at 15:44, Robert Cummings wrote:
>
> Yes it should be allowed,
Actualy was just thinking about how I didn't allow this in JavaScript...
you might want to make it an option as a second parameter to recurse. I
know in JavaScript any DOM element references the entire DOM tree and
y
On Wed, 2006-01-18 at 15:36, Mark wrote:
>
> [-- CLIPPED --]
>
> Here's a point of debate, should this sort of behavior be allowed? If it is
> allowable, how does one support it in any sort of serialized methodology? I
> have a few ideas but none very pretty. I'm pretty sure it causes problems
> in
I am working on an XML serializer module for PHP. It will allow session
information to be stored as XML in the database. While this sounds like
self promotion, and it probably is a bit, it is needed to make sense of why
I am doing this. Anyway, the XML stream is so that I can use PHP session
data
Dotan Cohen wrote:
On 8/5/05, Jochem Maas <[EMAIL PROTECTED]> wrote:
he runs php5, you run php4 - is the following set on his server perchance?:
echo $_SERVER['HTTP_REFERER'];
//or
echo getenv("HTTP_REFERER");
note that $HTTP_REFERER is depreciated in php5.
also the freeBSD box may have a fir
On 8/5/05, Jochem Maas <[EMAIL PROTECTED]> wrote:
> he runs php5, you run php4 - is the following set on his server perchance?:
>
> echo $_SERVER['HTTP_REFERER'];
> //or
> echo getenv("HTTP_REFERER");
>
> note that $HTTP_REFERER is depreciated in php5.
> also the freeBSD box may have a firewall t
Dotan Cohen wrote:
I creating a out.php file that will record clicks, and the redirect
the user to the site that he wanted. I am currently using
header("Location: $url"); which works as expected. The only problem
is, that the browser does not send $HTTP_REFERER info to the recieving
site.
Howeve
I creating a out.php file that will record clicks, and the redirect
the user to the site that he wanted. I am currently using
header("Location: $url"); which works as expected. The only problem
is, that the browser does not send $HTTP_REFERER info to the recieving
site.
However, that particular si
Jay Blanchard wrote:
Let's say I have a form and the action is thus;
\n";
Note the 'bid' attribute. Now, I have a case statement in which stuff
takes place since the form has called it because of the 'bid' attribute.
Before I break from the case I do this;
unset($_GET['bid']);
SIDEBAR: You should a
Jay Blanchard wrote:
Let's say I have a form and the action is thus;
\n";
Note the 'bid' attribute. Now, I have a case statement in which stuff
takes place since the form has called it because of the 'bid' attribute.
Before I break from the case I do this;
unset($_GET['bid']);
SIDEBAR: You should a
Jay Blanchard wrote:
[snip]
Am I missing something here? It's obvious that the 'bid' parameter will
appear in the query string... That's how the form posts it.
Yes, you can unset it if you like, but the form will still add it to the
URL that it posts to, unless you change the "action" attribute of
[snip]
Am I missing something here? It's obvious that the 'bid' parameter will
appear in the query string... That's how the form posts it.
Yes, you can unset it if you like, but the form will still add it to the
URL that it posts to, unless you change the "action" attribute of the
form tag.
A
But, Jay:
Am I missing something here? It's obvious that the 'bid' parameter will
appear in the query string... That's how the form posts it.
Yes, you can unset it if you like, but the form will still add it to the
URL that it posts to, unless you change the "action" attribute of the
form tag.
Let's say I have a form and the action is thus;
\n";
Note the 'bid' attribute. Now, I have a case statement in which stuff
takes place since the form has called it because of the 'bid' attribute.
Before I break from the case I do this;
unset($_GET['bid']);
SIDEBAR: You should all note that I ma
Chris Dowell wrote:
I haven't searched through the archives to refresh my memory, but it's
something to bear in mind. I wonder whether error messages are also not
passed to the browser.
I have pointed out some more aspects of this issue:
Error messages and normal output are passed to the browser
it seems that php first ends output buffering and then calls then
destructs the objects. so the output buffering is still ended when the
destructor is calles. one has to unset the object to reverse that
order manually.
aRZed
If I remember correctly, there were a number of posts about this subj
I discovered an interesting behavior, when ob_end_flush() or
ob_end_clean() is used in a destructor of an object.
I don't think it is actually a bug, so i decided to post it here.
$f = new foo();
// end of file
?>
this ends in an error:
Notice: ob_end_flush(): failed to delete buffer. No buffer
I have ran into a rather interesting problem while zlib or gzip compression
is enabled on my site. I have an external javascript-php file (a javascript
file that is dynamically generated as in filename.js.php) which is included
in the main template using the element (for example