微服务环境下基于权限的文档服务实现技术问询

Great question—this is a common scenario when building distributed systems with fine-grained permissions, especially when dealing with document resources. Let’s break down a scalable, maintainable solution tailored to your Node.js microservices and Actor-based auth setup:

1. Align Permission Models with Your Actor Pattern #

First, you need to map your Actor-based auth system to document-specific application-level permissions. Here’s how to structure it:

• Store Permission Metadata in Database: Create a document_permissions table/collection that links documents to authorized Actors. It should include fields like doc_id, actor_type (user/role/organization), actor_id, and permission (read/write/delete).
• Embed Actor Context in Tokens: Ensure your frontend’s auth token (e.g., JWT) carries critical Actor details: actor_id, actor_type, and associated roles (if users inherit permissions via roles). This cuts down on redundant database calls in microservices.

2. Build a Reusable Permission Validation Layer #

Since you have an unknown number of Node.js microservices, duplicating validation logic across services is a recipe for technical debt. Instead, create a shared middleware or utility library:

• Package as an Internal NPM Module: Build something like @your-org/doc-permission-validator that all microservices can import.
• Core Middleware Logic (Express Example):

  const jwt = require('jsonwebtoken');
  const { checkDocumentAccess } = require('@your-org/doc-permission-validator');
  
  const validateDocPermission = (requiredPerm = 'read') => async (req, res, next) => {
    try {
      // 1. Extract and verify auth token
      const token = req.headers.authorization?.split(' ')[1];
      if (!token) return res.status(401).json({ error: 'Unauthorized' });
      
      const decoded = jwt.verify(token, process.env.JWT_SECRET);
      const actorContext = { 
        actorId: decoded.actor_id, 
        actorType: decoded.actor_type, 
        roles: decoded.roles || [] 
      };
  
      // 2. Grab document ID from request (adjust based on your route structure)
      const docId = req.params.doc_id;
      if (!docId) return res.status(400).json({ error: 'Document ID required' });
  
      // 3. Validate permission against the database/permission service
      const hasAccess = await checkDocumentAccess(docId, actorContext, requiredPerm);
      
      if (!hasAccess) return res.status(403).json({ error: 'Insufficient permissions' });
  
      // Attach actor context to request for downstream business logic
      req.actor = actorContext;
      next();
    } catch (err) {
      res.status(401).json({ error: 'Invalid or expired token' });
    }
  };
  
  // Usage in a microservice route
  app.get('/docs/:doc_id', validateDocPermission('read'), async (req, res) => {
    // Permission is already validated—safe to fetch and return the document
    const document = await db.collection('documents').findOne({ _id: req.params.doc_id });
    res.json(document);
  });
  

• Decouple Permission Checks: For better scalability, consider a dedicated permission service instead of direct database calls from middleware. Microservices can call this service’s API to validate access, keeping data layer dependencies minimal.

3. Secure Document Delivery #

How you return documents depends on where they’re stored—here are two common scenarios:

• Database-Stored Binary Data: Once permission is validated, you can directly stream the binary data from the database to the frontend.
• Cloud Storage (e.g., S3, GCS): Never return direct cloud storage URLs (they bypass your permission checks). Instead:
  1. After validating access, generate a short-lived signed URL (e.g., 15 minutes) via the cloud provider’s SDK.
  2. Return this signed URL to the frontend—users can only access the document through this temporary, authorized link.

4. Handle Permission Changes in Real-Time #

When document permissions are updated, ensure subsequent requests respect the new rules:

• Short-Lived Caching: If you cache permission checks (e.g., with Redis), set a short TTL (1–5 minutes) to balance performance and freshness.
• Event-Driven Invalidation: Publish a doc-permission-updated event when permissions change. Microservices can listen to this event and clear cached permissions for the affected document immediately.

5. Audit & Logging #

For compliance and debugging, log every permission check:

• In your validation middleware, log details like actor_id, doc_id, permission_requested, timestamp, and result (allowed/denied).
• Send logs to a centralized system (e.g., ELK, Datadog) so you can audit access patterns or investigate permission issues.

6. Edge Case Handling #

• Document Existence: Check if the document exists before validating permissions—return 404 instead of 403 to avoid leaking whether a document exists (a security best practice).
• Super Admin Bypass: Add a special case in the middleware to allow super admins/global actors to skip permission checks (use sparingly and document thoroughly).
• Batch Requests: For endpoints that fetch multiple documents (e.g., GET /docs?ids=1,2,3), validate each document’s permission individually and return only the ones the user is authorized to access.

内容的提问来源于stack exchange，提问作者Mladen Oršolić