• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Input Validation

 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,
In the assignement there is no word that we must provide input validation. So, I have not done.
However I 've seen that a lot of your have done it. Why do you do it? Where do U make validation: on the client or on the server?
If on the client do you provide new method in interface (e.g. getFieldLength() and getFieldFormat()) or U just hard code it?
Thankx,
Vlad
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why do you do it?
So that when the user types in "-5" or "abc" in the field where a positive integer is expected, the program doesn't crash with some NumberFormatException. This is called a "monkey test". There may be good arguments to do the validation on the client or the server side, but you certainly need to do it somewhere.
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Eugene,
Well I know what the monkey test ist, but all our parameters are String, so technically it is not a problem.
It is not easy to make validation for Price column for example, so why should we do something what we are not required to do???
Making it on client will contract the requirement "Changes on server in future schould produce min. changes on Client!" ?
Regards,
Vlad
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Vlad
all our parameters are String

I think your database schema describes the field that you have to save in the database as:

Customer holding this record owner 8 The id value (an 8 digit number) of the customer who has booked this. Note that for this application, you should assume that customers and CSRs know their customer ids. The system you are writing does not interact with these numbers, rather it simply records them. If this field is all blanks, the record is available for sale.

If I were doing this assignment, I would want to verify that the user has entered a number, and that it is eight digits long. I would verify this client side, so that if requirements changed (to allow alphanumerics for example) then only client software would have to change - the server could remain running uninterrupted.
It can be argued that you dont have to do any verification since the instructions state that the system does not have to interact with the numbers. You might also be able to argue that you want to leave the field unverified so that if the requirements change then you dont have to change anything at all.
This is your decision.
Regards, Andrew
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Andrew,
Thankx for your reply!
I have a problem understanding how it should be done:
1) On Server or Client?
if on client: we will breach the requirement: changes in server functionality should force min. changes on client...
if on server: we can't define additional exceptions in intreface
2) I don't know how to validate such field like currency:
Charge per night for the room. This field includes the currency symbol
Validating Date is easy (SimpleDateFormat), but validation currency (so that only two positions are allowed after float point and so on) is pretty difuccult.
How would U do it? Which classes whout you use for it?
Many thanks,
Vlad
 
Damian Ryan
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think that as a general rule, for robust client-server operation, the client SHOULD perform user input validation before sending updates/queries to the database server, BUT the server should obey the dictum "Never trust a client to do the right thing" and should perform further checks itself to prevent runtime exceptions being thrown server-side because of badly formatted client requests.
I know this sounds like redundancy. It is. But it is this kind of redundancy that keeps client-server systems from tripping up because of a slight error, and it really isn't that hard to implement.
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Damian,
Ok, you are right, but what shoulc the server do if it got the wrong request? The interface does't throw any exceptions to let the client know???
Can U give an idea how should I validate "Price per Night". It is a currency , and there is no any validation class for it in jdk (like SimpleDateFormat)?
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Vlad,
It seems that java.text.DecimalFormat may help for currency amounts.
Regards,
Philippe.
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Philippe,
That is exactly what I am trying to for 2 days without success
It checks only the first sign. So if your value is for example $aabb, parse works Ok without throwing parse exception(ignoring the fact that aabb are not digits)!?
 
Damian Ryan
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Vlad, take a look at JFormattedTextField, or (perhaps simpler) just use a normal JTextField and do some checking (client side) on the format of the string. For example, optional or mandatory currency symbol, followed by 0 or more digits, followed by optional decimal point, followed by optional digits. This is a really good opportunity to use regular expressions.
If you extract out your validation code into an external utility class, both server and client can re-use the same code to do validation.
As to signalling from the server that a client has made a malformed request - this will depend on how you implement your client-server communication. If you use sockets (unlikely, everyone else except me seems to use RMI) you can send back a response object that contains an error status code or an exception (a bit like HTTPServletResponse does) or if you use RMI you can have your remote interface (that extends your database interface) throw specific exceptions to indicate malformed client requests.
Check your instructions on this. For example, when I did the FBN assignment, the instructions for the criteriaFind method (you probably have something similar to implement) said to return null if the query was malformed. So returning null from a method may be a way to signal that the request was malformed. But this would need to be documented in the API.
Hope this helps.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Vlad,
I think you are going too far with your checking. I would only validate client side, and the only field that I would suggest checking is the only field the user is allowed to modify: the customer id field. All the data in the other fields should have come from the server itself, so your client will not have to validate them.
Regarding Damian's comment:
BUT the server should obey the dictum "Never trust a client to do the right thing" and should perform further checks itself to prevent runtime exceptions being thrown server-side because of badly formatted client requests.

I agree in principal with this, however I am willing to ignore this principal for this assignment because:
  • You cannot throw a checked exception if something fails to validate - I dont think a RuntimeException is the correct response to invalid data.
  • The schema does not store the type of data held in each field. If the schema stored this, then validating would be easy to do server side. Without this, you have to build a server that is specific to the type of data being stored (and I disagree with that concept).
    I would just note in your documentation that validation cannot be performed with the method signatures provided.
    Regards, Andrew
    [ July 08, 2003: Message edited by: Andrew Monkhouse ]
  •  
    Maksim Golubkow
    Greenhorn
    Posts: 22
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Andrew Monkhouse:
  • You cannot throw a checked exception if something fails to validate - I dont think a RuntimeException is the correct response to invalid data.



  • What about java.lang.IllegalArgumentException?
    From javadoc:
    Thrown to indicate that a method has been passed an illegal or inappropriate argument.

    I think we have to validate the data passed to methods createRecord(...) and updateRecord(...). If we don't do it, it wold be very easy to destroy the data file. For example somebody could use our Data class to store "A" or "B" in the smoking field instead of "Y"/"N" as required by the spec and so change the format of the record, what is not allowed.
    To rate validation:

    Hope this helps!
    Regards, Maksim
    [ July 09, 2003: Message edited by: Maksim Golubkow ]
     
    Vlad Rabkin
    Ranch Hand
    Posts: 555
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Andrew!
    Thankx for reply,
    I've managed to do all this validation things yesterday at 2:00 am, and I've realized then, that
    specification does require ONLY search by hotel name and location ! )))
    So, Andrew I beleive you are 100% right.
    I validate only:
    - Customer ID (since it will be written in Database)
    - Only length of Hotel Name and Location (since it is search criteria)
    That's it. I will not do any validation on server since it is not required.
    If we make to much the possibility of an error in the code is higher. So we will not get additional scores, we can just loose them! ))
    So, the problem is closed.
    Many thanks to all of you!
    Vlad
     
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander
    Pie
    Posts: 12014
    220
    C++ Firefox Browser IntelliJ IDE Java Mac Oracle
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Maksim

    Andrew: You cannot throw a checked exception if something fails to validate - I dont think a RuntimeException is the correct response to invalid data.
    Maksim: What about java.lang.IllegalArgumentException?

    It is better than throwing a generic RuntimeException, but it is still not a checked exception. And this could mean that a client application could die a horrible death even though the programmer coded to specified interface.
    I think that if we are going to check for invalid data, then it should be handled - it should not be a critical error that causes an application to die.
    Regards, Andrew
     
    Maksim Golubkow
    Greenhorn
    Posts: 22
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    It is better than throwing a generic RuntimeException, but it is still not a checked exception. And this could mean that a client application could die a horrible death even though the programmer coded to specified interface.

    You mean that folowwing code

    is coded to the specified interface? This code would compile but don't run.
    The question is: What is the specified interface?
    Is it only the method signature or not? In my opinion it is not. It is the method signature and the data format (or the range of the data you could provide as parameter) especially if you use such general types as String/int/...
    Regards, Maksim
    [ July 09, 2003: Message edited by: Maksim Golubkow ]
     
    pavan kalyan
    Greenhorn
    Posts: 15
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi,
    As we I already said: Having validation on server is good thing. I would do in any case in the real project where I can definy design and interfaces,
    but it is not required here, so why should we do it?
    Another point: It really depends on the overall architectrure whjere we may use IllegalArgumentException:
    If we say that both client and server will validate requiest - its corrrect. If we have a thin client - it is not correct, because an invalid requiest is caused not by incorrect implementation of the client and this exception must catched by the client, otherwise we have a risk that developer will forget to catch this exception....
    I don't want to make double validation (on the client and on the server) for this assignement,
    so I can't use RuntimeException.
    That's why I suppose it is enought to validate data just on the client.
    Regards,
    Vlad
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic