Re: removing last chrs (with different browsers giving different last chrs )

Gregor Kofler wrote:
Jerry Stuckle meinte:
Gregor Kofler wrote:

Well, the is_this_an_integer_regex is not *that* hard to understand. The one for the email or URIs is another chapter, but there are hardly any alternatives.


Not to YOU is isn't - but to someone unfamiliar with regex's, it is quite complicated.

Hey, it's *my* framework. If I have to share it (it's reasonably documentented, but I wrote it for me), then he/she can resort to Rex::INT_EXCL_ZERO or whatever. Regular expressions are an important component in most contemporary programming languages. If someone is either not willing or not capable of understanding _basic_ regular expressions, he/she shouldn't be a programmer in the first place.


And you are the only person who will ever look at it? You never installed it on a client's machine, for instance, and they might change programmers?

NEVER assume you will be the only person to ever look at something!

Yes, I agree ones for email or URIs have little recourse, but there are lots of options for numeric values which are faster and easier to understand.

In my approach it looks this way:
private $allowed_parameters = array(
'id' => Rex::INT_EXCL_ZERO,
'name' => Rex::TEXT_NOT_EMPTY,
'category' => array('foo', 'bar', 'baz')
);
(There is this other option: an enumeration with discrete values; find that nicer than: /^(foo|bar|baz)$/ - but both yield the same result.
And what's so difficult to understand about that?


It uses constants from a class - to find out what's going on, the user will have to find the documentation for that class and decipher the constants.

Not the easiest thing to do always.

Sure. I loop through all fields that need validation, apply the prviously assigned appropriate "rule" and fill an array with all errors encountered. Of course you need an if statement (or ternary operator) to do that.


So, what's the difference? You're the one complaining about 'if' statements.

Sigh.

You need:
<loop>
switch ($type):
case 'int':
if(...) {
$error = ...;
}
break;
case 'text':
if(...) {
$error = ...;
}
break;
case 'other':
if(...) {
$error = ...;
}
break;
</loop>

I need (taking into account that I allow regex and enums with arrays):
<loop>
if($type = 'regex') {
if(...) {
$error = ...;
}
}
else {
if(...) {
$error = ...;
}
}
</loop>


You're assuming a lot. No, I don't.

First of all, I don't have one function which tries to validate everything. For instance, if I want to validate an integer between 1 and 5, I will use something like:

$emsg = array();

$val1 = trim($_POST['val1']]);
if (strval(intval($val1)) != $val1)
$emsg [] = 'Value 1 is not a valid number';

This ensures the value is an integer and puts out a meaningful error message if it isn't.

Sure. These additional rules are "special", as I said: admin emails, dependencies of dates, etc. For most bog standard forms I don't need that though. I should also mention, that proper escaping of each and every data before db manipulation is done by the db class.


You're the one complaining about 'if' statements. I'm just bringing up the fact you aren't saving anything.

Again: YMMV. My scripts are short and concise. And - since some of the projects get maintained by others, too - obviously not that hard to understand. Those "special checks" are - as the name indicates - not needed regularly.


Mine are, also - and they are easy to understand.

Then I'd provide a (boolean) database field "display", which will allow him to add categories and (de-)activate them at will. Anyway, where is the problem? In this scenario, a faker could add something to a category that exists, but won't be displayed anyway...


That's one way - but again, it means adding another column, fetching it from the database every time, just for the few times it's not required.

And this point I resort to "YMMV". There are situations where my solution is not the most efficient or the most convenient one.

Quite true. I don't add unnecessary things to the database. It just confuses the situation.

Yes, but *if* there can be categories in existence, that are not visible, but otherwise perfectly valid I would model this into the database.


It's not always necessary (or desired) to have everything in the database.

The original requirements might have been for 5 categories because that's all the owner ever considered having. But now he wants to add one more item. You have a choice - change two or three pages which use that category, or dozens of pages which access that table.

Now if this is something which will change regularly, then I probably would. But then I would also build the list from the database. However, if the categories are stable, then no, I probably wouldn't.

Agreed. Though I seriously doubt that one or two extra queries will have that much of an impact. Poorly designed, badly normalized, wrongly indexed databases are much more of a culprit.


"You doubt". But have nothing to back that up except your opinion. A lot of factors are involved - and while ONE item may not seem like much - this could easily expand into DOZENS of additional columns (and even a few extra tables).

Good design is also about what NOT to put in a database.

Where did you read about "system error message" in my answer? It will display something like "Your request could not be processed, due to an internal problem. Please retry in a few minutes or inform the administrator." Parse that into something exploitable. But something like my "Dude you gave category 6, but I offered you only 1 to 5!" - come on, the "normal" user won't create such an error, only the one trying to compromise the page. And now this one knows, that I explicitly check the category ids. Not a valuable information, but at least some information.


Wow - that's really a helpful message. What do you think your users think when they see that?

(a) What should I tell them? That's the truth. The database has a serious (internal) problem. Give it a rest and try again. They will hardly ever see that. (In fact I'm pretty sure, that on all the webpages I've done so far, no one ever came across it, i.e. the db always responded properly.)


If a field is in error, you should tell them that field is in error.

Am I really so hard to understand, or do you do that deliberately?
Once I deliver a perfectly valid query to the db and the db tells me something like "MySQL went away", what am I supposed to tell the user?


Which is entirely different from not validating a field. What don't YOU understand? Or are you just trying to change the subject because you don't have a response?

There is nothing wrong with the database; rather you aren't properly validating the user input.

Bollocks! I am *always* validating the user input properly and give proper feedback, as long as we have a "proper user". This "proper user" will find it impossible to choose a category that raises a foreign key violation. The one who doesn't is the bot. And this one doesn't deserve a meaningful error message.


Not from what I'm seeing. Never assume a "proper user". ALWAYS assume an "improper user".

(b) Why should I care? It's a bot trying to breach my system.

Maybe, maybe not.

Don't be cryptic! Give me a nice example, of how a "normal user" with a "normal form" equipped only with technically sound options could create a corrupt POST request.

Gregor



A bug in your page; some who has an old version of the page cached or accesses it via cached pages in google. Some accessing the page (validly) via cURL functions. A bug in the browser.

The list goes on and on. Just because you have an invalid value in a field does NOT mean you have a bot attempting to hack your system!

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@xxxxxxxxxxxxx
==================
.

Relevant Pages

  • Re: Size matters to some
    ... The underlying remote database connection ... physical layer is actually managing it all, the logical layer is forced to ... constraints as specified by developers. ... want to validate the information getting written. ...
    (comp.databases.pick)
  • Re: removing last chrs (with different browsers giving different last chrs )
    ... prviously assigned appropriate "rule" and fill an array with all errors encountered. ... that proper escaping of each and every data before db manipulation is done by the db class. ... but otherwise perfectly valid I would model this into the database. ... This "proper user" will find it impossible to choose a category that raises a foreign key violation. ...
    (comp.lang.php)
  • Re: Please help: Numeric class properties
    ... > that reflects a table in my database. ... I wish to validate the property values before writing them ... TextBox entry BEFORE you attempt to assign it anywhere? ... Function IsDigitsOnly(Value As String) As Boolean ...
    (microsoft.public.vb.general.discussion)
  • Re: OOP database tables <-> php interface (semi LONG)
    ... So potentially in a table with 25 columns I can have 25 getXXX and 25 setXXX methods, database related methods, etc. ... Thus I'm declaring one generic fieldSpecs array that provides properties for the fields so that the generic getters and setters as well as the generic Validator will take care of the rest. ... now how are you going to validate the entry? ...
    (comp.lang.php)
  • Re: ldb File and Sharing Violations (server Speed Issue?)
    ... We are intermittently receiving either of the following two messages: ... the database actually DOES reflect the proper data when ... >> We are migrating some asp based apps that use MS Access for the back end ... >> database and the error messages are wrong. ...
    (microsoft.public.inetserver.asp.db)
Loading