Oracle Visual Builder: Applications That Outlive Their First Release · Module 6 · Connecting to Fusion
Why a shared service account is usually wrong
Lesson 58 of 176 · 3 min
IT MAKES EVERY USER AS POWERFUL AS THE ACCOUNT. What that costs you in MODULE 11, and THE NARROW CASES WHERE IT IS STILL THE RIGHT ANSWER. The sentence is the whole argument and it is worth sitting with: whatever the service account can read, every user of your application can read, if they ask for it in a way your pages did not anticipate. BECAUSE THE ONLY THING RESTRICTING THEM IS YOUR PAGE, AND A PAGE IS NOT A RESTRICTION. Your page adds a filter for the user's own department; the endpoint your page calls will happily take a different filter, or none. Module 5 Lesson 4's rule, arriving with much higher stakes: browser-side logic is a courtesy, and the account's reach is the actual boundary. AND FUSION SERVICE ACCOUNTS ARE USUALLY BROAD, WHICH MAKES IT WORSE. They are provisioned to cover every case the integration might meet, so…
The full lesson is part of the course
The video, the complete written lesson and the module quiz are included in Oracle Visual Builder: Applications That Outlive Their First Release, with a certificate on completion and a fourteen-day refund window.
In this module: Module 6 · Connecting to Fusion
- 1What a service connection is
- 2Creating one against a Fusion REST APIFree preview
- 3Authentication, and whose identity is used
- 4Why a shared service account is usually wrong
- 5Query parameters, filtering and fields
- 6Pagination, properly
- 7Writing back to Fusion
- 8When the shape changes underneath you
- 9Calling an OIC integration instead
- 10Handling a service that is down
- 11CORS and the errors it produces
- 12What breaks: four connection failures
- 13Lab briefing · Connect, over-fetch, then fix it