I noticed that fields that are restricted from editing, but that are empty, will throw an error to the user upon submission. I'll look at the code and see if I can figure out where this could be modified. If anyone knows where this is already, please respond. Thanks!

Comments

mshaver’s picture

mshaver commented

I added a line to the validate function to first check that the $user->$key field isn't blank before validating the field. By adding an if statement on line 155:

if ($user->$key != '') {

Now it will only validate fields that aren't blank and are disabled.

I'm a little confused with the validate function in general? If the field is disabled, how can someone edit it in the first place?

junyor’s picture

junyor commented
Status: Active » Postponed (maintainer needs more info)

The user can edit the page (in their browser's cache, for instance) to remove the disabled attribute, then submit it after changing the form value.

In any case, I'm not able to reproduce this problem. I have an empty profile field set to read-only, submit the form, and it's fine.

mshaver’s picture

mshaver commented

I went back to see if I could reproduce the error and I can't seem to? Maybe it was coming from some place else? I've taken out my hack and it's working fine. I'm not sure if I understand how they can edit page in their browser's cache and re-submit. Is that a security issue?

junyor’s picture

junyor commented
Status: Postponed (maintainer needs more info) » Closed (won't fix)

No, it's not a security issue. Browsers cache information locally. Once the page is sent from the server to the client, the client (or anything in between) can change the page. The client can also change the page. That's all natural, expected behavior. That's why server-side validation is required.