Add password protection for documents and directories

[Copilot]

Implements password-based access control for documents and directories. Authentication flow: check standard permissions first, then password if protected. Returns 202 when password required but missing, 403 when incorrect.

Database Schema

• New object_protections table (single unified table for all protection types)
• Columns: target_type, target_id, protection_type, protection_data, protection_metadata
• protection_type: Distinguishes protection types ('password', 'encryption', 'biometric', etc.)
• protection_data: JSON format storing type-specific data (e.g., password_hash and salt for passwords)
• protection_metadata: Reserved for future extensions

Architecture

• Single unified table: All protection types share one table, distinguished by protection_type column
• Clean BaseObject: Protection logic kept out of base class to avoid bloat
• Handler-based checking: check_password_protection() helper function in handlers performs verification
• Scalable design: Future protection types add methods to ObjectProtection model without modifying BaseObject

Security

• PBKDF2-HMAC-SHA256, 600K iterations (OWASP 2023 minimum)
• Constant-time comparison via secrets.compare_digest() (timing attack prevention)

API Endpoints

# Enable/update protection
{"action": "enable_password_protection", "data": {
    "target_type": "document",  # or "directory"
    "target_id": "...",
    "password": "..."
}}

# Remove protection
{"action": "remove_password_protection", "data": {
    "target_type": "document",
    "target_id": "..."
}}

# Verify password
{"action": "verify_password", "data": {
    "target_type": "document",
    "target_id": "...",
    "password": "..."
}}

Handler Integration

Updated handlers now accept optional password parameter:

• get_document, get_document_info
• list_directory, get_directory_info

# Example: accessing protected document
{"action": "get_document_info", "data": {
    "document_id": "...",
    "password": "..."  # optional, returns 202 if missing and required
}}

Implementation Notes

• check_password_protection() helper function in handlers performs protection checks
• ObjectProtection model contains type-specific methods (e.g., set_password(), verify_password())
• TARGET_TYPE_MAPPING constant maps table names to API types
• BaseObject remains clean with no protection-specific methods

Original prompt

Please implement a function to add password protection to directories or documents. The authentication process is as follows: First, authenticate as you would any other directory or document. Then, check if the accessed object is password protected. If it is password protected and the request did not include a password, return code 202. Obviously, you will need to implement APIs for enabling and removing password protection. If possible, implement this functionality as a separate table in the database structure and use a join query to link it to the main table. This will preserve scalability (allowing for different types of protection to be implemented later). In other words, you need to reserve appropriate columns for scalability.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Creeper19472]

@copilot Several issues exist: 1. You didn't understand what I meant. I meant that for current password protection and all future protection types, they will all share a single table, using a column of type such as "protection" to distinguish their types, instead of splitting each protection type into a separate table as you did before. 2. Don't arbitrarily add functions that are only valid for a specific protection type, such as check_password, to classes like BaseObject, because, as I said, various more protection types are likely to be added in the future. Move this logic to RequestHandler, or ensure that your implemented functions can handle multiple protection types (able to handle one or more protection types being enabled) to avoid making the BaseObject implementation too bloated. After all, it's just a base class.

[Copilot]

@copilot Several issues exist: 1. You didn't understand what I meant. I meant that for current password protection and all future protection types, they will all share a single table, using a column o...

Refactored in commit 09e892b:

1. Single unified table: Renamed to ObjectProtection with protection_type column to distinguish types ('password', 'encryption', 'biometric', etc.) and protection_data as JSON for type-specific data

2. Removed BaseObject methods: Deleted get_password_protection(), is_password_protected(), and verify_password() from BaseObject to keep it clean

3. Logic moved to handlers: Created check_password_protection() helper function in protection handlers. All document/directory handlers now import and use this helper instead of calling BaseObject methods

The design now supports multiple protection types in a single table and keeps BaseObject focused solely on access control.

[Copilot]

Pull request overview

This PR implements password-based access control for documents and directories using a unified protection system. The implementation adds a new object_protections database table that can support multiple protection types (password, encryption, biometric, etc.) distinguished by a protection_type column.

Key Changes

• New password protection database model with PBKDF2-HMAC-SHA256 hashing (600K iterations) and constant-time comparison
• Three new API endpoints for enabling, removing, and verifying password protection
• Integration of password checks into existing document and directory access handlers

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 11 comments.

Show a summary per file

File	Description
tests/test_password_protection.py	Comprehensive test suite covering password protection on documents and directories, including enable/remove/verify operations and access control scenarios
src/main.py	Imports the new ObjectProtection model for database initialization
src/include/handlers/protection.py	New handlers for password protection management and helper function for password verification
src/include/handlers/document.py	Adds optional password parameter to document access endpoints and integrates password protection checks
src/include/handlers/directory.py	Adds optional password parameter to directory access endpoints and integrates password protection checks
src/include/database/models/protection.py	New database model for unified protection system with password hashing and verification methods
src/include/database/models/entity.py	Refactors TARGET_TYPE_MAPPING from local to global constant
src/include/constants.py	Adds TARGET_TYPE_MAPPING constant for mapping database table names to API types
src/include/connection_handler.py	Registers new password protection handlers in the available functions dictionary

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The password validation in the data schema allows empty strings. Similar to enable_password_protection, the password field should have minLength validation to prevent empty passwords from being accepted during verification.

Suggested change

	"password": {"type": "string"}
	"password": {"type": "string", "minLength": 1}

[Copilot]

The check_password_protection function only checks for None password, but doesn't handle empty strings. If a user provides an empty password string in the request, it will be passed to verify_password and processed, which could lead to unexpected behavior. Consider treating empty strings the same as None (password required), or add validation to reject empty password strings.

Suggested change

	if password is None:
	# Password required but not provided
	if password is None or password == "":
	# Password required but not provided or empty

[Copilot]

The database model is missing a unique constraint to prevent duplicate protection entries for the same target. Without a unique constraint on (target_type, target_id, protection_type), multiple password protection entries could be created for the same document or directory, leading to undefined behavior during verification. Consider adding a unique constraint or composite index on these three columns.

[Copilot]

The verify_password handler does not check if the user has read permissions for the target object before allowing password verification. This could allow unauthorized users to perform brute-force password attacks on documents/directories they don't have access to. Standard access permissions should be checked first (similar to how enable_password_protection and remove_password_protection check for manage permissions).

Suggested change

	# Check that the user has read permissions for the target object
	has_read_permission = False
	if hasattr(user, "can_read"):
	# Prefer an explicit can_read(target) capability method if available.
	has_read_permission = bool(user.can_read(target)) # type: ignore[call-arg]
	elif hasattr(user, "has_permission"):
	# Fallback to a generic permission check API, if provided by the User model.
	try:
	has_read_permission = bool(user.has_permission("read", target)) # type: ignore[call-arg]
	except TypeError:
	# In case has_permission has a different signature, fail closed.
	has_read_permission = False
	if not has_read_permission:
	handler.conclude_request(
	403,
	{},
	"You do not have permission to access this object",
	)
	return 403, target_id, handler.username

[Copilot]

The password validation in the data schema allows empty strings (minLength is 1 for target_id but password only has type "string" without minLength). An empty password would be hashed and stored, but this is a poor security practice. Consider adding minLength validation for the password field, or adding explicit validation logic to reject empty passwords.

[Copilot]

The return value (0, "success") for successful password verification is inconsistent with HTTP status code conventions. The function returns tuple[int, str] where 0 represents success, but this is mixed with HTTP status codes (202, 403) for other cases. This could be confusing. Consider using a more consistent approach, such as returning None for success or using a dedicated status code like 200.

[Copilot]

RequestGetDirectoryInfoHandler.handle returns tuple of size 2 and tuple of size 3.
RequestGetDirectoryInfoHandler.handle returns tuple of size 2 and tuple of size 3.
RequestGetDirectoryInfoHandler.handle returns tuple of size 2 and tuple of size 3.
RequestGetDirectoryInfoHandler.handle returns tuple of size 2 and tuple of size 3.
RequestGetDirectoryInfoHandler.handle returns tuple of size 2 and tuple of size 3.
RequestGetDirectoryInfoHandler.handle returns tuple of size 2 and tuple of size 3.
RequestGetDirectoryInfoHandler.handle returns tuple of size 2 and tuple of size 3.
RequestGetDirectoryInfoHandler.handle returns tuple of size 2 and tuple of size 3.

[Copilot]

Import of 'ObjectProtection' is not used.

Suggested change

from include.database.models.protection import ObjectProtection

[Copilot]

'except' clause does nothing but pass and there is no explanatory comment.

Suggested change

	except Exception:
	except Exception:
	# Best-effort cleanup: ignore errors if the directory was already deleted
	# or cannot be removed, so that they do not mask earlier test failures.

[Copilot]

'except' clause does nothing but pass and there is no explanatory comment.

Suggested change

	except Exception:
	except Exception:
	# Best-effort cleanup: ignore errors if the directory is already deleted