Re: removing last chrs (with different browsers giving different last chrs )
- From: Jerry Stuckle <jstucklex@xxxxxxxxxxxxx>
- Date: Fri, 31 Jul 2009 10:19:33 -0400
Gregor Kofler wrote:
Jerry Stuckle meinte:Gregor Kofler wrote:
That's what my first regexp does (excluding 0, which will hardly ever be a primary key). I normally stick to regexp even if is_numeric() or type casting would also suffice, since the regexp engine is needed anyway, and I've set up a collection of frequently needed expressions as class constants.
0 could very well be a primary key. And a regex is way overkill for this. Something like $i = strval(intval($i)) (assuming, of course, you have trim()med the white space).
0 can be a primary key, true. But an integer primary key sounds very like "autoincrement", hence no 0 (or is there a RDBMS that starts autoincrements with 0?). Alas, I have also a Rex::INT, which allows 0, too, at hand.
Maybe, maybe not. Many databases don't have auto_increment values at all - it's not part of the SQL standard, after all. In fact, MySQL is one of the few which do have an auto_increment value.
I seriously doubt that a regex is overkill - in my scenario, or rather my very own framework I use. The regex engine is frequently needed anyway for checking other parameters (URIs, emails, etc.). So the engine is already up and running. It /might/ be noticably slower when doing 10,000 checks, but how realistic is that? Your bunch of stacked functions will also need extra switch- or if-statements.
Regexes are nice - but they are very slow to process. For simple things like this, they are a complete waste of CPU. They are also hard for a newer programmer to understand; when it comes to choice, I always code for simplicity.
As for extra switch or if statements - your regexes don't get rid of that requirement if you are properly validating your input.
Depends. One could of course fake a wrong category ID (valid 0 .. 5), and send a 6. In this case foreign key integrity would be violated (after all we are using a "real" relational database engine, do we?). Nothing is written into the database, just an error message in my database log. Since the overall result of the save process gets evaluated, the client would get a "generic" message like ("unable to save your input. Try again or...").
That's why you should validate items within a restricted set are actually part of that restricted set. You should not depend on the database to do it for you - for instance, what happens if someone adds category 6 for testing?
Yes. Then category 6 will be a valid foreign key and the db entry created. Keep in mind, that we are talking about a situation where somebody or -thing deliberately fakes submitted parameters to breach into the system.
Which is still a good possibility, with the scenario I gave. For instance, the customer is getting ready to add a new category of things, but not ready to announce it yet. Update the database, (with category 6) get everything ready to go and when you're ready (but not before!), change the web pages for the new category id.
And detecting it early will allow you to send a meaningful message to the user exactly what is wrong.
I can't follow. What "meaningful" message? "Sorry dude, you faked a category 6, but I offered you only 1..5. Try again!" I offer only valid categories in the first run - if he fakes, why should I reward him (or the bot) with a meaningful message? A generic "database error" message always makes sense, since the db *can* have a problem beyond the submitted queries and the PHP realm. A detailled error message is precisely the wrong thing in this case - it won't help the user, the developer has his or her own sources, but the evil bot will feast on that.
Gregor
Something along those lines, yes. Most people have no idea what your "generic database error" means - and it provides information on the internal setup of your site, which could provide further clues for hackers on how to get in. In fact, you should NEVER be displaying system error messages to the user. Rather, you should have your own messages which are meaningful.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@xxxxxxxxxxxxx
==================
.
- Follow-Ups:
- Re: removing last chrs (with different browsers giving different last chrs )
- From: Gregor Kofler
- Re: removing last chrs (with different browsers giving different last chrs )
- References:
- removing last chrs (with different browsers giving different last chrs )
- From: Geoff Cox
- Re: removing last chrs (with different browsers giving different last chrs )
- From: "Álvaro G. Vicario"
- Re: removing last chrs (with different browsers giving different last chrs )
- From: Geoff Cox
- Re: removing last chrs (with different browsers giving different last chrs )
- From: Gregor Kofler
- Re: removing last chrs (with different browsers giving different last chrs )
- From: Geoff Cox
- Re: removing last chrs (with different browsers giving different last chrs )
- From: Gregor Kofler
- Re: removing last chrs (with different browsers giving different last chrs )
- From: Geoff Cox
- Re: removing last chrs (with different browsers giving different last chrs )
- From: Gregor Kofler
- Re: removing last chrs (with different browsers giving different last chrs )
- From: Jerry Stuckle
- Re: removing last chrs (with different browsers giving different last chrs )
- From: Gregor Kofler
- Re: removing last chrs (with different browsers giving different last chrs )
- From: Jerry Stuckle
- Re: removing last chrs (with different browsers giving different last chrs )
- From: Gregor Kofler
- removing last chrs (with different browsers giving different last chrs )
- Prev by Date: Re: removing last chrs (with different browsers giving different last chrs )
- Next by Date: Re: removing last chrs (with different browsers giving different last chrs )
- Previous by thread: Re: removing last chrs (with different browsers giving different last chrs )
- Next by thread: Re: removing last chrs (with different browsers giving different last chrs )
- Index(es):
Relevant Pages
|