I recently started to work in a java enterprise project (~200 people) that uses a SWT rich client. In many cases I've found business rules not being validated in server side, because the widgets that trigger such actions are disabled in the SWT client using the business rules.
This is a well known question of validation in server, client or server+client and I'm not pointing to the same issue. Also, I'm in favor of validation in server+client.
The need of validation in the client is obvious because allows a more responsive application for the end user and less requests for the server.
The need of validation in the server is obvious with a web client, where one can play with the html and javascript for avoid the client-side validations and send incorrect data to the server.
But, with a SWT client this is not that simple (could be achieved with a package sniffer like Wireshark?) so one could argue that validate in the server would have an innecesary cost in performance. Always in a scenario where there is only one point of access to the application and it's the SWT client.
If the project had begun yesterday I would fight for server+client validation, but in a project with 8 years of history this could be difficult because we would have to convince end-users and analysts for the advantages of the performance penalty.
So, every time I find one of this validation holes I struggle between add the server side validation or let it go, thinking "the client will catch it and this will never happen" and continue with a more priority task.
This project has been productive four years, so it's a viable practice, but from the point of view of design, is correct this approach? Aniway I think this is a consequence and not something deliberately sought.
Could be taken it like a political decision with knowledge of the consequences or the software world will say NO to this practice?