Server-side authorization
A hidden Edit button can make a page easier to understand, but it does not prevent an edit request. The browser belongs to the user: page markup, JavaScript, URLs, and submitted values can all be inspected or changed.
PHPRunner can hide actions according to permissions and enforce access on the server. Those are complementary jobs, and the server-side rule is the one that protects the data.
Quick answer: Use hidden buttons and fields to present the correct interface, but authorize the operation again after the request reaches the server. The rule must still work when someone types a page URL directly, changes a record key, submits a handcrafted request, calls an API, or triggers custom server code.
If a decision exists only in the browser, the user controls the decision.
CSS can make an element invisible. JavaScript can remove it from the page. A disabled control can prevent an ordinary click. None of those actions proves that the person is authorized. The underlying request may still be sent directly to the application.
The same applies to hidden fields. A value such as Role, Price, AccountID, ApprovalStatus, or OwnerID should not be trusted merely because the normal form does not display it. Important values should be assigned or verified on the server.
“Can this user open the page?” is only the first question.
A complete decision asks whether the user may perform this operation, whether the selected record belongs to the permitted scope, and whether the submitted fields may be changed. An employee might be allowed to edit a customer address but not the account's credit limit. A manager might approve requests only for a particular department.
Perform those checks using the authenticated identity and current database state. Do not rely on a username, group, owner ID, or permission flag supplied by the request itself.
A rule is incomplete if it covers one screen but not another entry point.
| Entry point | Server-side question |
|---|---|
| Direct page URL | May this user open this page and this record? |
| Add or Edit submission | May the user perform this change with these values? |
| Delete action | May the user delete this specific record now? |
| Export or download | May the user receive every record or file in the response? |
| REST API | Do the same identity, ownership, and operation rules apply without a visible page? |
| Custom button | Does its Server event repeat the authorization instead of trusting that the button was visible? |
Permissions establish the boundary; interface changes reflect it.
Use User Group Permissions and Advanced Security to restrict pages, operations, and records. Use server-side events when the authorization depends on additional business data or when certain submitted fields must be ignored or rejected.
After enforcement is in place, hide unavailable buttons, menu entries, fields, and links so users see an interface appropriate to their role. For a grid-row element, PHPRunner's server-side visibility methods use the element's Item ID and the current record ID. That improves the page, but it should mirror—not replace—the permission rule.
Test the request without the button.
For every restricted action, ask what happens if a user changes the URL, record key, submitted fields, or request method. If the server rejects the request independently of the interface, hiding the button is useful. If it does not, the application is only hiding the path—not protecting it.