I've seen it written elsewhere on SO that while the Enterprise Library Validation Application Block is geared towards validating user inputs, Code Contracts are meant to prevent programmer errors. Would you support this opinion? Why?
Yes.
Code contracts are meant to keep a strict programming interface, which only a developer can get right or wrong; a user shouldn't really be able to mess this up.
Validation is meant to validate the data; e.g. verifying data isn't null, or matches a regex.
Code contracts throw exceptions when they are violated. Invalid user input is not an exceptional condition so validation functions should generally not throw exceptions. That's why methods like TryParse were added to the Framework (the original Framework didn't have them, and it made validation cumbersome because of all the possible exceptions).
Code contracts are used to assert things that will always be true, and if they're not true, then there's a bug in the code. That means it can only apply to conditions that are controlled by code. So, you can't use them to state "the user will never supply an empty string", because that's outside of the control of the code. The static verifier will never be able to prove that statement - how can it know what the user will do?
What you can do is make statements like "Given a user input, the method will either return a non-empty string or throw an exception".
Related
I'm using the paginate method of the query builder and I would like to allow the user to choose the number of items per page.
$paginate= Model::paginate($request->input('per_page'));
Doing this could I be opening a loophole for SQL Injection or is this value sanitized first?
You can use a validator to make sure $request->input('per_page') is an integer or whatever validation you want.
documentation here : https://laravel.com/docs/9.x/validation
Such methods must be protected. This is what models are for.
But you are right, it's better to be safe than sorry and verify your premises. This is especially true with popular frameworks, because sometimes the creators crave for simplicity above everything else, often forgetting even security.
But it seems that in this case, Laravel QueryBuilder casts the perPage value to integer, making it immune to SQL injection:
protected function compileOffset(Builder $query, $offset)
{
return 'offset '.(int) $offset;
}
Then I dug a bit into the history, and found that the protection has been added almost a decade ago, so you can be sure that with any supported version of Laravel this part is safe.
That said, validating user input is still a good idea. Even being protected from SQL injections, you don't want any unexpected behavior. I don't think 500000 or -100 are good values whatsoever. If you can see that the data is not valid, it's a good strategy to bail off already, without waiting for some bizarre things to happen. So you may consider validating this input value just like any other input, like good programmers always do.
As far as I can see, the validation within Entity Framework is built entirely around the assumption that, if an item fails its validation, it must not be persisted to the database. Is there any mechanism, possibly running parallel to normal validation, of making a constraint on a field produce a warning to the user, rather than an error which prevents the record from being saved/updated?
To be more specific, I have a situation where a particular numerical field has limits on it, but these are advisory rather than hard-and-fast. If the user enters a value outside these limits, they should get a warning, but should still be able to save the record.
In theory, I could subclass the ValidationResult class to make, say, a ValidationWarning class, then create a custom subclass of ValidationResults whose IsValid property was sensitive to the presence of ValidationWarning messages, and ignored them in deciding whether the entity is valid. However, this requirement has arisen in a project which is already someway along in its development, and it would require a lot of refactoring to make this kind of custom subclassing work properly. I would prefer to find a mechanism which could be levered in without creating that much disruption/rework.
I had a similar requirement on a project and how I solved it was this. If (ModelState.IsValid) is false, I cleared out the errors out of the ModelState and sent it on its way again,then logged the "error" to another service. This is a bit of a hack and I would'nt recommend doing as it is not exactly best practice.
I have been reading about specifications lately and I am really keen on using them. However, I am afraid to overdo it.
For example, if I have a User entity with a phone number property, do I need to put the phone number specification test in the setter, or is the validation logic in the setter enough?
Thanks,
Phil
UPDATE:
For more context:
I think I would like the validation to be in the domain, and not in the presentation. I will implement the validation in presentation, but that will be more of a UI feature. The idea (i believe) is that the domain cannot be in an invalid state, nor can it rely on the presentation. I actually have a phone number Entity, and many entities have phone numbers, though I suppose this could value object, but that is another debate:)
I was just wondering if it overkill to use Specifications in Property setters. One advantage I could see is that Specifications can be shared between layers, ie the Presentation Layer, so that you can share the validation code.
As you can see, I am unsure if this is the right approach.
Much Thanks,
Phil
You might look into the notion of pre and post conditions (invariants or design by contract).
Pre conditions are things that must be true for your function to operate correctly.
Post conditions are things that will be true when your function is complete and exits normally.
"user's phone number valid" is probably a good post condition to have for your setter function. However you have 2 choices for the pre-condition: (1) make it a precondition of your setter function that whatever is passed to it is valid, or (2) make a much looser pre condition to your setter function and perform the error checking in your setter function. Option (1) essentially passes responsibility for validation to the client. Option (2) endows your User entity with the responsibility for error handling.
I think the design you choose would depend on the bigger picture for your specific application.
Here are a few links for invariants and design by contract:
http://svengrand.blogspot.com/2008/11/preconditions-postconditions-invariants.html
http://en.wikibooks.org/wiki/Computer_Programming/Design_by_Contract
I often see people validating domain objects by creating rule objects which take in a delegate to perform the validation. Such as this example": http://www.codeproject.com/KB/cs/DelegateBusinessObjects.aspx
What I don't understand is how is this advantageous to say just making a method?
For example, in that particular article there is a method which creates delegates to check if the string is empty.
But is that not the same as simply having something like:
Bool validate()
{
Result = string.IsNullOrEmpty(name);
}
Why go through the trouble of making an object to hold the rule and defining the rule in a delegate when these rules are context sensitive and will likely not be shared. the exact same can be achieved with methods.
There are several reasons:
SRP - Single Responsibility Principle. An object should not be responsible for its own validation, it has its own responsibility and reasons to exist.
Additionally, when it comes to complex business rules, having them explicitly stated makes validation code easier to write and understand.
Business rules also tend to change quite a lot, more so than other domain objects, so separating them out helps with isolating the changes.
The example you have posted is too simple to benefit from a fully fledged validation object, but it is very handy one systems get large and validation rules become complex.
The obvious example here is a webapp: You fill in a form and click "submit". Some of your data is wrong. What happens?
Something throws an exception. Something (probably higher up) catches the exception and prints it (maybe you only catch UserInputInvalidExceptions, on the assumption that other exceptions should just be logged). You see the first thing that was wrong.
You write a validate() function. It says "no". What do you display to the user?
You write a validate() function which returns (or throws an exception with, or appends to) a list of messages. You display the messages... but wouldn't it be nice to group by field? Or to display it beside the field that was wrong? Do you use a list of tuple or a tuple of lists? How many lines do you want a rule to take up?
Encapsulating rules into an object lets you easily iterate over the rules and return the rules that were broken. You don't have to write boilerplate append-message-to-list code for every rule. You can stick broken rules next to the field that broke them.
What is the point of putting asserts into our code ? What are the benefits of assertive programming ?
private void WriteMessage(string message)
{
Debug.Assert(message != null, "message is null");
File.WriteAllText(FILE_PATH, message);
}
For example we can check the message variable and throw an exception here. Why do I use assert here ? Or is this a wrong example to see benefits of asserts ?
They also support the philosophy of fail fast, explained in this article by Jim Shore.
Where some people would write:
/*
* This can never happen
*/
Its much more practical to write:
assert(i != -1);
I like using asserts because they are easily turned off with a simple compile time constant, or made to do something else like prepare an error report. I don't usually leave assertions turned on (at least, not in the usual way) when releasing something.
Using them has saved me from making very stupid mistakes on other people's computers .. those brave souls who enjoy testing my alpha code. Using them plus tools like valgrind helps to guarantee that I catch something awful before committing it.
An important distinction to consider is what sorts of errors you would like to catch with assertions. I often use assertions to catch programming errors (i.e., calling a method with a null parameter) and a different mechanism to handle validation errors (e.g., passing in a social security number of the wrong length). For the programming error caught with the assertion, I want to fail fast. For the validation error, I want to respond less drastically because it may be normal for there to be errors in the data (e.g. a user doing data entry of some sort). In those cases the proper handling might be to report the error back to the user and continue functioning.
If there is a specified pre-condition for the method to take a non-null message parameter, then you want the program to FAIL as soon as the pre-condition doesn't hold and the source of the bug must then be fixed.
I believe assertions are more important when developing safety-critical software. And certainly you would rather use assertions when the software has been formally specified.
For an excellent discussion of assertions (and many other topics related to code construction), check out Code Complete by Steve McConnel. He devotes an entire chapter to effective use of assertions.
I use them to verify that I have been supplied valid dependent class. for exmaple in constructor DI, you usually are accepting some sort of external class that you are dependent on to provide some action or service.
so you can assert(classRef !- null,"classRef cannot be null"); instead of waiting for you to pass a message to classRef and getting some other exception such as exception : access violation or something equally ambiguous that might not be immediately obvioius from looking at the code.
It is very useful to test our assumptions. The asserts constantly make sure that the invariant holds true. In short it is used for the following purposes,
It allows to implement fail-fast system.
It reduces the error propagation because of side-effects.
It forbids(kind of sanity-check) the system to enter an inconsistent state because of user-data or by subsequent code changes.
Sometimes, I favor the use of assert_return() when we do not want to use try/catch/throw.
private void WriteMessage(string message)
{
assert_return(message != null, "message is null"); // return when false
File.WriteAllText(FILE_PATH, message);
}
I suggest assert_return() to halt the application by reporting an error in test build. And then in the production system, it should log and error and return from the function saying it cannot do that.