When I was writing this ticket https://wisej.com/support/question/datetimepicker-readonly-but-changeable-by-arrow-up-and-down I was thinking why the client is able to update service side controls while they are supposed to be readonly or disabled.
Therefore I wrote a small demo and can confirm that the users are able to change the text of a readonly or disabled textbox using the JavaScript api. It works fine for labels.
My assumption would be that the user shouldn’t be able to change controls when the state of the control is not changeable and this behaviour is a bug.
Hi Bernhard,
fix for WJ-8655 is included in Wisej dev build 1.4.59.
Best regards
Frank
Since it’s impossible to stop a tech user to change anything he likes on the browser (and console can’t be blocked – go to facebook, open console and type alert(1) ) what we can do is stop the server side from accepting the change from the client when the control is disabled or read-only.
I have tested it and comfirm this as fixed
I’m aware that nobody can control the client.
“what we can do is stop the server side from accepting the change from the client when the control is disabled or read-only.”
Perfect. Thats what I was looking for.
Only 1 is an issue. The second point is handled correct by WiseJ.
For 1: User is able to change the text of disabled controls –> unwanted behaviour. Not checked by wisej.
For 2: User is not able to click on disabled controls –> expected behaviour and also correctly enforced on serverside by wisej
2. was only an example that you are already checking for enabled on Buttons but not on TextBoxes
Hi Bernhard,
As I understand it, there are two points
Is this correct?
We load the POCO = EntityFramework object from the database, bind the properties to the textboxes (or any other editable-control) and afterwards save the entity. I assume this is the typical Workflow for data driven applications.
Now, if the user has no permission to edit some properties, we set the control to readonly (or disabled). With this we want to make sure that the property can not be changed by the client (user or JavaScript).
But with this issue the user is still able to change properties (still he has to be an advanced user knowing the JavaScript API).
Our finding on this topic is also taht if the user “clicks” a disabled button with JavaScript button.execute() you are checking if the control is enabled. Why not checking for readonly or enabled for TextBoxes, DateTimePicker or any other editable control?
Hi Bernhard,
Can you explain why this is a show stopper for you?
Thank you for your reply but for us this is not an option. I attached a simple demo how this will be a showstopper for us (and I assume this will be an issue for many other developers).
In my first example you also saw that, for example, changing the text of a label is not send to the server.
Hi Bernhard,
no, readonly protects a control from being changed by user activity.
Programatically it still can be updated (this includes javascript).
Otherwise there would be no chance to display anything in the browser.
Hope that helps.
Best regards
Frank
Please login first to submit.