Spudinski

Uhm, you said you guys didn't have a date to release V1 to open source until recently? There *should* be a period specified, at least a month, after which it's released for free. A step like "just releasing" V1 to open source is highly unethical. Seker, and everybody else that purchased V1 within a one month period before it was released needs to get a refund. Or if you guys prefer, maybe all MCCodes versions can be open source'd? It not fair paying for a license for something which is released for free in under about three months. A (software) life expectancy needs to be given in order to avoid fuckups like with Seker. If it was a side project, like openSuSe or Fedora it would be appropriate. Unfortunately this particular case isn't at all justified.

In no offensive manner possible: This has been suggested since last year.

+1 http://www.symfony-project.org/

While you're mentioning frameworks, why don't you take a look at a "real" framework like Symphony   P.S.: That's because you're a Microsoft guy.

I found myself saying "Oh no" at every line of code I read. This is the wrong approach to dealing with JavaScript in an application. JavaScript events should not be abstracted like this, at all... When dealing with Ajax, an **interface** should be created, not an abstraction layer. JavaScript is *object* orientated, unlike C++ or PHP which are actually class-orientated. PHP is unable to deal with JavaScript objects, events and methods, and visa versa for JavaScript as well. Furthermore, "registering"(?) a *PHP* function to be used in *JavaScript* and then allowing "JavaScript" to be passed to a "PHP" function to be generated? Seems diabolical. Seeing as you've practically rolled this out in a bit under a week, something tells me that you didn't think this through properly.

Well, since you're going on about "complex" queries... There's a very simple way I've seen this being solved. Take for example: $query = array( 'select' => 'CONCAT(), IFNULL(), somewhere.something AS some', 'from' => 'blah bl LEFT JOIN blah () as blah CROSS JOIN as b', 'where' => 'some LIKE \'bla%\'' ); In it's simplest form, you pass the array to the database abstraction layer and each driver will interpret the query as needed. I've created many "complex" queries this way, as it's also useful for switching where clauses and filters.

I'm not keen on advertising in any form on any of my websites. I wouldn't discourage other websites, but links to other websites will need to be given off of the website. Additionally, I've had a case or two where I am held liable for any/all content produced from my website. Thus, I never allow outbound links, without notification.

lol @ the misspelled domain.

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.

I can register any domain, even "this-aint.gonnawork.out". I normally setup internal DNS to my initials though(SO). Back to the point, that is still a lot for those domains. I'd suggest you post some traffic stats, or lower the price by about 3/4.

Depends weather you're talking about the PHPSESID... If so, yes, it is really going to affect everyone. A stupid example is when they bookmark that page, when they reload the website from that bookmark with the SESID appended, it would force a re-login(depending on what one has implemented). If you do CSRF, it needs to be done communally. Here's an example in lay man's terms(just because I'm lazy): The user visits the site, - A session_id is generated - The session_id is stored via use of a hashing algorithm along with an identifiable ID of the user. The user visits again, - The cookie previously generated is now retrieved. - PHP's session relating to that user is compared the the hash generated before. + If it matches, create a new session ID. + If not, automatically delete the data and initiate a new session. Now, if user B tries to use user A's session: - The cookie is validated to the session_id PHP holds for this user. + If it matches, it's deemed that everything is in order. + If not, it's deemed that this is not the same user as before. * This can also mean the user has had 15 minutes(depending on session.max_lifetime) of inactivity, and would need to re-login. Note: the above is an example, do not actually use/build a system based on this. It's a very basic example, but it set sight to my point if I'm correct.

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

We know... you created this topic today..

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

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

I'll fork it. :P

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.

From a design point of view, 4. For historically correct, it's actually 5.

Well, ok. It's like having a Prison then. You lock up the whole place, but the thing you don't bargain for is the guests. You put up bars and cells up to keep certain people at bay, but they all still get fucked. And that's all people that you do know.

Yea, but that's like replacing all the windows in a house with solid blocks of steel, just for "extra" security.

'twas a compliment. PS. Stop saying "we". You did not create ezRPG, Zeggy did.

As I've said, there's no need for it in ezRPG.

Well, your method is indeed valid. But your only index would be at 0, or "COUNT(`id`)" when pulled using mysql_fetch_*.

Whilst introducing AS, for associative arrays..   $result1 = mysql_query("SELECT COUNT(`id`) AS `totalUsers` FROM `grpgusers` WHERE `exp` < limit_to_level_5_exp_as_int");

Your articles, while amusing that you would post them, are not of importance to me. Furthermore, the "frameworks" (with the exception being IP.x) are all just that, frameworks. They are built to suit most, if not every, scenario possible. It would be rather annoying not to have the functionality when needed. CSRF has many aspects to it, and doesn't just fall at risk on the application layer. That being said, one would wonder why protocols on the session layer wouldn't fall under suspicion to this as well. Actually they do as well, it's just different methods employed. But, some protocols are designed "around" this. Applications can also be designed "around" this issue - a simple example is to use only SESSIONs, with a minor alteration or two to PHP's configuration file. I'm confident that you understand the concepts of CSRF, but how it is carried out requires deeper knowledge about the relationship between multiple applications on a system. I'd be more than willing to explain further, if need be.