Function remains accessible despite internal modifier when service binding allow pattern is permissive
24K reputation · 07 Jul 2023, 01:56 UTC
When developing a Ballerina service, I want to guarantee that certain helper functions are not callable from outside the defining package, even if the service is bound to an HTTP listener with a permissive allow pattern.
The language provides the private keyword for function‑level visibility and the internal modifier (since 2.2.0) for package‑level visibility. However, it is unclear whether these modifiers interact with service binding allow patterns: does marking a function as internal or private automatically prevent external HTTP invocation when the listener’s allow rule accepts all paths?
Specifically, I need to know if an internal function remains reachable via the service endpoint despite its visibility restriction, and what additional steps—if any—are required to fully block accidental public access.
Does an internal or private function stay inaccessible when the service binding uses an allow pattern of "**"? If not, what configuration (e.g., explicit deny rules or listener‑level security) is needed to enforce the intended access boundary?