Suggestions to a version 2.0

[Aventro]

I believe there is plenty that can be rewritten or updated in the engine, and I would just like to propose some of my suggestions on what can be done. I like the engine overall, and instead of developing my own, I would rather make this one a bit up to date and perhaps a bit more active? Personally I would be glad to contribute with different modules If this could take place.

Suggestions:

- The password hashing sucks. First off it's using a non-iterated simple hash. Have a look here: http://stackoverflow.com/questions/4948322/fundamental-difference-between-hashing-and-encryption-algorithms/4948393#4948393

The salt is stored separetly. The salt must be unique to each and every record in order for it two work. The logical place put it is along side the password. Also it's using a pepper, which also is bad, have a look here: http://blog.ircmaxell.com/2012/04/properly-salting-passwords-case-against.html

The solution is to use a library, I would recommend PHPASS (http://www.openwall.com/phpass/) or PHP-PasswordLib. (http://blog.ircmaxell.com/2012/04/introducing-passwordlib.html) I am personally using the latter in my engine.

- Smarty: The current version in the engine is 2.6 or something like that, there has been a 3.0 release. An update would be appropriate. I haven't read the patch notes, but I believe it would be in our favour.

- Variables expanding: This is a personal thought, but there is many people agreeing with me, I think we should expand the variables that have those random abbreviations. I believe a variable should tell exactly what it is intended for when looking at the name, therefore a quick change on the short abbreviations would be more logical and generally just looking better.

- Clean the URL, Fix the MSG. The URL is messy, heavy messy. I am talking about sending the messages through the url with urlencode.

Instead we should consider using like a SESSION flash message like how cakephp/codeigniter have implemented a similar functionality to provide this one-time messages. This is easy to fix.

- Nice urls! Instead of index.php?mod=module&act=hello We could consider making some simple mod_rewrite and give the engine some nice urls,

module_name/action etc.

- reCaptcha: Instead of the custom builded captcha (more code, gd libraries(?) etc) that also requires a lot of additional code, you should consider the more developed, updated recaptcha api, it's easy as hell to integrate and is way better imo.

- Clear up the code: We should remove all one-liner if statements and properly give them some brackets, there are 2 bytes extra in the line, but the code looks much cleaner and better.

- Change the database abstraction layer: This could be heavily discussed but honestly, I believe there is time to update from the mysql_ functions and use PDO, we could also build a high level wrapper on the PDO and therefore keep the functionality but also increase it in speed and etcetera. Consider this post: http://webdevrefinery.com/forums/topic/1272-your-mysql-code-sucks

Just a couple of suggestions after scanning through the engine, I am quite sure I could come up with more. What do you think? Would it be essential and in our favor to update this otherwise excellent engine?

[Spudinski]

I agree with the "continuing to develop" ezRPG.

If you're really interested in it, make a branch on Github and people will join in(including me personally).

As for your points, I have a few problems with it:

Hasing of passwords: If I ever see hashing done like that post you linked to, I'd kill them.

There are other methods that are more secure, like blowfish.

See more information at: http://webdevrefinery.com/forums/topic/11331-best-hashing-algo-for-storing-passwords/page__view__findpost__p__120331

Variable abbreviations: It's actually common practice in programming, and is much better than long variable names.

Take some PHP functions and variables expanded:

stringtotime
$ENVIRONMENT
fileopen
fileread
mystructuredquerylangauage_query()
mystructuredquerylangauage_select_database()

 

The mysql I'm half for, but there's no need.

The only reason I've ever had to switch to PDO or mysqli was because of data encoding that sucks in mysql(splits multi-byte characters to 8byte).

But then again, mysqli is broken in procedural context, mysqli_connect has no return. Having this in ezRPG would be a rather tall task.

[Aventro]

https://github.com/ircmaxell/PHP-PasswordLib is using Blowfish method. But I think we be rather off with PHPASS instead due to PasswordLib being in alpha, but we can ascertain this is nothing you want to go accomplish yourself unless you have a lot of time for it.

I agree with the variable abbreviations, I'm just pointing out that there should be logical abbreviations, I didn't really look over it in ezrpg, but I just felt like naming it as it's quite an interesting point anyway.

 

About the mysql it would fit as for a discussion later.

 

I'll be setting up a Github branch asap.

[Ben Nash]

I would also join this group...

[Spudinski]

https://github.com/ircmaxell/PHP-PasswordLib is using Blowfish method. But I think we be rather off with PHPASS instead due to PasswordLib being in alpha, but we can ascertain this is nothing you want to go accomplish yourself unless you have a lot of time for it.

I agree with the variable abbreviations, I'm just pointing out that there should be logical abbreviations, I didn't really look over it in ezrpg, but I just felt like naming it as it's quite an interesting point anyway.

 

About the mysql it would fit as for a discussion later.

 

I'll be setting up a Github branch asap.

I'll fork it. :P

[Aventro]

Already got it set up though, https://github.com/devjosmith/ezrpg

[Spudinski]

Already got it set up though, https://github.com/devjosmith/ezrpg

Forked.

Btw.

 

svn move readme.txt readme.markdown
svn commit . -m"pretty docs"

[Aventro]

Forked.

Btw.

 

svn move readme.txt readme.markdown
svn commit . -m"pretty docs"

Done and done. I am going to let Boother make a subcategory where we can have further discussion regarding what updates Version 2.0 should have.

[rulerofzu]

Apart from the obvious reason is it worth using such a password encryption method.

I can see the obvious point. I did consider using a AES method myself but then thought well actually. Is my game going to attract that *much* attention. Also is a hashed salted sha512 suitable for my requirements. Yes it is quite easily.

Just think its overkill for something this level but I suppose if the engine is going to go through a major overhaul then it doesnt hurt to just implement it.

As for mysql,mysqli,pdo

PDO is going to reduce the amount of users that can install and run the engine. Its not installed out of the box when compiling php.

Mysqli preferred over mysql.

Recaptcha. Hate it. I do use it. But cant stand it. Its at 99% of the time hard to read. Not fool proof anyway.

Smarty. There is better ones out there if your going to go down such a redevelopment route anyway.

[Spudinski]

PDO, it was there when I compiled 5.3.2. (CentOS).

[rulerofzu]

Ah yes but its not there in most images used by hosting companies.

Most certainly not there by default with cPanel and Plesk installs.

[Spudinski]

May be, but it's easily installed. And it should have ported version somewhere.

[Aventro]

Apart from the obvious reason is it worth using such a password encryption method.

I can see the obvious point. I did consider using a AES method myself but then thought well actually. Is my game going to attract that *much* attention. Also is a hashed salted sha512 suitable for my requirements. Yes it is quite easily.

Just think its overkill for something this level but I suppose if the engine is going to go through a major overhaul then it doesnt hurt to just implement it.

As for mysql,mysqli,pdo

PDO is going to reduce the amount of users that can install and run the engine. Its not installed out of the box when compiling php.

Mysqli preferred over mysql.

Recaptcha. Hate it. I do use it. But cant stand it. Its at 99% of the time hard to read. Not fool proof anyway.

Smarty. There is better ones out there if your going to go down such a redevelopment route anyway.

I believe you are wrong about the PDO reducing amount of users that can install. Since 2010 it has been encouraged to use the extensions pdo or mysqli, and they should therefore by default be enabled. I believe I haven't yet met a webhost that don't have those extensions ready to use: http://news.php.net/php.internals/53799

About Smarty, I have just used Twig (template engine, it is integrated in Symfony framework). I did indeed prefer Twig due to the escaping, the cache method etcetera. This can be discussed as well.

I am also thinking about the current database structure, imo I would rather see the "character" (level, strength) etc taken out in to a new table, this way users can have many "characters/heroes" instead of one.

Edited May 19, 2012 by Aventro

[rulerofzu]

Having ran a webhost have business relations and friends still in the business and have managed servers for well over 10 years.

I can tell you pdo is not.

[Aventro]

Having ran a webhost have business relations and friends still in the business and have managed servers for well over 10 years.

I can tell you pdo is not.

Well we can only speak for ourselves, I am however only used with web hosts/servers with pdo extensions available, and I believe yet again, enabling PDO would not harm, as it's (look again) on my link, PHP want to deprecate mysql_ but can't just do it yet due to many still using it. A good question is _ why _ ?

[rulerofzu]

Look at the date of that proposal among the other similiar proposals over the years. Wont happen.

[JakeB]

If you have plans to fork ezRPG, that is fine, but at least don't call it ezRPG as it is clearly not an official update. especially calling it ezRPG version 2..

[Spudinski]

PDO arguments:

Let's presume a user installs ezRPG onto a shared hosting environment.

The odds - between those 10 thousand users hosted - are, that someone needed PDO.

Even if not, any good host would gladly enable it, even if just on a justforyou basis.

I've never run a hosting company, but, all mine goes up and beyond for their customers.

But, if you're gearing towards 1 dollar hosting, forgedaboudit, be glad you have mysql support.

 

If you have plans to fork ezRPG, that is fine, but at least don't call it ezRPG as it is clearly not an official update. especially calling it ezRPG version 2..

I agree.

Using a codename, and only referencing to ezRPG would be much better.

[Aventro]

PDO arguments:

Let's presume a user installs ezRPG onto a shared hosting environment.

The odds - between those 10 thousand users hosted - are, that someone needed PDO.

Even if not, any good host would gladly enable it, even if just on a justforyou basis.

I've never run a hosting company, but, all mine goes up and beyond for their customers.

But, if you're gearing towards 1 dollar hosting, forgedaboudit, be glad you have mysql support.

 

I agree.

Using a codename, and only referencing to ezRPG would be much better.

Well sure. I have a great codename already. After more research I simply agree with Spudinski PDO should be enabled, and if it isn't it should be possible to be enabling it, and if not, well you should consider looking for a new web host.

[Aventro]

About the implementation of the database abstraction layer, I am just thinking freely:

1) We could have as already implemented database settings such as hostname, username, password, database and driver in the configuration files.

2) As there is similar functionality no matter what driver you use it would make sense to just provide a dns in the configuration file, and then just have one database wrapper class?

Does I make any sense, do you guys agree, or how would it else why be implemented.

[a_bertrand]

I wonder how many of you guys will use ezRPG on anything but MySQL as I doubt you will use postgress or oracle or any other DB. So making a complex structure to allow to run with different databases doesn't seems all that useful for this project.

[Nickson]

The database question is actually rather simple to solve while it doesn't require a lot of work actually... read up on database abstraction layers. If you keep that design in mind, you only need to develop say the mysql connector and the wrapper itself. Later, when the time is right or the need is there, you could just add another connector. and support 2 database systems at once without having to touch your code.

Application <-> Database Wrapper <-> Database system

And if that seems to much work, or people are too afraid of losing speed, you could always work with a database object. Design it properly and you could have drop in replacements of various database systems. Just keep in mind that no non-standard queries can be send from the application unless you want to run into trouble somewhere. But if you want to support multiple databases it's certainly possible, and with doing this you have a work around for the pdo dependency ;).

[a_bertrand]

That would be true, if the queries stays the same. However even operations like join, upper or whatever a bit more than a simple select will not be standard across databases. You would then need either to have a query generator or use only things which works across the different db you want to use. That's why I think it's not as simple as simply have a DB class which translate $db->query into mysql_query for example.

[Aventro]

The database question is actually rather simple to solve while it doesn't require a lot of work actually... read up on database abstraction layers. If you keep that design in mind, you only need to develop say the mysql connector and the wrapper itself. Later, when the time is right or the need is there, you could just add another connector. and support 2 database systems at once without having to touch your code.

Application <-> Database Wrapper <-> Database system

And if that seems to much work, or people are too afraid of losing speed, you could always work with a database object. Design it properly and you could have drop in replacements of various database systems. Just keep in mind that no non-standard queries can be send from the application unless you want to run into trouble somewhere. But if you want to support multiple databases it's certainly possible, and with doing this you have a work around for the pdo dependency ;).

 

That would be true, if the queries stays the same. However even operations like join, upper or whatever a bit more than a simple select will not be standard across databases. You would then need either to have a query generator or use only things which works across the different db you want to use. That's why I think it's not as simple as simply have a DB class which translate $db->query into mysql_query for example.

That's why I am thinking off using PDO and just build a wrapper upon it, as PDO already has many drivers available, I would just let the user specify which dsn (driver) he would like to work with, the query and statements are still the same in PDO, then I would basically lay on the functionality I need to make everything easier, such as making the insert() query pass in the data array and then it's done.

[Nickson]

Well correct me if I'm wrong, but isn't PDO a database wrapper on the framework/php level where I suggested an database wrapper on the application layer? Both will have their advantages, to me it doesn't matter that much as I was simply providing an explanation of what I meant.