clientside modifications of disabled and readonly controls

Answered
0
0

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.

  • You must to post comments
Best Answer
0
0

Hi Bernhard,

fix for WJ-8655 is included in Wisej dev build 1.4.59.

Best regards
Frank

  • You must to post comments
Good Answer
0
0

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.

  • Tiago (ITG)
    Issue logged as WJ-8655
  • You must to post comments
0
0

I have tested it and comfirm this as fixed

  • You must to post comments
0
0

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.

  • You must to post comments
0
0

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

  • You must to post comments
0
0

Hi Bernhard,

As I understand it, there are two points

  1. Unwanted change of disabled or read only TextBox
  2. Unwanted clicks on disabled Buttons or other clickable elements (Tab page etc.)

Is this correct?

  • You must to post comments
0
0

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?

  • You must to post comments
0
0

Hi Bernhard,

Can you explain why this is a show stopper for you?

  • You must to post comments
0
0

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.

  • You must to post comments
0
0

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

  • You must to post comments
Showing 10 results
Your Answer

Please first to submit.