Make the DAM's scope-based access control optional

[VPS-thodax]

depends on #6151

Problem

The DAM's REST controllers check whether the current user may access a file's scope, and they ask an AccessControlService to decide. That service comes from UserPermissionsModule and is injected unconditionally, so registering DamFilesModule without the user permissions setup fails at startup with an unresolved dependency.

That is the last thing keeping the DAM from running as a files-only service, which is what this stack (#6150, #6151) works toward.

Solution

The access control service is optional now, and every scope check goes through one helper, isAllowedToAccessScope.

A DAM that has no access control service still refuses to start, but on its own terms: DamFilesModule checks at module init and throws an error naming the two ways forward, instead of Nest reporting an unresolved dependency. A project that runs the DAM behind its own authentication guard, and therefore wants no scope checks at all, takes the second one:

DamFilesModule.register({
    damConfig,
    Scope: DamScope,
    File: DamFile,
    Folder: DamFolder,
    disableScopeAccessControl: true,
});

Setting it logs a warning at startup. Nothing changes for applications that use DamModule together with UserPermissionsModule: they keep using the registered AccessControlService.

One limitation — the option switches off the REST controllers' scope checks only. The DAM's GraphQL resolvers rely on UserPermissionsGuard, which comes from the same module, so a DAM without UserPermissionsModule has no permission checks on its GraphQL API and has to bring its own.

Decisions

• A missing access control service stops the application at startup, rather than being answered with 403 per request. Denying every scoped request keeps the REST endpoints closed, but the GraphQL resolvers have no such fallback: their scope checks come from UserPermissionsGuard, which the same module provides, so they would serve requests unguarded. A half-protected DAM cannot run this way. isAllowedToAccessScope still denies access when the service is missing or no user is authenticated, so the endpoints stay closed even if something ever gets past the startup check.
• The option lives on DamFilesModule, not in DamConfig. Projects fill DamConfig from comet-config.json and environment variables, which is no place for an authorization switch. It also keeps the option out of DamModule.register(), so a normal Comet app cannot turn scope checks off.
• One shared function instead of the same check in three controllers. The rule cannot drift apart between them, and it can be unit-tested.

Dropped alternative: no option at all, and standalone setups register an allow-everything AccessControlService instead. That service answers every permission check in an application, not just the DAM's, so it would be an easy way to switch off authorization everywhere.

Verification

• scope-access-control.spec.ts covers both helpers: the startup check with a service, without one, and with the option set; and the per-request check for a service that allows, a service that denies, a missing service, a missing user, and the option overriding all of them
• The Demo API boots, which the startup check only allows while the access control service is injected, and DAM thumbnails and a file preview still load in the Demo admin

Big picture

After this, DamFilesModule resolves against two things only — blob storage and MikroORM:

Dependency	Injected by	Provided by	Status
BlobStorageBackendService	FilesService, FoldersService, FilesController	BlobStorageModule	stays — the DAM has to store files somewhere
EntityManager / MikroORM	most providers	MikroOrmModule.forRoot	stays
ContentScopeService	FilesService, FilesController	UserPermissionsModule	removed in #6150
ImgproxyService	FilesService	ImgproxyModule	removed in #6151
DependenciesService	the dependents resolver	DependenciesModule	removed in #6151
ACCESS_CONTROL_SERVICE	FilesController, FoldersController, DamFilesModule	UserPermissionsModule	optional in this PR

[VPS-Obi]

IMO we don't need this warning. We don't log warnings for similar scenarios (e.g., the public option in the FileUploadsModule). If a dev uses the option, they (hopefully) know what they're doing.

[VPS-Obi]

This method is identical in the three controllers. Maybe we should move isAllowedToAccessScope to a service?

[VPS-Obi]

Have you considered to just make the service optional and not add an additional option? Or did you decide to make the decision to not have ACL explicit by setting the option?

[VPS-Obi]

Needs human review — touches auth/access-control logic.

This PR makes the DAM's AccessControlService optional and reroutes every scope check in FilesController, FoldersController, and ImagesController through a new isAllowedToAccessScope helper that fails closed when the service is missing. Authorization-path changes like this warrant a careful human look even with good unit coverage (scope-access-control.spec.ts) — worth double-checking the fail-closed guarantee holds for the GraphQL resolvers too, per the PR's own noted limitation. Already has 3 inline review comments and a requested reviewer (kaufmo), so review is in progress.

---

Generated by Claude Code