Re: The most powerful CMS developed in Perl (not spam, sounds that way) (without functions)

[Anonymous Monk]

in reply to The most powerful CMS developed in Perl (not spam, sounds that way)

I LOVE feedback, it makes my day to read comments and suggestions, so if you try it out please let me know what you think.

Throw it away and start over :/

For example forums_section_threads.function and index.pl show everything that is wrong with your code :)

You forgot the ballad of bobby-tables.com: A guide to preventing SQL injection

You're rolling your own CGI.pm, use CGI or die;

You don't have enough functions  ## load parent settings if avail should be a function,  ## load pre plugins should be a function ... everything you repeat should be a function, ... skimmable code is the idea

Also  no strict "refs"; and .function? see Simple Module Tutorial, Module::Pluggable, AutoLoader/AutoSplit...

Speaking of red flags, see
Mark Jason Dominus - Perl Program Repair Shop and Red Flags - YouTube,
Program Repair Shop and Red Flags - Perl.com,
Return of Program Repair Shop and Red Flags - Perl.com
http://perl.plover.com/flagbook/yak/Chi/TABLE_OF_CONTENTS.html

[snoopy20]

I think you need to look at it properly.

1. There is no SQL injection, all code is protected. Please supply any example where it is not.

2. CGI is bloated. The internal method is MUCH faster.

3. Don't have enough functions - are you kidding!!! Have you counted the amount of functions??? try /igaro/, /igaro/functions/, igaro/functions/plugins etc.

The reason those particular bits you refer to are not functions is they are not called again by any function. When code is duplicated it becomes a plugin and stuck in /igaro/. You'll see that there are already many.

4. No strict refs impossible when using &{$..} as far as I'm aware.

Regards, Andrew

[Anonymous Monk]

There is no SQL injection, all code is protected. Please supply any example where it is not.

I linked the xample. 1) you don't use $dbh->quote, 2) you don't use placeholders 3) you interpolate variables into $dbh->do

2. CGI is bloated. The internal method is MUCH faster.

*sigh* So you didn't read use CGI or die, congratulations, this is the last time I give you advice :)

Don't have enough functions ...

:|

4. No strict refs impossible when using &{$..} as far as I'm aware.

Gee, kinda why I said to use pluggable and real actual modules not .functions

Have a nice day

[Anonymous Monk]

Here goes… 1. $dbh_quote is used all over, but not when it's not required where the variables have been pre-checked by parent modules. This is faster. 2. The denial of service you refer to I presume is the overloading of URI data, to be fair there are much easier ways to create a DOS attack than this. This I think should be left to the web server. Otherwise, you haven't given any credible explanation as to why CGI should be used over the internal method. 4. Not possible without object orientation. Nothing wrong with &{$_} either.

[chromatic]

CGI is bloated. The internal method is MUCH faster.

Maybe it's faster, but it has at least one denial of service bug and one data loss bug. (I stopped looking after two seconds, so it may have more bugs).

[Anonymous Monk]

Not sure what data loss bug you are referring to? Overloading with data will not cause a DOS attack, the web is far too slow for that, and there are no other security issues that will cause a DOS failure that I'm aware off. And not 'Maybe' it's faster - it is faster. ;) Please refer to specific lines of code as your comments are at best spurious. I don't mean to sound offensive, but I am unable to relate to the specific issues you are pointing out. Regards, Andrew

[snoopy20]

I forgot to add, the reason Module::Pluggable etc are not used is because igaro is functional not object/module orientated.