mORMot Open Source

ws

Member

Registered: 2015-03-17

Posts: 19

Server Side Validation

The TSQLServerRest class, already had the ServerSideValidate property, if yes, why was excluded?

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,240

Website

Re: Server Side Validation

I do not understand what you mean, sorry.

ws

Member

Registered: 2015-03-17

Posts: 19

Re: Server Side Validation

sorry, I'll try again.

this link "http://synopse.info/forum/viewtopic.php?id=1500" has a reference to this property.

TSQLServerRest.ServerSideValidate := true;

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,240

Website

Re: Server Side Validation

This patch has never been integrated into the main source code.
AFAIR it was just a trial from one mORMot user: proper integration would require much more work, and would slow down the whole process.

The validation should be done at business level, not at ORM/REST level.
At ORM/REST level, the framework works with "pure" JSON content, with no temporary conversion to a TSQLRecord instance.
It is able to directly create the SQL from the JSON, for best speed.
So validation should be done on client side, before sending the data to the server.

ws

Member

Registered: 2015-03-17

Posts: 19

Re: Server Side Validation

Thanks ab!

jonjbar

Member

Registered: 2012-12-27

Posts: 23

Re: Server Side Validation

So validation should be done on client side, before sending the data to the server.

Clients must never be trusted!

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,240

Website

Re: Server Side Validation

REST clients should be trusted, otherwise you may introduce unexpected business logic within resource access.
See http://stackoverflow.com/a/16461863

It is similar to the concern of putting the business logic within a SQL database using triggers, or only relying on table definition ("foreign key").
Definitively not a good approach.
The persistence details should be abstracted from the logic.

Basic security is available in the framework, to access a REST resource, i.e. a table, for Read or Write operations.
See http://synopse.info/files/html/Synopse% … #TITLE_488

In application layer is where your business logic should reside.
In application layer is where validation should take place.

jonjbar

Member

Registered: 2012-12-27

Posts: 23

Re: Server Side Validation

IMHO any kind of clients (REST included) must be put on a leash as there are plenty of bad things they could do which they shouldn't be allowed to. From the top of my head, I can think about:
- Access resources (rows/fields) without proper permission
- Delete/Update resources without proper permission
- Send invalid data which could result in either data corruption or server crash
- Send malformed (string instead of int, data is too long...) or missing data (required field) which could lead to future problems (data analysis, report generation...)

Where it should be done is another question which should be carefully thought out:
- Invalid access permissions should be checked (at the very least) before returning data to the client. If not before accessing data in the persistence storage
- Invalid modification access should be checked before modifying the persistence storage
- Invalid formated data or missing data should be checked before modifying the persistence storage
- Invalid data resulting in server crash should be handled as soon as it is received (e.g data flood, invalid characters, invalid requests...)
- Invalid data resulting in data corruption should be handled before writing to persistence storage

Regarding table access security, this is great but not enough for most systems: row-level and even field-level security and validation should be handled from the server.
I admit I do not know mORMot enough to say that it is not possible to do so or that it should handle everything.
But as far as I can tell mORMot includes both the data persistence access and REST server with direct interactions between them so it should provide a way to interfere and add safe guards between both.

I hope you'll see those remarks as constructive, not critics