Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-10-05 22:56:55 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

Add 18 more community AL/BC patterns across appsource, data-modeling, error-handling, security, style, testing, ui, upgrade, and web-services

Browse source 
Second contribution from CURABIS ApS, generalized from patterns observed across real AppSource/PTE development. Cross-checked against the current microsoft/knowledge corpus before opening; several originally-drafted candidates were dropped as duplicates of existing files.
This commit is contained in:
Michael Dieringer 2026-09-04 20:59:54 +02:00
parent 07e324ddbc
commit a4d85c3e9e
50 changed files with 1262 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

12
microsoft/knowledge/security/exposed-objects-must-be-in-a-permission-set.bad.al Normal file
View file

@ -0,0 +1,12 @@
permissionset 50100 "Sample - Integration"
{
Access = Public;
Assignable = false;
Caption = 'Sample Integration';
Permissions =
tabledata "Sample Order" = RIMD;
// BUG: "Sample Order API" (PageType = API) and "Sample Order Query"
// (a published API query) have no "= X" entry anywhere in this app.
// Both endpoints are unreachable even though the table looks fully
// granted - nobody decided who may call them.
}

10
microsoft/knowledge/security/exposed-objects-must-be-in-a-permission-set.good.al Normal file
View file

@ -0,0 +1,10 @@
permissionset 50100 "Sample - Integration"
{
Access = Public;
Assignable = false;
Caption = 'Sample Integration';
Permissions =
tabledata "Sample Order" = RIMD,
page "Sample Order API" = X, // exposed API page: execute granted
query "Sample Order Query" = X; // exposed API query: execute granted
}

26
microsoft/knowledge/security/exposed-objects-must-be-in-a-permission-set.md Normal file
View file

@ -0,0 +1,26 @@
---
bc-version: [all]
domain: security
keywords: [permission-set, api-page, web-service, exposure, access-control]
technologies: [al]
countries: [w1]
application-area: [all]
---
# Every exposed object must belong to a permission set
## Description
An object that is reachable from outside the app's own UI — an API page (`PageType = API`), a web-service-enabled page or query (`ServiceEnabled = true`), or a published API query — is only usable if it is also granted execute access through a permission set. When such an object is left out of every permission set, it becomes both unusable (no caller, human or service, can reach it) and invisible in review: nobody deliberately decided who may call it. Exposure without a matching grant is not a safe default; it is an endpoint nobody is governing.
## Best Practice
Give every exposed object an explicit execute entry (`page "..." = X`, `query "..." = X`) in a permission set shipped by the app. Route sensitive endpoints into a dedicated, non-default admin permission set so reaching them requires a deliberate grant rather than being included by default. If an object should never be reachable from outside the app, remove the exposure itself (drop `PageType = API` / `ServiceEnabled`) rather than leaving an orphaned endpoint with no permission-set membership.
See sample: `exposed-objects-must-be-in-a-permission-set.good.al`.
## Anti Pattern
Granting access to the underlying table data while forgetting to grant execute access to the exposed page or query itself. The table looks fully covered by a permission set, but the API/service layer in front of it has no `= X` entry anywhere, so the endpoint silently fails for every caller even though the data permissions look complete.
See sample: `exposed-objects-must-be-in-a-permission-set.bad.al`.