- Dikirim
- 19 April 2026 pukul 21.34 UTC
- Penulis
- Kamo
- Commit
- 7720191
Closes the "stale DB leaks a disabled feature" gap by gating every surface that touches OrgFeature / ServiceType through the applied security model. - **************** (the primary feeder of the frontend OrgContext): replaces the raw features serialization with **************** org.getFeatures()). The auto- provisioning loop now also skips apps the model marks NOT_AVAILABLE so we never create DB rows for blocked apps. - FeatureController.list: returns each feature with modelAvailability + locked metadata. NOT_AVAILABLE rows are filtered out, FORCE_ENABLED rows are reported as enabled=true + locked=true regardless of their DB state. The available list is also filtered down to apps the model permits. - New AppAvailabilityInterceptor + WebMvcConfig: installs a HandlerInterceptor on every service-scoped URL prefix (/api/security/pos, /api/security/commerce-markets, /api/security/leads*, /api/security/lead- imports, /api/security/lead-markets, /api/security/lead-vendors, **************** **************** **************** Each request is matched to a ServiceType, resolved against the caller's applied model, and rejected with HTTP 403 if the app is effectively off. This is the final line of defense: even with stale client state, a forgotten controller guard, or a direct API call, a blocked app returns 403. Net effect: the applied security model now wins at read time everywhere the org's features or apps are exposed — navigation, home page, settings slide-out, FeaturesManager, per-service endpoints. When the admin flips CRM to NOT_AVAILABLE on the model, the CRM UI disappears from the frontend and CRM endpoints start 403'ing — regardless of whether the DB still has OrgFeature.isActive=true for CRM.