Home > Archive > PHP DB > May 2006 > Re: [PHP-DB] Re: Sending filing attachments using PHP
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: [PHP-DB] Re: Sending filing attachments using PHP
|
|
| JupiterHost.Net 2006-05-12, 6:58 pm |
|
Ron Piggott (PHP) wrote:
> I came up with some code today. I started e-mailing myself file
> attachments to see what my e-mail program did in preparing them and when
> I opened the e-mails I changed the view to "show e-mail source".
>
> The biggest challenge is the boundary that separates the e-mail message
> text from the file attachment. I found this command on php.net here to
> generate the boundary:
You're piping a hand crafted mime message to sendmial via mail()?
You are a glutton for pain :) (and oh yeah theres about a zillion MIME
issues you've overlooked that will come back and bite you later, gauranteed)
use a tool thats made for it:
http://search.cpan.org/perldoc?Mail::Sender::Easy
| |
| JupiterHost.Net 2006-05-12, 6:58 pm |
|
Alister Bulman wrote:
> On 12/05/06, JupiterHost.Net <mlists@jupiterhost.net> wrote:
>
>
>
> I agree - don't get bitten on the ass, but OTOH, there's already a PHP
> Mime encoder - no need to point him to a Perl library....
>
> http://pear.php.net/package/Mail_Mime
Yes there's a huge need, PHP is way to problematic and many folks don't
even realize thats its one of a hundred possible tools. Most of which
are better suited for most things.
Plus, what if you don't have Pear compiled into PHP? Now theres more
hoops, oops need zend optimizer, more hoops, oops that version doesn;t
work on that verison, more hoops. Oh yeah and you have to be root to do
all this, nice.
And that module is not a MIME tool in itself, it uses perl's MIME tools
and SMTP tools but it abstracts all of that for you so all you have to
do is make a hash that represents your mail. No knowlege of SMTP or MIME
necessary.
And you can install it as a regular user and use it yourself if need be,
what could be easier :)
| |
|
| JupiterHost.Net wrote:
> Alister Bulman wrote:
>
>
>
> Yes there's a huge need, PHP is way to problematic and many folks
> don't even realize thats its one of a hundred possible tools. Most of
> which are better suited for most things.
>
> Plus, what if you don't have Pear compiled into PHP? Now theres more
> hoops, oops need zend optimizer, more hoops, oops that version doesn;t
> work on that verison, more hoops. Oh yeah and you have to be root to
> do all this, nice.
What planet are you on? Seriously? Because PEAR does not need to be
compiled into PHP. Zend Optimizer is no different to the optimizers
available for other scripting languages. Version mismatches are a fact
of life with all tools, deal with it. And last but not least, you do not
have to be root to do anything with PHP, or indeed apache except to
listen on a port lower than 1024, which is true for all tools since it's
a platform limitation.
> And that module is not a MIME tool in itself, it uses perl's MIME
> tools and SMTP tools but it abstracts all of that for you so all you
> have to do is make a hash that represents your mail. No knowlege of
> SMTP or MIME necessary.
>
> And you can install it as a regular user and use it yourself if need
> be, what could be easier :)
Yeah, you're definitely smoking somethin'. The PEAR package Mail_Mime is
another example of a pure-php class. It certainly does not use anything
perl related at all. I'd really like to know what makes you think it does.
Oh, and there's nothing stopping you installing any of the PEAR classes
as a regular user and using it yourself. What could be easier? Not
having to read your ignorant emails.
-Stut
--
If ignorance is bliss, you must be in heaven!
| |
| JupiterHost.Net 2006-05-12, 6:58 pm |
| > What planet are you on? Seriously? Because PEAR does not need to be
> compiled into PHP. Zend Optimizer is no different to the optimizers
I was referring to --with-pear, sorry "compiled" was not the right word *
> available for other scripting languages. Version mismatches are a fact
I was referring to how Zend Opt is "required" for some stuff mainly
because its necessary to offset the bloat. *
> of life with all tools, deal with it. And last but not least, you do not
And PHP tends to have a greater majority of them, have you ever managed
PHP on multiple servers? If you have you kwo exactly what I'm referring to.
> have to be root to do anything with PHP, or indeed apache except to
I was referring to building PHP/Apache in general *
> listen on a port lower than 1024, which is true for all tools since it's
> a platform limitation.
* I'm speaking in generalitites of working with PHP not specifics
components of the technology.
>
> Yeah, you're definitely smoking somethin'. The PEAR package Mail_Mime is
> another example of a pure-php class. It certainly does not use anything
> perl related at all. I'd really like to know what makes you think it does.
I never said PEAR or any specific package used Perl, I'd simply offered
a better solution that happend to be done in Perl.
> Oh, and there's nothing stopping you installing any of the PEAR classes
> as a regular user and using it yourself. What could be easier? Not
> having to read your ignorant emails.
I was outlining some of PHP faults, not getting personal which truly
*is* ignorant.
Good day to all, sorry if I was to ambiguouse or I've offended.
| |
|
| Let me start by apologising if my posts came across as personal. Check
the archives for my posts, primarily on php-general and you will see
that I have a very sarcastic personality. No offence was meant or is
meant by what follows.
JupiterHost.Net wrote:
>
> I was referring to --with-pear, sorry "compiled" was not the right word *
I'm not familiar with the switch you are referring to. If you look into
PEAR a bit closer you will find that it is simply a package of classes.
It does not need any changes to your PHP binary for it to work correctly.
>
> I was referring to how Zend Opt is "required" for some stuff mainly
> because its necessary to offset the bloat. *
I'm not sure what gives you the impression that Zend Optimizer is
"required" for anything. ZO is a system for pre-compiling PHP code to
bytecodes such that the PHP source files do not need to be interpreted
each time they are run. While it is true that some commercial software
written in PHP is encoded and requires ZO, but this is a choice of that
particular developer and is not attributable to PHP as a language or as
a technology.
>
> And PHP tends to have a greater majority of them, have you ever managed
> PHP on multiple servers? If you have you kwo exactly what I'm referring to.
I maintain 13 servers in total, each of them have PHP installed, and
I've never had a problem with version issues. And I have to say that in
my experience other tools have more problems with this. Perl used to be
a nightmare for us until we rewrote the scripts we had in PHP. I'm not
blaming PHP for this, I'm just trying to point out that problems related
to version mismatches are usually related to the administrators
understanding of that particular package. For me that means Perl caused
me more issues than PHP because I know PHP better.
>
> I was referring to building PHP/Apache in general *
You do not need to be root to build PHP or Apache, or in fact anything
else, so I'm not sure where you're getting that requirement from.
>
> * I'm speaking in generalitites of working with PHP not specifics
> components of the technology.
In that case I would point out that your personal experiences with PHP
are not necessarily a reflection on PHP. I hope you don't take offense
at that but I know a huge number of developers and sy mins who are
more than happy with working with PHP, and nearly all of them have been
through the process of trying the alternatives before landing on PHP as
the right solution for them.
>
> I never said PEAR or any specific package used Perl, I'd simply offered
> a better solution that happend to be done in Perl.
Quoting your original post... "it uses perl's MIME tools and SMTP
tools". How is that not saying "PEAR or any specific package used Perl"?
Your solution was not "better" given the context of the question.
Specifically that the question was asking about doing something in PHP
and was asked on the PHP list meaning it's not a great leap to assume
the guy need a solution in PHP.
>
> I was outlining some of PHP faults, not getting personal which truly
> *is* ignorant.
I hope you understand that I wasn't getting personal, but you must
accept that your answers so far have suggested that you don't actually
know much about what you are talking about.
> Good day to all, sorry if I was to ambiguouse or I've offended.
Feel free to ignore the rest of this post, which I hope you'll take in
the spirit it is meant, but please answer me this. What has PHP done to
you? Why are you so anti-PHP? And specifically why are you on a PHP list
suggesting people use a different technology?
-Stut
| |
| JupiterHost.Net 2006-05-12, 6:58 pm |
| Stut wrote:
> Let me start by apologising if my posts came across as personal. Check
If? How else can "What could be easier? Not having to read your ignorant
emails." be taken?
No worries though I understand, thanks :)
>
> I'm not familiar with the switch you are referring to. If you look into
in PHP source:
../configure --help
> PEAR a bit closer you will find that it is simply a package of classes.
> It does not need any changes to your PHP binary for it to work correctly.
>
>
>
> I'm not sure what gives you the impression that Zend Optimizer is
> "required" for anything. ZO is a system for pre-compiling PHP code to
If a PHP system has been "Optimized" then it requires ZO. Most admins
need to have ZO since at least one of theri users will want to use sucha
PHP system.
> bytecodes such that the PHP source files do not need to be interpreted
> each time they are run. While it is true that some commercial software
> written in PHP is encoded and requires ZO, but this is a choice of that
> particular developer and is not attributable to PHP as a language or as
> a technology.
But it does epitomize PHP's overall paradigm of "you want to add
funtionality for XYZ? ok lets drunkenly add support for it without
tryign to be consistent or plan for anything in the future.
>
> I maintain 13 servers in total, each of them have PHP installed, and
try 13000 :) 13 is child's play and can be easily managed.
>
>
> You do not need to be root to build PHP or Apache, or in fact anything
> else, so I'm not sure where you're getting that requirement from.
So any user on your systems can recompile apache or PHP at will?
>
> In that case I would point out that your personal experiences with PHP
> are not necessarily a reflection on PHP. I hope you don't take offense
My personal experiences with PHP and many other internet technologies is
quite extensive.
> Quoting your original post... "it uses perl's MIME tools and SMTP
> tools". How is that not saying "PEAR or any specific package used Perl"?
Because I was refering to the URL I'd sent to Perl's Mail::Sender::Easy
module.
> Your solution was not "better" given the context of the question.
> Specifically that the question was asking about doing something in PHP
> and was asked on the PHP list meaning it's not a great leap to assume
> the guy need a solution in PHP.
A solution is a solution, PHP is just one tiny option, I was offering an
easier to work with alternative.
> Feel free to ignore the rest of this post, which I hope you'll take in
> the spirit it is meant, but please answer me this. What has PHP done to
> you? Why are you so anti-PHP? And specifically why are you on a PHP list
> suggesting people use a different technology?
PHP has all the problems I've been specifying, that costs time and
money, and I'm sick of it :)
I'm on this list because I am a developer for a company that makes an
apache install system and I needed to find out some info on the specific
oddness of PHP4 and PHP5's --with-mysql and --with-mysqli options so
that its would work properly.
Which in fact PHP4/5 + --with-mysql[i] *is* a huge example of what makes
PHP the last choice for any project.
| |
|
| JupiterHost.Net wrote:
> Stut wrote:
>
>
> in PHP source:
> ./configure --help
I've had a look and it would appear that all that switch does is install
PEAR for you during the build process. That doesn't change the fact that
it's still just a collection of PHP classes and does not require
rebuilding of PHP to benefit from it.
>
> If a PHP system has been "Optimized" then it requires ZO. Most admins
> need to have ZO since at least one of theri users will want to use sucha
> PHP system.
I think you're grossly over-estimating the number of PHP systems that
use Zend Optimizer, not so much as an actual number but more as a
percentage of all software written in PHP.
You're also making it sound like adding ZO to a PHP installation is a
mammoth task... it's not. It's just as simple as building PHP itself.
>
> But it does epitomize PHP's overall paradigm of "you want to add
> funtionality for XYZ? ok lets drunkenly add support for it without
> tryign to be consistent or plan for anything in the future.
How so? Take any other interpreted language, and you don't usually get
pre-compilation for free. Correct me if I'm wrong but this goes for Perl
as much as it does for PHP. You have to 'jump through hoops' to get it.
I'll freely agree that there are a number of things that exist in PHP
that are not ideal, and could appear to have been implemented by a
drunken developer trying to meet a deadline. However, having been a
lurker on the PHP-Dev list for a long time now I can say with absolute
confidence that most of the decisions made regarding what gets into PHP
and what doesn't are well-justified.
PHP is not a small system, and it takes a huge effort to manage the
ongoing development. Mistakes have been made and undoubtedly will
continue to be made, but I'm sure the same can be said for any
similarly-sized open-source project.
>
> try 13000 :) 13 is child's play and can be easily managed.
IMHO, 13,000 servers should be just as easy to manage as 13 - it all
depends on the infrastructure (in terms of tools) you have in place to
assist you in the task.
Out of curiosity, why do you find it easier to manage Perl on 13,000
servers? What specific advantages does it have over PHP when it comes to
this?
>
> So any user on your systems can recompile apache or PHP at will?
Yeah, I don't stop them - more hassle than it's worth. But they'll be
compiling it in their own directories, they'll be running their own
copies. They can't interfere with the systems installation of either
because file permissions don't let them, but that doesn't stop them
working on their own copies of it.
Any user with shell access with the required build tools available to
them will be able to do the same. If you think otherwise I encourage you
to try it.
>
> My personal experiences with PHP and many other internet technologies is
> quite extensive.
I don't doubt that, but I'm not understanding what Perl gives you that
makes it easier to manage than PHP. Please explain it to me so I can
learn something from this exchange. You clearly feel quite passionate
about it, so please share.
>
> Because I was refering to the URL I'd sent to Perl's Mail::Sender::Easy
> module.
Reading back I see that now, but it was a bit ambiguous. My apologies.
>
> A solution is a solution, PHP is just one tiny option, I was offering an
> easier to work with alternative.
Without adequately explaining why it's easier. And more to the point you
are still on a PHP list, and as I've stated before, the question was
clearly asking for a PHP solution.
>
> PHP has all the problems I've been specifying, that costs time and
> money, and I'm sick of it :)
Yeah, I got that already :). What I haven't grok'd is what specifically
makes Perl easier and therefore cheaper to manage.
> I'm on this list because I am a developer for a company that makes an
> apache install system and I needed to find out some info on the specific
> oddness of PHP4 and PHP5's --with-mysql and --with-mysqli options so
> that its would work properly.
>
> Which in fact PHP4/5 + --with-mysql[i] *is* a huge example of what makes
> PHP the last choice for any project.
Again, this is a statement that makes no sense to me. You've made a
statement saying you hate something without explaining why. Do you see
why it's very hard to learn from you when you don't justify your hatred?
What's the problem with the MySQL modules available for PHP? I
personally have never had a problem with them, but if there is a better
way I'm all ears.
-Stut
| |
| JupiterHost.Net 2006-05-12, 6:58 pm |
| >> in PHP source:
>
> I've had a look and it would appear that all that switch does is install
> PEAR for you during the build process. That doesn't change the fact that
> it's still just a collection of PHP classes and does not require
> rebuilding of PHP to benefit from it.
sure no problem, again mostly I was speaking in gernalities about how
its works and referencing the switch since you'd never heard of ti.
> You're also making it sound like adding ZO to a PHP installation is a
> mammoth task... it's not. It's just as simple as building PHP itself.
Which is a mammoth task ;)
> How so? Take any other interpreted language, and you don't usually get
Even though PECL and PEAR alleviate some of the headache by trying to be
CPAN, much funtionality is based on build options (mysql, curl, etc)
So if I find that my server does not have, say, mysql support built in
or I need a special kind (see ./configure --help for a list) then PHP
will most likely need recompiled.
If it breaks, you may break PHP for everyone, it may even take down
apache if the .so got goofy.
With Perl
perl -MCPAN -e 'install DBD::mysql;'
if it breaks then
- all scripts still work
- apache still works
> pre-compilation for free. Correct me if I'm wrong but this goes for Perl
> as much as it does for PHP. You have to 'jump through hoops' to get it.
one command, no possiblity of breaking anything, one hoop, very low to
the ground and about ten feet tall :)
> Out of curiosity, why do you find it easier to manage Perl on 13,000
> servers? What specific advantages does it have over PHP when it comes to
> this?
Perl just works and make sense so its easier to code with. Any issue
sthat do come up now and then are usually resolved by a moduel upgrade,
one CPAN cpmmand :)
>
> Yeah, I don't stop them - more hassle than it's worth. But they'll be
Ok, i guess I'm refering to running a webserver that all the user's
share. If "bob" needs --with-curl then PHP needs to be recompiled. in
practice most hosting customers are hosting customers because they
woudln't knwo anythgin about compiling their own anything.
Its all really besides the point though, perhaps I shoudl have just
phrased it "you have to recompile some major stuff just to add minor
functionality"
>
> I don't doubt that, but I'm not understanding what Perl gives you that
> makes it easier to manage than PHP. Please explain it to me so I can
As I stated I'm not doing a Perl vs PHP rant I'm doing an "anything but
PHP" rant :)
> learn something from this exchange. You clearly feel quite passionate
> about it, so please share.
Actually since most everyone has expressed an interest in stopping this
thread, I think I will. Teh facts are there do as you wish :)
>
>
> Without adequately explaining why it's easier. And more to the point you
Sure I did, no one wants to hear it though :)
> are still on a PHP list, and as I've stated before, the question was
> clearly asking for a PHP solution.
True enough, but if you want to be strict then why not send them to a
none DB list?
>
> Yeah, I got that already :). What I haven't grok'd is what specifically
> makes Perl easier and therefore cheaper to manage.
As I stated I'm not doing a Perl vs PHP rant I'm doing an "anything but
PHP" rant :)
>
> Again, this is a statement that makes no sense to me. You've made a
> statement saying you hate something without explaining why. Do you see
Because its got *soooo* many problems, security, development, admin wise
- details throughout this thread :)
> why it's very hard to learn from you when you don't justify your hatred?
> What's the problem with the MySQL modules available for PHP? I
Those configure flags have so many combinations to get unpredicatabel
behavior this is the pseudo thought process while doing it:
--with-mysql (make sense so far)
but lest add the super duper mysqli stuff:
Oi crap what arg do you give it depending on what --with-mysql 's value is?
--with-mysql=/usr --with-mysqli=path_to_mysql_config
--with-mysql --with-mysqli=/usr
Is all of that mess the same on PHP 4 and 5 ?
What if you have mysql 4.0, 4.1, or 5 ?
and once you get your head wrapped around it are all the badly named
funitons gogin to behave the same?
> personally have never had a problem with them, but if there is a better
> way I'm all ears.
yep, use Perl's DBI modules or some other API (C, Python, Ruby,
*anything*) to MySQL that is consistently easier to setup and use
| |
|
| I think we may have to agree to disagree. I love PHP. I've never had a
problem with it that couldn't be solved that's made me want to switch.
Just to make it clear I do try the so-called "up-and-coming" development
trends, and over the years have tried most of the existing systems. I
recently started using Rails, which has some very nice features but I
find it far too restrictive for development of anything more than 'toy'
apps. Just wanted to make the point that I'm not pro-PHP for no reason.
I've tried the rest, I've settled on what I believe to be the best.
JupiterHost.Net wrote:
>
> sure no problem, again mostly I was speaking in gernalities about how
> its works and referencing the switch since you'd never heard of ti.
>
>
> Which is a mammoth task ;)
No more so than building Perl or Python or Ruby IMHO.
>
> Even though PECL and PEAR alleviate some of the headache by trying to be
> CPAN, much funtionality is based on build options (mysql, curl, etc)
Again, this is not true. As far as I know, PHP is architected as a core
engine with modules for all userland functions, including what could be
considered basic features such as array operations. What this means is
that each module that provides additional functionality can be built as
a dynamically loaded object. That is to say separate from any other
functionality.
> So if I find that my server does not have, say, mysql support built in
> or I need a special kind (see ./configure --help for a list) then PHP
> will most likely need recompiled.
Not so. Or rather, I should say, build the .so.
> If it breaks, you may break PHP for everyone, it may even take down
> apache if the .so got goofy.
>
> With Perl
> perl -MCPAN -e 'install DBD::mysql;'
>
> if it breaks then
> - all scripts still work
> - apache still works
Build the .so. Run php on the command line with a script that uses the
dl function to dynamically load the new module. If it doesn't work it
hasn't broken anything since it's dynamically loaded. If it does work
then you update the configuration file that lists the extensions to be
loaded at startup and restart Apache.
>
> one command, no possiblity of breaking anything, one hoop, very low to
> the ground and about ten feet tall :)
Likewise with adding MySQL to PHP, as long as you do it right. Do it the
lazy way (which is just to recompile) and you could encounter problems.
>
> Perl just works and make sense so its easier to code with. Any issue
> sthat do come up now and then are usually resolved by a moduel upgrade,
> one CPAN cpmmand :)
Same with PHP.
>
> Ok, i guess I'm refering to running a webserver that all the user's
> share. If "bob" needs --with-curl then PHP needs to be recompiled. in
> practice most hosting customers are hosting customers because they
> woudln't knwo anythgin about compiling their own anything.
>
> Its all really besides the point though, perhaps I shoudl have just
> phrased it "you have to recompile some major stuff just to add minor
> functionality"
We're talking about different things. The only point I was making is
that building PHP and apache do not *require* root. In fact only
installing it requires root. You certainly don't need root to run
either. You seem to be extending this to include whether users are
capable. That's irrelevant - they can if they want to, but in most cases
it's not worth their while.
In your example of "bob" and his CURL module, it's as simple as building
to .so (bob can do this if he's able), sticking it in the right
directory and running a test script (as I described above) to ensure it
doesn't break anything. No recompilation of PHP, or any other "major
stuff" needed, and nothing gets broken.
>
> As I stated I'm not doing a Perl vs PHP rant I'm doing an "anything but
> PHP" rant :)
And that justifies it how? All I'm getting is an "I hate PHP and nothing
you say will sway me from that opinion". Is that accurate? Because if it
is I have better things to do with my time.
>
> Actually since most everyone has expressed an interest in stopping this
> thread, I think I will. Teh facts are there do as you wish :)
Agreed, we should probably both give up. The "facts" are still in
dispute, but each to his or her own.
>
> Sure I did, no one wants to hear it though :)
>
>
> True enough, but if you want to be strict then why not send them to a
> none DB list?
Fair point, but it was still a *PHP* list not a generic DB list.
>
> As I stated I'm not doing a Perl vs PHP rant I'm doing an "anything but
> PHP" rant :)
>
>
> Because its got *soooo* many problems, security, development, admin wise
> - details throughout this thread :)
Yeah, about those security problems. You mentioned phpBB as an example.
You must be aware that nearly every problem related to security that has
ever been found in relation to PHP has been down to poor implementation
on the part of the script developer and not PHP itself. All other
languages and tools are open to the same type of problems, but
popularity and user-base of PHP cause bad press.
>
> Those configure flags have so many combinations to get unpredicatabel
> behavior this is the pseudo thought process while doing it:
>
> --with-mysql (make sense so far)
>
> but lest add the super duper mysqli stuff:
>
> Oi crap what arg do you give it depending on what --with-mysql 's value
> is?
> --with-mysql=/usr --with-mysqli=path_to_mysql_config
> --with-mysql --with-mysqli=/usr
Please enlighten me as to how other tools find the MySQL libs. As far as
I'm aware they do it in exactly the same way, namely an automatic search
which will occasionally fail which requires the ability to specify it in
the configure command.
> Is all of that mess the same on PHP 4 and 5 ?
Pretty much.
> What if you have mysql 4.0, 4.1, or 5 ?
Doesn't matter.
> and once you get your head wrapped around it are all the badly named
> funitons gogin to behave the same?
Badly named functions? There are some dodgy ones still in there for BC
reasons, but this has improved a lot since PHP 4 & 5 arrived.
>
> yep, use Perl's DBI modules or some other API (C, Python, Ruby,
> *anything*) to MySQL that is consistently easier to setup and use
Again, we'll have to agree to disagree. For me PHP makes setting up and
using MySQL a breeze.
Anyway, I think we should end this here since we're clearly not making a
dent in each others opinion of PHP. Feel free to reply to me offlist if
you really want to continue, but I don't think there would be much point.
-Stut
| |
| JupiterHost.Net 2006-05-12, 6:58 pm |
|
Stut wrote:
> I think we may have to agree to disagree. I love PHP. I've never had a
Ah I completely forgot about this sort of fun thing that I find in my
email almost once a w , just got this one:
http://forums.gentoo.org/viewtopic-t-460727.html
now how many phpinfo() pages do you think there are and how many are
vulnerable to the cross-site scripting attack.
So this report means you have to upgrade your binary and it addresses:
- system level problems (buffer overflow, memory leak, potential crash)
- web based secuity attacks (corss-site scripting)
- code based security attacks (restriction bybasses)
*exactly* the sort of stuff thats jaded me :)
Time to upgrade each install of PHP on all 13 server's :)
The phpingo(0 reminds me of the one they had where a php file with only
this line:
<? phpinfo(); ?>
would allow an attacker to upload a rootkit and damage the system,
saaaweeet ;p
or a cross site scripting/SQL injection thing that'd allow people to
post HTML to your site and make it show whatever they wanted...
good times, good times
Peace everyone, its been really fun :)
| |
| Bastien Koert 2006-05-12, 6:58 pm |
| php is not the only language susceptible to x-browser attacks... seems
unfair to single it out.
And as previously pointed out, many times it the developer's fault for
writing that insecure code
Bastien
>From: "JupiterHost.Net" <mlists@jupiterhost.net>
>To: php-db@lists.php.net
>Subject: Re: [PHP-DB] Re: Sending filing attachments using PHP
>Date: Fri, 12 May 2006 18:53:13 -0500
>
>
>
>Stut wrote:
>
>Ah I completely forgot about this sort of fun thing that I find in my email
>almost once a w, just got this one:
>
>http://forums.gentoo.org/viewtopic-t-460727.html
>
>now how many phpinfo() pages do you think there are and how many are
>vulnerable to the cross-site scripting attack.
>
>So this report means you have to upgrade your binary and it addresses:
> - system level problems (buffer overflow, memory leak, potential crash)
> - web based secuity attacks (corss-site scripting)
> - code based security attacks (restriction bybasses)
>
>*exactly* the sort of stuff thats jaded me :)
>
>Time to upgrade each install of PHP on all 13 server's :)
>
>The phpingo(0 reminds me of the one they had where a php file with only
>this line:
>
> <? phpinfo(); ?>
>
>would allow an attacker to upload a rootkit and damage the system,
>saaaweeet ;p
>
>or a cross site scripting/SQL injection thing that'd allow people to post
>HTML to your site and make it show whatever they wanted...
>
>good times, good times
>
>Peace everyone, its been really fun :)
>
>--
>PHP Database Mailing List (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php
>
| |
| JupiterHost.Net 2006-05-12, 9:56 pm |
|
Bastien Koert wrote:
> php is not the only language susceptible to x-browser attacks... seems
> unfair to single it out.
Why not? Its the only I've seen that actually has hackability built in!
(see below) So it singles itself out, thats the whole point :)
> And as previously pointed out, many times it the developer's fault for
> writing that insecure code
Yes developer does cross-site scripting suseptable code = developer's fault
* but if a script has *only* this as its content:
<? phpinfo(); ?>
And *that* script has cross-site vulnerabilities is the programmer at
fault for writing bad code?
No, he's at fault for using PHP
I rest my case ;)
The only solution is to upgrade the binary.
That SUCKS big time!
|
|
|
|
|