UI Validation

[EdwardJS024]

How do you guys handle UI Validation from a broader sense? I have posted about this in "Constraining input data" but needed to post on a more conceptual level.

IMHO, there are 2 kinds of validation that occur in a system,

1. Syntax Validation
2. Business Rules Validation


Syntax rules occur at the UI level to constrain, and limit what data a user can send into the core -- ex: "An input field for 'Age' may only allow numeric data".

Business Rules occur at the core of the domain model and are more concerned with rules of the business -- ex: "Only customers 21 and over are allowed to register for subscription."

At the UI layer, how/what mechanism would you implement for syntax checking if:

1. syntax rules vary across locales
2. must not be repeated, need to be centralized
3. configurable, no recompilation


At the same time, if one was to remove the UI and expose the APP to integration or 3rd party gateways, the UI syntax rules are now breached.

Your comments are appreciated

Edward J. Smith

 

[Polu]

Hello.

You will need a four tiers design instead the now classical three tiers model. Which means:

Tier 1: Database access layer (not discussed here)

Tier 2: Business layer: This is the place for "Only customers 21 and over are allowed to register for subscription" kind of rules

Tier 3: Application layer: This is the place for "An input field for 'Age' may only allow numeric data"

Tier 4: User interface layer: It deals with form design, artwork and so on.

I think you should build your API for 3rd parties as a Tier 4 component; graphically:

----- ------ ------
|API| |UI 1| |UI 2|
----- ------ ------
| | |
----------- | |
|App layer|------------
-----------
|
----------------
|Business layer|
----------------
|
------------
|Data layer|
------------

The app layer should be able to load rules form somewhere (a database, an xml file or whatever). This rules should contain information about for what user/Tier 4 implementation/any-other-relevant-paramenter applies.

If needed (i.e. you need a web UI, a heavy client UI and a "smart client" in PDA's or mobile phones), you should consider to implement several differents App Layers, one for every kind of client. Graphically:

----- -------------- ------------ ----- --------
|API| |Heavy client| |Web client| |PDA| |Mobile|
----- -------------- ------------ ----- --------
| | | | |
|----------- |---- |---------
------------- ------------- -------------
|App layer 1| |App layer 2| |App layer 3|
------------- ------------- -------------
| | |
---------------- | |
|Business layer|-----------------------
----------------
|
------------
|Data layer|
------------

Hope it helps!

Polu.

 

[Polu]

The ASCII diagrams are not well displayed; you should cut and paste them into notepad.exe to see them properly.

 

[EdwardJS024]

Polu,
great explanation on the concept of layering. I got that pretty much etched into my principals.

As for validation, this is a topic not frequently spoken of when related to a 4-tier architecture.

So youre saying that data/input validation should occur at the App level. I agree. That means the app is not focused on the business rules, instead that is solidified by the core domain.

Do you see any loop holes in that design where a client could potentially take a back door approach and send data not validated to a domain entity, hence violating the integrity of the system?

My Point is, should there be some form of layered validation where data is validated all the way down to the persistence level?

 

[Polu]

Hello.

Not sure if I understand you correctly, but I don't think that security issues should be oriented to data validation.
Security effort should be oriented to identification of users and managing rigths for users/groups of users.

I mean, a user will type his user/password pair and he will be validated and allowed to perform some actions while other actions will be forbidden.

May be are you thinking in expose all layers? This should *NOT* be done:

Deeping in the example of my previous post:

1. Through the API: The user should validate himself by calling LogIntoSystem(User as String, Password as String). If he tries to call any other method without having been validated, he will receive a return code indicating that he is not logged in and no action will be performed. If he is logged but his user has no rigths, again he will receive a return code indicating the situation and no action will be performed.

2. Through the heavy client: User will be prompted with a login screen. He will access the application only if correctly logged in. If he has no rigths for an action, this action will not be present/will not be enabled in the GUI (GUI dinamically generated based on the user rigths)

=> In both cases I am exposing only the UI layer.

3. Through Web client: User will be prompted with a login screen. He will access the application only if correctly logged in. If he has no rigths for an action, this action will not be present/will not be enabled in the GUI (GUI dinamically generated based on the user rigths)

=> In this case, App layer is exposed (Lets suppose it is a servlet). App layer should be protected using standard criptography (PKI, X.501, etc)or even custom criptography (i.e. embbeding an ActiveX in your web page and using it to cypher yor data before send it to the server)

4. and 5. Through PDA and Mobile clients: This kind of devices often work in disconnected mode. So, App layer should be implemented in the client side. Let's suppose that we expose our business logic layer using a set of web services. When the PDA connects to the server, it should log into the server using a user/password pair and the same criptography methods apply.

=> In this cases, I am exposing the business layer. This is the most conflictive scenario since a hacker could send non validated data. If needed, you could replicate the App layer, having a client side App layer and a server side App layer (If you replicate the app layer you are not exposing the business layer anymore so this will be the same as in 3.), but IMHO this does not worth the while for a majority of the systems.

So, we have visited three scenarios:

+ UI layer is exposed: No problem since data will be always validated in the App layer

+ App layer is exposed: No problem since data will be always validated in the App layer

+ Business layer is exposed: Problems could arise; however, if your security is broken, bad data types will be the minor of your problems so I think that replicating the App layer in the server does not worth the while.

In conclusion:

=> Expose as least layers as you can.
=> Expose the top most layer that you can
=> If needed, replicate App layer in the server althoug IMHO it does not worth the while.

Of course you can think in other scenarios as exposing the app layer for a heavy client as DCOM services or whatever but I think all these alternative scenarios are easily translated to the three basic scenarios I mentioned.

I don't know if I have missed the point of your post. English is a foreign language for me so please, excuse any mistakes.

Hope this will be helpful!

Polu.

 

[grooke]

I'm a little lost in much of the above detail, so what I say may cut accross some of it. There are clearly many aspects I agree with.
There are four layers of validation required:
Character Level: Alphas where only numerics are acceptable etc. They are just part of field level validation.
Field Level:- Age < 16 etc. These can be tested in the UI (client) or on the server side.
Form Level:- Maiden Name required if married female etc. Again these can be client or server side: client side needs rules and data, server side is a bit slower (thick/thin client and all that).
System Level:- That Bank Account is NOT a savings account. etc. These can only be carried out on the server side.

The possible server side Levels map nicely into OO classes.
Field Level -> Constraint on an attribute in a class
Form Level -> Constraint on the class, checking some link between attributes
System Level -> three different types:
Pre-condition on a method:- is status correct etc.
Post-Condition on a method:- did it perform the correct algorithm
Contraint on an Association:- you can only borrow a maximum of four books from the library.

All the functional business rules MUST belong to one of these five cases or a use case description.

Now, take the n-tiered (more than the old fashioned 2 or 3 layers) architecture, and assume checking is done on the server side.
UI may need data for the form and may return data to it. This is normally provided as a Data Transfer Object or DTO. Mostly this will look like one of the business class with a few differences:
Not all attributes will be included,
Some other classes may have been 'joined',
Inheritance classes will have been flattened, because most remot UI APIs cant handle items more complex than 2D arrays.

In a Web system, this DTO is used to create a page of HTML; using either JSP, ASP or similar. In an on-line application the DTO is used either by the Swing, VB etc. Both systems have callbacks or other methods of detecting the arrival of some user input. By then, any client-side checking will have been completed client side checking allows immediate feedback at the field level if necessary.

The next few tiers or sub-tiers deal with security, session management, transaction control etc. These may produce errors to be reported using the mechanism described below.

At the bottom of this heap is the lowest level Application Controller. This more or less reflects the steps you wrote in the use case. Its job is to call the Business Objects as outlined in the sequence diagram. Again, it may find errors in its own right, but mostly, it will just pick up errors from the Business Classes. This is where the constraints listed above are used for validation.

Now we need to get the errors found back to the UI. Getting them back to the Application Controller can be done as you like; exceptions or error classes are fine. in the Application Layer, they need to be packaged up into reader friendly reports. To do this, the common method is to create and error page (panel) which is either displayed on its own ot at the top or bottom of the original form. This of course is done by the JSP,ASP, VB, Swing or whatever.

Finally, you need to think about client side validation.
The standard approach is to ensure that all validation is done server-side, because
you dont have 100% control of some clients
they may be language specific (as you say)
you may want to swap the UI software from Swing to JSP or JSP to Flash etc
all the constraints are in well defined places in the use cases and on the classes, and can more easily be made reliable, tested etc.
marshalling of all errors found are more easily found because you can use exceptions etc
However there can often be big improvements in performance if they can be done on the client side. A common approach is to duplicate the tests on the client side. In this case, it is only necessary to have the most common ones done on the client side, because a complete check will be made on the server side.

Gil