93 lines
3.7 KiB
Markdown
93 lines
3.7 KiB
Markdown
|
# Authentication Specification
|
||
|
|
|
||
|
|
## Overview
|
||
|
|
|
||
|
|
The QuickNotes application is designed primarily for local use and does not currently implement a comprehensive authentication system. This document outlines the current state of authentication in the application and potential future enhancements.
|
||
|
|
|
||
|
|
## Current Implementation
|
||
|
|
|
||
|
|
### Local Usage Model
|
||
|
|
|
||
|
|
QuickNotes currently operates on a local-only model:
|
||
|
|
|
||
|
|
1. The application runs as a local server on the user's machine
|
||
|
|
2. Access is restricted to localhost connections
|
||
|
|
3. No user accounts or login functionality is implemented
|
||
|
|
4. All data is stored locally in the SQLite database
|
||
|
|
|
||
|
|
### Security Considerations
|
||
|
|
|
||
|
|
Despite the lack of formal authentication, the application implements several security measures:
|
||
|
|
|
||
|
|
1. **Trusted Proxies**: The application only trusts loopback addresses (127.0.0.1, ::1)
|
||
|
|
2. **Input Validation**: All user inputs are validated to prevent injection attacks
|
||
|
|
3. **Content Security Policy**: Headers are set to prevent cross-site scripting
|
||
|
|
4. **CSRF Protection**: The application includes measures to prevent cross-site request forgery
|
||
|
|
|
||
|
|
## Potential Future Authentication
|
||
|
|
|
||
|
|
If authentication were to be implemented in the future, the following approach could be adopted:
|
||
|
|
|
||
|
|
### User Model
|
||
|
|
|
||
|
|
A potential `User` entity would have the following attributes:
|
||
|
|
|
||
|
|
| Field | Type | Description |
|
||
|
|
|-------|------|-------------|
|
||
|
|
| ID | string | Unique identifier for the user (UUID) |
|
||
|
|
| Username | string | Username for login |
|
||
|
|
| PasswordHash | string | Hashed password (not stored in plaintext) |
|
||
|
|
| Email | string | User's email address |
|
||
|
|
| CreatedAt | timestamp | When the user account was created |
|
||
|
|
| UpdatedAt | timestamp | When the user account was last updated |
|
||
|
|
|
||
|
|
### Authentication Flow
|
||
|
|
|
||
|
|
1. **Registration**: Users would create an account with a username and password
|
||
|
|
2. **Login**: Users would authenticate with their credentials
|
||
|
|
3. **Session Management**: Authenticated sessions would be maintained using JWT or session cookies
|
||
|
|
4. **Logout**: Users would be able to terminate their sessions
|
||
|
|
|
||
|
|
### API Endpoints
|
||
|
|
|
||
|
|
| Method | Endpoint | Description |
|
||
|
|
|--------|----------|-------------|
|
||
|
|
| POST | /api/auth/register | Register a new user |
|
||
|
|
| POST | /api/auth/login | Authenticate a user |
|
||
|
|
| POST | /api/auth/logout | End a user's session |
|
||
|
|
| GET | /api/auth/me | Get the current user's information |
|
||
|
|
| PUT | /api/auth/password | Change a user's password |
|
||
|
|
|
||
|
|
### Multi-User Support
|
||
|
|
|
||
|
|
With authentication, the application could support multiple users:
|
||
|
|
|
||
|
|
1. **Data Isolation**: Each user would only see their own notes, readlist items, and feeds
|
||
|
|
2. **User Preferences**: Users could have individual settings and preferences
|
||
|
|
3. **Sharing**: Users could optionally share specific notes or collections with other users
|
||
|
|
|
||
|
|
### Security Enhancements
|
||
|
|
|
||
|
|
Authentication would bring additional security measures:
|
||
|
|
|
||
|
|
1. **Password Hashing**: Using bcrypt or Argon2 for secure password storage
|
||
|
|
2. **Rate Limiting**: Preventing brute force attacks
|
||
|
|
3. **Two-Factor Authentication**: Optional additional security layer
|
||
|
|
4. **API Tokens**: For programmatic access to the API
|
||
|
|
|
||
|
|
## Integration with Emacs Mode
|
||
|
|
|
||
|
|
The Emacs mode would need to be updated to support authentication:
|
||
|
|
|
||
|
|
1. **Credential Storage**: Securely storing user credentials
|
||
|
|
2. **Authentication Flow**: Handling login and session management
|
||
|
|
3. **Token Refresh**: Automatically refreshing expired tokens
|
||
|
|
|
||
|
|
## Implementation Considerations
|
||
|
|
|
||
|
|
If authentication were to be implemented, the following considerations would be important:
|
||
|
|
|
||
|
|
1. **Backward Compatibility**: Ensuring existing data can be migrated to user accounts
|
||
|
|
2. **Simplicity**: Maintaining the application's ease of use
|
||
|
|
3. **Privacy**: Ensuring user data remains private and secure
|
||
|
|
4. **Performance**: Minimizing the performance impact of authentication checks
|