Repository navigation
[Backend]: Implement Protected Share Links with Expire Policies #24
Description
🧭 Project Area
Security / Compliance
📝 Issue Summary and Problem Description
- Issue summary: Allow users to create safe, temporary sharing URLs.
- Problem description: Sharing documents currently relies on raw file access which has no expiry or access logging.
- Why this is important: Real-world document management requires time-limited access and access token revocation.
- Who is affected: Users sharing documents with external entities.
🔍 Current and Expected Behaviour
- Current behaviour: No sharing model or endpoints exist in the system.
- Expected behaviour: Users request a share token (POST /api/documents/:id/share-links) with an expiration timestamp. External guests access the document via GET /api/share/:token.
🧩 Reproduction and Evidence
Step 1: Design the Share Link Feature
Step 2: Create the Share Link Database Model
Step 3: Create the Share Link Controller
Step 4: Create Protected Share Link API Routes🎯 Affected Scope
- Affected files: New files under backend/src/models/share.model.js, backend/src/controllers/share.controller.js, backend/src/routes/share.routes.js
- Database changes required?: Yes (ShareLink collection)
🖥 Environment
- Proposed solution: Generate secure, random tokens using Node's crypto module. Store these tokens with expiration dates. Add endpoint middleware to validate share link validity before streaming files.
- Difficulty: Intermediate
💡 Solution, Alternatives, and Estimate
- Priority: P1 High
✅ Acceptance Criteria and Additional Notes
-Requirement one
🤝 Contributor Checklist
- I have searched existing issues and pull requests for duplicates.
- I can reproduce the issue, or I have clearly explained why reproduction is not applicable.
- I will follow the contribution guidelines and target
ecsoc-2026. - I agree to follow the Code of Conduct.
- I have removed secrets, private documents, and personal data.
Activity
Yuva-Deekshitha-N commentedon Jul 11, 2026
Hi! I'd like to work on this issue under ECSoC26. Before I start, I have a couple of implementation questions:
crypto.randomBytes) stored in the database, or do you prefer a signed token (e.g., JWT)?POST /api/documents/:id/share-linksendpoint be restricted to the document owner only, or should users with edit/admin permissions also be able to generate share links?GET /api/share/:token, should we stream the file directly, or should it return document metadata first and provide a separate download endpoint?Once these details are confirmed, I'll proceed with the implementation.
Krishnx21 commentedon Jul 11, 2026
Thanks for the questions! Here are the implementation decisions for this issue:
1.Share Token
Use a random opaque token generated with crypto.randomBytes().
Store only a hashed version of the token in the database (similar to password reset tokens). Do not use JWT for share links.
2.Token Usage
Share links should be multi-use.
They remain valid until they expire or are manually revoked.
3.Permissions
Only the document owner can create, revoke, or manage share links.
Edit/admin permissions can be considered in a future enhancement, but they are out of scope for this issue.
4.GET /api/share/:token
Validate the token and return the document metadata first.
Provide a separate secure download endpoint rather than streaming the file directly. This keeps the design more flexible and easier to extend.
5.Scope
Please implement:
Secure token generation
Token hashing/storage
Expiration validation
Manual revocation
Basic access logging (timestamp, IP, user agent if available)
More advanced analytics or auditing can be handled in future issues.