EEConf 2024 is around the corner! EEConf 2024
I have a channel that allows the user to modify some fields, but I need some specific field not to be modifiable from the user on the template side.
Can this be securely prevented? Not putting the value in the form is not an option, as someone could just modify the form to include the field and pass a value.
Or should I just have a separated channel for those fields which no access to users? Ideally, I would like to keep all user fields in the same channel but some fields only be readable by the user and only allow for modifications by the admin (or another authorized member group)
Can you just wrap it in a conditional?
{if exp:member:has_role role_id="6"}
<select name="my_field_name" id="my_field_name">
{options:my_field_name}
<option value="{option_value}"{selected}>{option_name}</option>
{/options:my_field_name}
</select>
{if:else}
My Field's Value is: {my_field_name}
{/if}
I did not consider a conditional, I will try that.
I still want users to be able to see the value rendered in a template, but not be able to modify it. Since I will have a form on the same page that allows the modification of other fields in the same channel, I don’t want some malicious users to modify the source code and just pass the field name (assuming they guess the name) to that form in the POST request.
I’m not trying to hide the value in the form, since it will not exist but prevent someone from trying to pass it.
I don’t think a conditional example would work in this specific case, since you are excluding the field from being rendered visually in the form front end.
It does not stop a malicious user from editing the form and adding the value back manually before sending the POST request. The permission should rely on a permission on the server side.
Think here ‘read’ = yes, ‘write’ = no. But only for that field or specific fields.
In the conditional, I’m displaying the field’s value, just not as an element that accepts user input. If you want it to appear as an HTML input field but not actually be user-editable then you can style it however you’d like when you display it.
The second part of the requirement is tougher. I mean, theoretically someone could guess any fields in a channel form and try to submit those with a POST request. I think the only way to really prevent this is through an add-on (extension). Probably hook into the before_channel_entry_update
hook. In your extension you’d check the member’s role and remove any data updating fields you don’t want to be updated by certain roles.
Hi guys, well that is precisely what I want to prevent here. Imagine a product sales amount in that field. You want to display the price, but hiding it visually does not prevent someone from tampering the amount before ordering, as such changing the price. That is just an example, but I think you get the idea.
Is there any add-on for this or PHP code I can use? I want to avoid that one more add-on route if possible. But now…
Natively without add-ons, would this work?
Channel B (store fields users cannot modify)
Template, display both data from Channel A and Channel B.
Template has an entry form that allows to modify values in Channel A, but user has no permission to modify entries in channel B.
Is that maybe the solution I initially came up the only option?
I decided to ask first since it’s a bit cumbersome to have a second channel just for one field.
I do understand what you’re trying to do. That was an easy way to get stuff from websites for a penny back in the day :D. Of course, the way to overcome that in e-commerce was with server-side validation. The product would be sent via POST, then you had a method to look up the price of the product and charge the customer that amount no matter what was actually rendered on the front-end. Same thing with using an extension hook. User sends the form, the extension makes sure certain fields aren’t tampered with based on roles, and then updates/creates the entry. Lots of add-ons are not bad, and are sometimes a cleaner way to do things. No one installs a library like Laravel and says I’m not going to write anything custom for this. It’s expected. Same thing with EE. EE provides a great platform and starting point to build some really awesome stuff, but the whole reason there are are add-ons and so many hooks is to allow devs to build bigger and better things with it. Now, to be clear, there is a major issue with just installing tons of 3rd party add-ons that you don’t know if the dev is going to support them or if the code is even good just to do a few small things. However, having a lot of your own add-ons to dos specific functions is fine and often a great choice.
If an add-on is just not the right option for you, and you’re really concerned about being hijacking the POST requests then I think the two-channel approach is the best. You can’t have channel entry tags inside of channel entry tags, so you’ll need to use template embeds to make this work.
I see, it’s not a big issue. I can just have a second channel, just curious if it was possible out-of-the-box, reason I asked first.
Likewise, I do tend to use PHP and my own forms for critical data as I can do all the check on the POST request server side and in that sense you can completely ignore values and only process the ones required, after the proper validation and sanitization but in this case I would use the EE Post form tag and I don’t actually manage the data request, but EE does. EE does the field validation for data in this case, so I was just curious if it was also possible to ignore a specific field as well from being updated. Maybe this could be a nice feature in some future, permissions per field, but I understand that would get complex quickly to have such granular permissions up to the field type level.
I will just go the second channel route and modify values with my own PHP code, and just keep the channel form entry for data that is safe for users to update. This is not such a critical field, reason why I decided to put in a channel entry, for most critical data I don’t actually want to put them in entries just in case…but I assume that putting them in a separated channel that only admins or specific authorized groups are able to modify, is moderately secure as I don’t give regular users access to the control panel anyway, they can only update and manage data from a template. This way I can keep fields which I want to be read only but not write for users separated by channel permissions.
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.