1

I'm working on a page where you have a box of things and you can drag the things around to reposition them. You can also drag them to a specified drop zone to move them to another box. This brings up a list of all your boxes, where you select the one you want to move it to. The thing is then moved there, so for the current view it is simply removed and the "# things" counter is decremented. Simple.

However, if the user selects the box that the thing is already in, then it will appear removed and gone, until the current box is reloaded in which case it reappears.

Well, since moving a thing to the box it's already in is counter-productive, I've added the "disabled" attribute to the button that would move it to its own box. I figure this is better than outright removing the box from the list, since that might cause further confusion (where is my box? why is the "select box" dialog inconsistent here? etc.)

But naturally, this being the browser, the user can do whatever the hell they like really. Such as going into the DOM inspector and removing the "disabled" attribute, then clicking the button.

Server-side, there's already a check for "is the thing already in that box? if so, no action needed", but the JavaScript side of things will blindly continue to remove the thing from the box and decrement the counter. The thing then reappears when you reload the box.

So my question is: does this matter? If a user is tampering with the DOM, surely they must realise that this can lead to undefined or unexpected behaviour? So long as the server-side handles input appropriately (validating, DB parameter queries etc.) is there any harm in leaving this the way it is, even though it's quite bad behaviour to have it look like the thing was moved when it hasn't, because the user moved it to an invalid selection?

  • If possible add some images and synthesize the text. Wall of text answers are less likely to be answered. – Alejandro Veltri Jan 20 '16 at 13:19
2

First: No, you don't have to design UX thinking of how can the common user modify the DOM from the backdoor.
If your system security and robustness relies on UI modifications, it's a sign of bad software design, you should validate both on the client and the server.

Disabling the current box in the target selection is okay, but it may improve it to add a clarification to avoid any confusion.

mockup

download bmml source – Wireframes created with Balsamiq Mockups

  • 2
    That's a good idea. I'll see if I can integrate the reason for disabling in there, since there's other reasons too (box might be full, for instance). – Niet the Dark Absol Jan 20 '16 at 13:54
1

I see no problem in "undesirable" action taking place after the user manipulates the DOM IF it doesn't cause any vulnerabilities or permanent damage. In this case it will just look weird until the user reloads, that is acceptable, you took care of the real issues by checking server side. They could also manipulate the DOM to delete the item completely or create 1000 of them, you can't prepare for every possibility because as you said "the user can do whatever the hell they like really".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.