Re: A case for developer centric PHP frameworks [spammer]
Erwin Moller
Celeroo, celeroos, whatever.
We have seen your spam the first time.
You have just found out the best way to irritate the PHP community: keep
posting how great your framework is in a technical newsgroup.
Maybe you think this is the way to gain popularity: it is not.
I will never use it, simply because you spam too often.
Good job.
Regards,
Erwin Moller
--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
Ulf Kadner
> I will never use it, simply because you spam too often.
> Good job.
There is a realy better reason to ignore it completely!
It contains a lot of code like this and other stupid stuff in a lot of
cases:
$q="INSERT INTO $T_SETTINGS (name,value,defval) VALUES
('adminlogin',\"$_POST[adminlogin]\",'ADMINLOGIN'),
('adminpass',\"$_POST[adminpass]\",'ADMINPASS'),
('site_url',\"$_POST[site_url]\",'SITE_URL')";
Best regards, Ulf
Gordon
Code brought to you by fearless people who don't even know the meaning
of the word "Validation", and who laugh in the face of SQL injection
attacks!
Erwin Moller
Brrrrrrr.
Thanks for fishing that up.
Maybe the programmer is one of those that 'prepare' the $_POST before
using it. A method I totally dislike, but it would be better than using
it raw.
Either way: poor code.
But since he spams, it doesn't matter anymore. :P
Ulf Kadner
> Brrrrrrr.
> Thanks for fishing that up.
np
> Maybe the programmer is one of those that 'prepare' the $_POST before
> using it.
You are hopefull? :-)
This and some includes without security handling / filtering code comes
before:
if(!empty($_POST[ok]))
{
if($_POST[dbtype]==1)
{
@mysql_connect($_POST[dbhost],$_POST[dblogin],$_POST[dbpass]) or
msg_die (mysql_error());
@mysql_select_db($_POST[dbname]) or msg_die (mysql_error());
$wrapper="inc/mysql_wrapper.php";
}
...
this is absolutely poor stuff.
> Either way: poor code.
:-)
best regards, Ulf
cele...@gmail.com
that we are looking at feedback that will help us improve Frame. That
means we need specific points rather than blanket statements like "lot
of poor code". We know there are lots of experts out there who can be
helpful. And we have received helpful feedback, and appreciate that.
The comments above sadly do not help at all.
What is more, they are completely uneducated and if anything, merely
"textbook-ish", with no intelligent thought spared, whatsoever.
Yes, the code in install.php is completely insecure. There are no
validations of any kind. AND WE ARE NOT GOING TO CHANGE IT. We made
a simple assumption that installations are NOT done by drunk or
suicidal people.
If you want to "hack" your own installation, go ahead and do it.
Unless you deliberately want to do that, there is no issue with the
security. This is an installation script and it will be used by the
owner of the application ONLY to install it. It will not be accessible
by end users at all, so there is no point in performing any validation
of the user input. If you really want to delete your DB, why do you
want to download and install Celeroo Frame, and then input stuff to
delete the DB? You have access to your DB anyway and can delete it
directly :-)
Saying that an installation script is insecure because it doesn't
perform input validations is like saying that phpMyAdmin is insecure
because it lets you perform any kind of SQL queries.
We are sure you missed the point about the installation part
accidentally and made those comments. And hope we have been able to
clarify it. If not, just put that textbook down and think for just a
minute and you might see some logic.
--------------------------------------------------------------------------
Erwin Moller
First of all: Congrats! You respond.
That is a start.
> First of all, we want to repeat what we clearly stated in our post
> that we are looking at feedback that will help us improve Frame. That
> means we need specific points rather than blanket statements like "lot
> of poor code". We know there are lots of experts out there who can be
> helpful. And we have received helpful feedback, and appreciate that.
> The comments above sadly do not help at all.
>
> What is more, they are completely uneducated and if anything, merely
> "textbook-ish", with no intelligent thought spared, whatsoever.
Poor Ulf.
The spammer says he is uneducated. :-(
I must admit that IF I looked at your code, I would come to the same
conclusions as Ulf did. How much trouble can it be to do the installpart
right too, even though you trust the user?
>
> Yes, the code in install.php is completely insecure. There are no
> validations of any kind. AND WE ARE NOT GOING TO CHANGE IT. We made
> a simple assumption that installations are NOT done by drunk or
> suicidal people.
>
> If you want to "hack" your own installation, go ahead and do it.
> Unless you deliberately want to do that, there is no issue with the
> security. This is an installation script and it will be used by the
> owner of the application ONLY to install it. It will not be accessible
> by end users at all, so there is no point in performing any validation
> of the user input. If you really want to delete your DB, why do you
> want to download and install Celeroo Frame, and then input stuff to
> delete the DB? You have access to your DB anyway and can delete it
> directly :-)
OK, as stated: I didn't look into your code because you are a spammer.
If what you say is true (and I have no reason to doubt that) you only
made the installpart insecure.
I wonder why, since you appearantly know how to do it properly in the
rest of the code (as you claim).
The problem stays however (appart from the SQL injection for admins):
You are spamming this group.
Please stop that.
Now, you seem like a reasonable guy (since you responded, that is
something most spammer never do).
So please tell us: How on-topic would this newsgroup, or any other, be
if any start-up project kept posting messages about their great framework?
Don't you see that is irritating?
Gordon
You want advice? Okay, here's mine. Quit programming and take up
origami. You'll probably cause less harm that way.
Gregor Kofler
[fullquote & top posting dumped]
We? You mean more than one is working on this masterpiece? I read only
of you Bobby...
I just skimmed over you mysql-"class", which is easy, since there's
hardly any code in there. Ever thought about proper error handling?
Enabling and disabling it? Logging? A framework is supposed to do more,
than just wrap a few pedestrian routines in a new "method".
Ok, since you want to improve your "framework":
* Clean up you classes - what has AJAX with a navigation widget in common?
* Are there any priorities set? I assume not. A few lengthy functions
for resampling images, a primitive upload script, an even more primitive
email function,...
* You claim, that you filter user data? What's that?
$q="UPDATE $T_SETTINGS SET
value=\"".$_POST[$name]."\"
WHERE name=\"$name\"";
* $HTTP_SERVER_VARS? It's 2009.
* Get rid of things like
<a href=\"javascript:void(0);\" onclick=\"".$path."$off);\">
<div style='text-align:center;' align=center>
and learn how interpolation works. Find someone who knows contemporary
web authoring.
* Separation of markup from the code would be smart
* how about caring about different locales?
* Some generalization makes maintenance easier:
...
Creates a dropdown for choosing a date
Creates a dropdown for selecting a value
Creates a dropdown for selecting a value (assoc)
...
I'm sure my first attempts at PHP looked similar, maybe worse. But I'd
never had the cheek to spam a PHP newsgroup announcing it as a "lean
framework for programmers". I'd say "dimwits" nails it.
Gregor
--
http://www.gregorkofler.com
http://web.gregorkofler.com - vxJS, a JS lib in progress
PHP Expert
negative and sarcastic remarks. We will also ignore the holier-than-
thou attitude that is on ample display.
However, this being a nice discussion group, we will respond to many
points because there are some good points made and there are others we
need to clarify further.
One of the valid points Gregor has is that some of the code is archaic
and some functions are a bit dirty. That's because we have been using
most of this code for years - and since it works we haven't seen a
need to rewrite (besides the negative comments we still don't see a
need, but we will probably need to take them into account in a future
version).
The functions for pagination, for example, are a bit dirty in the
sense that they output some HTML directly from the PHP which in
general is not a good idea (because it can't be changed by a
designer).
There is one main reason for this to be like that, however (besides
the fact that it's old code that has worked over the years): it's
shorter and simpler to use. To make a pagination, send email or upload
file in Celeroo (if you use the procedural versions) you need one line
of code with almost no preparation of any kind. To do the same in
Cake, CodeIgniter you need to read tutorials like this one:
http://groups.google.com/group/cake-php/msg/88f108d4a60687f7and to
write around 10 lines of code. Not to mention the Rails way.
Frame's main idea is to make things easy and fast, with less typing
and less learning. If one is such a great expert and OOP guy like
those in Usenet they have 3 options:
a) to use the OOP versions of most of the procedural functions that
are there in helpers/ folder of Frame. To extend them and improve them
on their own as much as they like.
b) to use Cake, CI or Zend which all use the super modern way of doing
things in pure OOP writing ten lines of code for each 1 line in
Celeroo. (Strange why php.net site is written in procedural code.
Maybe that's because php.net webmasters are amateurs and the guys in
Usenet are gr8 h@cXs)
c) to use their own framework, like an expert is probably doing
anyway.
We can however make some templates for these few functions that now
output HTML in order to keep the design separated.
* Get rid of things like
<a href=\"javascript:void(0);\" onclick=\"".$path."$off);\">
<div style='text-align:center;' align=center>
and learn how interpolation works. Find someone who knows contemporary
web authoring.
- Point taken, we have some invalid/outdated HTML code. Especially
some places that use tables - both in the PHP code and in the views.
- Not sure about the interpolation thing, I guess Gregor has an idea
how the pagination can be made using it. We haven't seen such,
therefore can't comment. But as long as we have worked with the
current code, it has created pagination that works just fine.
* You claim, that you filter user data? What's that?
$q="UPDATE $T_SETTINGS SET
value=\"".$_POST[$name]."\"
WHERE name=\"$name\"";
1) There is basic filtering done in defines.inc.php
2) This is a superadmin function and it's not supposed to filter
anything anyway. It does exactly what it needs to do - lets you write
set_setting("adminpass"); for example and updates "adminpass" with
the corresponding POST value or whatever other setting you decide to
let him change. These settings are then used in the code. It doesn't
need to check whether the $name variable is in some allowed list
because you, the programmer, are passing it to the function in your
code. It does need to allow putting just everything there and no
filtering is needed of any kind (not even escaping the values one
although it's prepared in defines.inc.php)
3) There is no such thing like general filtering. There is only
mysql_real_escape_string() which is done in defines.inc.php and even
that's too much, because you may want to have the unescaped data for
something. Go see Cake or any other of the big frameworks, they
provide sanitization classes but they don't do any filtering until you
explicitly use the class in a specific case. In some case you will
want HTML tags stripped out, in other cases you will want even
javascript along with <script> tags inserted into the database.
Filtering and security checks need to be done depending on the
specific need. Neither in install.php nor in the superadmin function
set_setting() we need to filter anything.
how about caring about different locales?
We aren't doing this because for now we don't think it's common enough
to be included in a framework that aims to be minimalistic. If you are
building a multi-language site you can add support for locales
yourself or pick a framework that provides it.
Clean up you classes - what has AJAX with a navigation widget in
common?
The navigation widget is creating ajax-based pagination. To us somehow
it sounds like both have something in common. And it's not a class by
the way, it's a library of procedural functions.
I just skimmed over you mysql-"class", which is easy, since there's
hardly any code in there. Ever thought about proper error handling?
Enabling and disabling it? Logging? A framework is supposed to do
more, than just wrap a few pedestrian routines in new "method".
What we needed was to have a shorter and more convenient way of
running a query and especially retrieving the results in arrays,
something that avoids the unpleasant and long syntax of mysql_query()
and mysql_fetch_array(). To us writing $items=$DB->aq($q) looks much
better than writing
$result=mysql_query($query);
while($row=mysql_fetch_array($result))...
but of course you may have a different opinion. The second reason to
write a class instead of using the built in functions is that it
allows eventually changing the database engine with less effort.
That's the point of using wrappers, either procedural or OOP.
Yes, there is no error handling - this is a first version of a
minimalistic framework so it doesn't include many things. If that was
a suggestion to add error handling, that's exactly what we were
looking for - suggestions on what to add, so thanks for this one.
Ulf Kadner
> First of all, we want to repeat what we clearly stated in our post
> that we are looking at feedback that will help us improve Frame.
OK. Delete it and write it new. Better use some programmers with more
knowledge. May this helps alot.
> What is more, they are completely uneducated and if anything, merely
> "textbook-ish", with no intelligent thought spared, whatsoever.
I will stop my feeding of you here.