Octarine

$_GET['ID'] = abs((int)$_GET['ID']) is .. for want of a better turn of phrase .. utter madness 1. the resulting $_GET['ID'] might not be an integer contrary to what appears in the code 2. making an implicit assumption about the sign of incoming data 3. Not even bothering to perform type checking which may lead to unwanted information disclosure 4. Clamping the data unnecessarily It is far better to test for the existence of the ID parameter; check its type (anything other than a string you can "400" the user), then check the contents of the (string) value without coercing or casting it first is within some form of acceptable limits, and finally - though at this stage no longer important, casting it to an integer value prior to using it in a query.

[OT] Access controls provided by AuthName and AuthType directives need directives such as AuthUserFile and AuthGroupFile in order to work correctly. And why support authentication for a file you don't need access to anyway? <Files ...> or <FilesMatch ...> Order Deny, Allow Deny From All </Files...> would suffice no?

Assuming a small Mccodes game, you ideally only want SELECT, INSERT, UPDATE and DELETE privileges for the game user; the lack of DROP privileges is easy enough to work around. Larger games will probably need other permission sets or multiple (mysql) users. You can protect files easily enough by moving them outside of the document root - for example - However that in turn raises a whole host of other permission related problems and frankly I'm not overly sure what benefit there would be over a .htaccess file with a simple <Files ...>...</Files> block outside of keeping the public_html (or whatever it is called on your hosting platform) clean. (A lot of people still hide their cron jobs in long/winded/folder/names in an attempt to hide them rather than using this method - why, I've no idea) As for spotting problem areas; decent logs help; your web server's own logs can be a start though they seldom provide sufficient information; ie: they don't log POST parameters or X_HTTP_xxx variables both of which are susceptible to common tricks. Knowing what is happening to you is the key to tracking down the problem itself; then understanding how the problem arose in the first case and either learning how to patch it yourself or employing somebody with necessary skills to patch it for you.

DROP is also required IIRC due to the TRUNCATE statement in the day cron. - A marginally safer alternative would be wise; ie DELETE with no WHERE clause.

Why a check and perform two queries? That's just asking for trouble. You can perform the check and the two UPDATES in one simple statement.

Sessions would help here; for example...

parse_url() would seem handy; Something akin to this perhaps ?   [Edit] My bad; didn't read the OP correctly; still - may prove useful elsewhere

Users in an ideal world need only identify themselves by something unique; commonly their username or email address; therefore surely the password entry and/or password storage scheme has no bearing on the actual game itself. No matter what you do, people are going to be looking at the game, not how securely you've designed your password system - and any revenue is equally going to be generated from the game itself, not the security system. Hashing the password against a short-lifetime server-generated token prior to POST'ing back would seem a decent solution with a fallback to plain-text for non-js users (which shouldn't be a problem given the fact its a game). HTTPS can be added if you think it will help but somehow I doubt its addition would result in more revenue.

Irrelevant .. but isn't it "testimonials" rather than "testemonials"

Neat .

Simply put, the inventory table structure is poorly designed; the primary key should ideally be inv_userid + inv_itemid; which means you can drop the inv_id field all together. Now; having simplified the table structure to user, item and quantity; things become a lost easier. As it stands, there is a possibility of the user donating the items having their inventory altered by either themselves or somebody else during the function I posted up, which is why the check is made upon delete. ie: function call is made SELECT statement issued to read the donating user's inventory $rows fully populated donating user buys 1000 of item X function loops over $rows making the adjustments as required ... end of function You could question the validity of this, after all the function call has been issued, but this is a simple example; there are far more complex examples - one in particular being the item/crystal market which is (or at least was) abusable with careful timing. Careful design of the table structure itself would prevent this problem from ever arising and certainly do away with the utter madness that is SELECT+UPDATE+INSERT(sometimes) in the current item_add() function. With your problem, I think a single query would be sufficient with the simplified inventory table structure - and thus no chance of misplacing items or having multiple rows containing the same item in your inventory.

Something like this perhaps ?

So I'm guessing this isn't going to happen then; and I was so looking forward to bugfixing the bugfixes that have been mangled after I submitted bugfixes to the bug tracker... :D

You asked. Sorry, was I meant to soften the blow or blow candy up your ass? I assumed when you asked for an opinion, you wanted an honest one; yes, you may well have just started with photoshop - but surely a forum is presented with html and css. The content of a forum is what at the end of the day makes it, though first looks will play a large part in whether people sign up. Try designing it with html and css only; use one of the color designers in triadic or tetradic mode; ie Color Scheme Designer (random #anchor to show the effect of a tetradic scheme)

Outside of the foul colors (though the background I could almost like), it's a forum; an area for sharing thoughts, points of view, meeting and greeting people, so why have you got a usable forum (vertical) area of only 336 pixels out of 753? That's less than half of your screen real estate taken up with static and/or mostly irrelevant junk? TBF, it's not just your layout at fault; look at the most of the current forum software and even well known forums like *ahem* MWG - they often do the same - massive headers, pointless footers; the key component surely is the topics and discussions therein. Yes, I know there are only 3 forums presented on that screenie; however no matter how you look at it - the top 152 pixels are essentially irrelevant (though I'd always accept some form of global navigation bar ~30-40 odd pixels high seems to be good). Some examples - not saying these are any good, simply here for comparison * Burning Board -- Used to be a great favorite of mine * MyBB -- Looks nice but jees, how far down is that first forum? * XenForo -- Gathering support apparently There are many more, but I assume you are aiming for the PHP market (software wise) and those are about the best looker's I can source quickly of the top of my head. [Edit] Extra poll option * Yeuch [X]

That's strange then; I've never known grpg mix broken insecure files from mccodes. Would seem rather risky especially as they actually interact with our grpg files. Still; your game; I've no doubt there is some good reason for it. [Edit] A quick look at the GRPG sources; nope - there is definitely no files named as such; but whatever you choose to call your sources; its apparent that at least one mccode file is present, and actively querying the database in a matter which could be consider somewhat risky. As for being made by you - sorry, I doubt it in this particular file's case; I spent a lot of time working on it a while back, I know more than most how it can be used and abused. A fix was made available to the developers who partially corrected the original though yours is certainly a little older than the one that has been patched. If you had written it yourself; you would have corrected at least one of the glaring errors it exhibits.

It's fairly obvious it's a basic mccode's setup with a few renamed files - obvious why? because it exhibits the same flaws that most out-of-the-box mccodes setups have - and even has some legacy files kicking around that to this day have never been properly cleaned up. So testing simply becomes a case of looking at the standard bugs that exist in any 2.0+ edition. Start with the basics; look at your login form; there is enough at fault there to write a somewhat lengthy article; but I'll refrain. Missing type checking is rife throughout which is a common fault; I'm not going to bother to probe the more interesting aspects; there's too much work in my opinion needed for it to be called beta.

'cept, it's not actually a language. MySQL is a database system that uses SQL, however you can with a bit of fiddling also access key/values directly thereby doing away with the key aspect of SQL (and thus the notion of the language) itself. Relatively easy? perhaps - but in comparison to what? Whether you choose it, PostgreSQL, SQL Server or any number of KV storage mechanisms is dependant on what you want do. However given the OP's intent; picking up an existing product and slowly learning from it rather than the more difficult route of learning multiple languages and environments in parallel would seem a far wiser course of action.

Maybe this is clearer. I'm sure you can figure out how to do this from PHP. What is different between this and your code? What makes this work and your code ... not work?

css styles

The best way I can think of to explain is: you don't ask somebody "where"... you ask them "where ... something is"; ie you clarify the statement. If you simply ask "where", then the chances are you will get an answer but it is highly unlikely to be the answer you want; the same holds true for SQL. Be explicit.

I can still see all manner of problems; you are still not addressing the WHERE clause. Take for instance this example. The WHERE clause and associated direction (ASC/DESC) does not in fact return the last row as CavellA alluded to; you would need a LIMIT statement for that as shown. You could also search for a particular `id` (... WHERE `id` = $some_value); in fact, as far as I can this would seem the more sane approach. The order by and limit statement would become redundant then of course. BTW; the WHERE clause in that example is itself redundant - as I suspect it is in your code; WHERE `field`; will return every row for a non-zero (or non NULL) `field` value.

SELECT 0; -- > 0 (obvious) SELECT 1; -- > 1 (-- " --) SELECT 0 AND 0; -- > 0 (boolean AND operation) SELECT 0 AND 1; -- > 0 ( -- " -- ) SELECT 1 AND 0; -- > 0 ( -- " -- ) SELECT 1 AND 1; -- > 1 ( -- " -- )   So... Again I say consider your WHERE clause. If you were to look at the results (using *your* data) of the following operation: SELECT `id` FROM `qotd`; SELECT `question` FROM `qotd`; SELECT `correct` FROM `qotd`; and think about how those values are being interpreted in your WHERE clause...

Consider the statement: SELECT 1 AND '' AND '' Now examine your WHERE clause; what is it doing?

What's the problem ? FTP is perfectly acceptable for any number of solutions, including but by no means limited to well known blogging software and forums; why should it not be suitable here? Just because your password is transmitted in clear-text does not mean that someone is sniffing your data-stream. The very fact that you logged on here to post without the use of SSL (which itself is highly suspect) means you are obviously not overly concerned by this or make the assumption that your password (at least here) is at best difficult to guess. While I don't agree with the actual mechanism, I can see that it may well suit a number of people; it's a simple clean solution which requires very little prior knowledge to run and is "safe enough" given the task at hand.