@produtype/core 1.12.0 → 1.13.0

package/dist/analyzer/detectAuth.js

@@ -301,7 +301,64 @@ async function detectAuth(ctx) {
      * is the one that meant three different things in three repositories, and it is the
      * one the tree answers.
      */
-    const unambiguousRoles = await (0, textSearch_1.searchInFiles)(ctx.root, sourceFiles, [/requireRole/i, /isAdmin/i, /SUPER_ADMIN/i, /roles\.includes\(/i], 20);
+    /**
+     * Spring says all of this with names it owns, and none of them were here.
+     *
+     * mall is a Spring Boot shop with a full authorization model — a filter chain built
+     * with `authorizeHttpRequests`, a `DynamicAuthorizationManager` comparing the
+     * caller's `GrantedAuthority` against the one a path requires, and a
+     * `UmsAdminRoleRelationDao` that loads an administrator's roles from the database —
+     * and it was told at `medium` that it has no role checks and no permission checks
+     * at all.
+     *
+     * Every word above is Spring Security's or the JSR's: `GrantedAuthority`,
+     * `@PreAuthorize`, `@Secured`, `@RolesAllowed`, `hasAuthority`, `hasAnyRole`,
+     * `authorizeHttpRequests` and the `antMatchers` it replaced. What mall chose was
+     * `Ums`, the prefix on its own classes, and that is exactly what a search must not
+     * depend on.
+     */
+    const SPRING_AUTHORIZATION = [
+        /@PreAuthorize\b/,
+        /@PostAuthorize\b/,
+        /@Secured\b/,
+        /@RolesAllowed\b/,
+        /\bGrantedAuthority\b/,
+        /\bhasAuthority\s*\(/,
+        /\bhasAnyAuthority\s*\(/,
+        /\bhasAnyRole\s*\(/,
+        /\bhasRole\s*\(/,
+    ];
+    /**
+     * `authorizeHttpRequests` is not on that list, and the corpus is why.
+     *
+     * It was, and `spring-security-defaults` — a fixture whose whole point is a chain
+     * with no roles in it, `requests.anyRequest().authenticated()` — started reading as
+     * having an authorization model. Every Spring Security setup writes that line: it
+     * says the request must be authenticated, which is the question one capability
+     * along. The same test Django's `SecurityMiddleware` and Rails' default headers
+     * failed — a thing every project has distinguishes nothing.
+     *
+     * What survives is the part somebody chose: which authority a path requires, and
+     * the annotation that says it on a method.
+     */
+    const unambiguousRoles = [
+        ...await (0, textSearch_1.searchInFiles)(ctx.root, sourceFiles, [/requireRole/i, /isAdmin/i, /SUPER_ADMIN/i, /roles\.includes\(/i], 20),
+        ...await (0, textSearch_1.searchInFiles)(ctx.root, sourceFiles, SPRING_AUTHORIZATION, 20, 
+        /**
+         * An import is not a check.
+         *
+         * `import org.springframework.security.core.GrantedAuthority;` names the type
+         * and decides nothing; `grantedAuthorities.stream()` twenty files away is where
+         * the caller's authority is compared against the one the path requires. The
+         * first version of this cited the import, which is the same complaint pocketbase
+         * earned two releases ago — a reader is promised the line that decides.
+         *
+         * Filtered inside the search rather than after it, so the budget is spent on
+         * lines that check something: a Java project has one import per file and they
+         * would fill it.
+         */
+        (match) => !/^\s*import\b/.test(match.snippet)),
+    ];
     const comparedRoles = guardedRoles
         ?? excludeChatTurnRoles(await (0, textSearch_1.searchInFiles)(ctx.root, sourceFiles, [/req\.user\.role/i, /user\.role/i, /role\s*===/i], 20));
     const roleSignals = [...unambiguousRoles, ...comparedRoles].slice(0, 20);
@@ -524,7 +581,7 @@ async function detectAuth(ctx) {
         {
             key: 'authz.roles',
             present: roleSignals.length > 0,
-            evidence: (0, absenceEvidence_1.evidenceOrSearch)(snippetEvidence(roleSignals), 'role checks', ['role ===', 'hasRole', 'isAdmin', 'user.role', 'roles.includes', '@Roles', 'role_required']),
+            evidence: (0, absenceEvidence_1.evidenceOrSearch)(snippetEvidence(roleSignals), 'role checks', ['role ===', 'hasRole', 'isAdmin', 'user.role', 'roles.includes', '@Roles', 'role_required', '@PreAuthorize', '@Secured', 'GrantedAuthority', 'hasAuthority(', 'hasAnyRole(']),
         },
         {
             key: 'authz.permissions',

package/dist/analyzer/detectDatabase.js

@@ -225,26 +225,53 @@ async function detectDatabase(ctx) {
         databases.add('sqlite');
         evidence.push({ type: 'file', value: 'sqlite db file detected' });
     }
-    // docker-compose hints
-    const composeFile = ctx.files.all.find((f) => /(^|\/)(docker-compose\.ya?ml|compose\.ya?ml)$/.test(f));
-    if (composeFile) {
+    /**
+     * Every compose file, not the first one in the list.
+     *
+     * A repository has several: `docker-compose.yml` beside `.devcontainer/
+     * docker-compose.yml`, an override for tests, one per deployment shape. This read
+     * whichever came back first and ignored the rest, so a Postgres declared only in
+     * the production compose was invisible whenever a development one sorted ahead of
+     * it — and which one that is was the filesystem's business until this session
+     * sorted the scan.
+     *
+     * The devcontainer is not excluded here, and that is the difference from
+     * `docker.presence` next door. "How does this ship" is answered by the image the
+     * product is built into; "what does it store data in" is answered by the database
+     * it talks to, and in development that is the one the devcontainer starts. The same
+     * file, two questions, two answers.
+     */
+    const composeFiles = ctx.files.all.filter((f) => /(^|\/)(docker-compose[\w.-]*\.ya?ml|compose[\w.-]*\.ya?ml)$/.test(f)).slice(0, 8);
+    /**
+     * Each store cited once, from the first file that shows it.
+     *
+     * immich has seven compose files and all of them run Postgres and Redis, so reading
+     * every one turned two facts into eleven citations of the same two facts. A reader
+     * is promised a line they can open and argue with; eleven lines saying the same
+     * thing is not eleven times the argument.
+     */
+    const COMPOSE_SERVICES = [
+        ['postgres', /image:\s*postgres/i, /postgres:/i],
+        ['redis', /image:\s*redis/i, /redis:/i],
+        ['mysql', /image:\s*mysql/i, null],
+        ['mongodb', /image:\s*mongo/i, null],
+    ];
+    /**
+     * Counted for this reading only, not against `databases`: a store the dependencies
+     * already named still deserves the compose line beside it, and skipping on the set
+     * removed every compose citation from a project that declares its driver too.
+     */
+    const citedFromCompose = new Set();
+    for (const composeFile of composeFiles) {
         const text = (await (0, readTextFileSafe_1.readTextFileSafe)(ctx.root, composeFile)) ?? '';
-        const lower = text.toLowerCase();
-        if (/image:\s*postgres/i.test(text) || lower.includes('postgres:')) {
-            databases.add('postgres');
-            evidence.push({ type: 'file', value: 'postgres in docker-compose', file: composeFile });
-        }
-        if (/image:\s*redis/i.test(text) || lower.includes('redis:')) {
-            databases.add('redis');
-            evidence.push({ type: 'file', value: 'redis in docker-compose', file: composeFile });
-        }
-        if (/image:\s*mysql/i.test(text)) {
-            databases.add('mysql');
-            evidence.push({ type: 'file', value: 'mysql in docker-compose', file: composeFile });
-        }
-        if (/image:\s*mongo/i.test(text)) {
-            databases.add('mongodb');
-            evidence.push({ type: 'file', value: 'mongo in docker-compose', file: composeFile });
+        for (const [name, image, service] of COMPOSE_SERVICES) {
+            if (citedFromCompose.has(name))
+                continue;
+            if (!image.test(text) && !(service && service.test(text)))
+                continue;
+            databases.add(name);
+            citedFromCompose.add(name);
+            evidence.push({ type: 'file', value: `${name} in docker-compose`, file: composeFile });
         }
     }
     // DATABASE_URL env reference

package/dist/analyzer/detectJobs.js

@@ -97,11 +97,21 @@ async function detectJobs(ctx) {
     for (const name of processScripts) {
         evidence.push({ type: 'note', value: `package.json script "${name}" starts a separate process` });
     }
-    // A compose service that runs one.
-    const composeFile = ctx.files.all.find((file) => /(^|\/)(docker-compose\.ya?ml|compose\.ya?ml)$/.test(file));
-    const composeText = composeFile ? ((await (0, readTextFileSafe_1.readTextFileSafe)(ctx.root, composeFile)) ?? '') : '';
-    const composeWorker = /^\s{2}(worker|jobs?|scheduler|cron|consumer)[a-z0-9_-]*:/im.test(composeText);
-    if (composeWorker && composeFile) {
+    /**
+     * A compose service that runs one — in any of the compose files, not the first.
+     *
+     * A repository has several, and this read whichever came back first: a worker
+     * declared in the production compose was invisible whenever a development one
+     * sorted ahead of it. The same first-match reading that made `docker.presence`
+     * answer "how does this ship" with a devcontainer, one detector along.
+     */
+    const composeFiles = ctx.files.all.filter((file) => /(^|\/)(docker-compose[\w.-]*\.ya?ml|compose[\w.-]*\.ya?ml)$/.test(file)).slice(0, 8);
+    let composeWorker = false;
+    for (const composeFile of composeFiles) {
+        const composeText = (await (0, readTextFileSafe_1.readTextFileSafe)(ctx.root, composeFile)) ?? '';
+        if (!/^\s{2}(worker|jobs?|scheduler|cron|consumer)[a-z0-9_-]*:/im.test(composeText))
+            continue;
+        composeWorker = true;
         evidence.push({ type: 'file', value: 'a worker service in compose', file: composeFile });
     }
     const declarations = await (0, textSearch_1.searchInFiles)(ctx.root, ctx.files.source, JOB_DECLARATIONS, 20);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@produtype/core",
-  "version": "1.12.0",
+  "version": "1.13.0",
   "description": "Deterministic CLI and library that analyzes a web application repository and reports how far it is from production-ready for the kind of product it is meant to be.",
   "license": "MIT",
   "bin": {