dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

Well, usually this would be the case, that there would be validation at the
database level, but given the database agnostic nature of DHIS, I have no
idea how or if this can be done.  I would think that the period "
YYYY-MM-YY" value should actually be stored as a real date type. Currently,
I think it is only text. The same can be said for the datavalue table, which
stores values as text, instead of having a datavalue table with multiple
columns (one for integers, reals, booleans, text and so forth, similar to
DHIS 1.4) , each with real db data types. Of course, placing other
constraints at the db level is also possible, but have no idea how to do
this with hibernate.



2009/12/23 Bob Jolliffe <bobjolliffe@xxxxxxxxx>

> 2009/12/23 Lars Helge Øverland <larshelge@xxxxxxxxx>
>
>
>>
>> On Wed, Dec 23, 2009 at 4:01 AM, Hieu Dang Duy <
>> hieu.hispvietnam@xxxxxxxxx> wrote:
>>
>>> Dear Saptarshi,
>>>
>>> I'm not good at about security, I also knew that using javascript it's
>>> really not safe in web application. By the way, I have a small idea about
>>> this issue that. Not surely, have any configuration/setting about date in
>>> DHIS2 program ? Unless, I think we can make a new setting for this one.
>>> I meant we should make a pattern setting for date format, ie. yyyy-mm-dd
>>> for DataEntry module. Or can be expanding to use for our whole system.
>>>
>>> In that case, we can easily use any kind of validations with that pattern
>>> setting in either client-side (javascript) or server-side (java).
>>>
>>> Thanks for your suggestion !
>>>
>>>
>> Hi,
>>
>> I would say that we should stick with yyyy-mm-dd for input for now, to me
>> the added complexity of configurable date input formats justifies the
>> benefit...
>>
>> Re validation, we do have server side validation for meta data like data
>> elements, indicators, data set etc. A problem is that we have separate
>> action classes for validation and adding/updating (this was done with
>> separation-of-concerns in mind). This poses a threat since a "malicious"
>> user could bypass this by turning off javascript in the browser or sending
>> direct GET-requests. Btw I wouldn't say avoiding javascript validation is
>> the answer, rather having both where its possible.
>>
>
> Agreed it is not an either/or thing.  Validation at the browser and
> validation at the server actually serve two different purposes.  Client side
> validation is really a convenience to the user to prevent having to enter
> data only to find that the data is later rejected after the http post/get.
> Catching the validation problem early allows for a slicker and more friendly
> user interface.  But because it can be easily bypassed it is not a mechanism
> for protecting the integrity of data to be persisted and should not be used
> with that in mind.  That is the purpose of server side validation.  But of
> course we all know that ....
>
> Sorry I haven't looked much at the validation action classes so I can't
> really comment much.  But shouldn't the validation be a function of the
> model layer (as low down as it can be pushed) and be "un-bypassable"?.  This
> way it also applies to data input from other sources than the web ui.
>
> Bob
>
>
>
>> Lars
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>