feat: Implement syntactic sugar and site-specific discovery config
- Add syntactic sugar for container transformation: .insertr containers → children get .insertr - Fix discovery auto-running when disabled with site-specific config loading - Add comprehensive styling test examples for HTML attribute preservation - Include test input for syntactic sugar validation - Update discovery defaults to respect developer intent (disabled by default)
This commit is contained in:
51
TODO.md
51
TODO.md
@@ -484,3 +484,54 @@ The HTTP server has been successfully implemented and is production-ready:
|
||||
5. **✅ Performance** - Static file serving with dynamic content injection
|
||||
6. **✅ Multi-Site** - Single server manages multiple enhanced sites
|
||||
7. **✅ Zero Downtime** - Updates don't require site rebuilds or deploys
|
||||
|
||||
## 🎯 **Future Class Extensions: Advanced Access Control** (Planned)
|
||||
|
||||
### **Granular Permission System for `.insertr-gate`**
|
||||
|
||||
**Current Implementation**: Simple boolean authentication gate for page-level editing access.
|
||||
|
||||
**Future Enhancement Concept**: Role-based access control and section-level permissions for enterprise applications.
|
||||
|
||||
#### **Potential Extended Gate Classes**
|
||||
```html
|
||||
<!-- Current: Simple page-level auth -->
|
||||
<div class="insertr-gate"></div>
|
||||
|
||||
<!-- Future: Role-based section permissions -->
|
||||
<div class="admin-content insertr-gate-admin">
|
||||
<div class="insertr-add">Admin-only dynamic content</div>
|
||||
</div>
|
||||
|
||||
<div class="editor-section insertr-gate-editor">
|
||||
<div class="insertr-content">Editor-level rich content</div>
|
||||
</div>
|
||||
|
||||
<div class="premium-content insertr-gate-premium" data-auth-level="subscription">
|
||||
<div class="insertr">Premium subscriber content</div>
|
||||
</div>
|
||||
```
|
||||
|
||||
#### **Enterprise Use Cases**
|
||||
- **Multi-tenant Applications**: Different organizations editing separate content areas
|
||||
- **Editorial Workflows**: Writers, editors, and admins with different capabilities
|
||||
- **Subscription Content**: Different content areas for different subscription tiers
|
||||
- **Department Permissions**: Marketing vs Engineering vs Sales content areas
|
||||
- **Geographic Restrictions**: Region-specific editing permissions
|
||||
|
||||
#### **Implementation Considerations**
|
||||
- **Configuration Complexity**: How to maintain zero-config philosophy while supporting complex permissions
|
||||
- **Role Definition**: Where and how to define roles and permissions
|
||||
- **Authentication Integration**: Extending current auth system vs external RBAC systems
|
||||
- **Fallback Behavior**: Graceful degradation for unauthorized users
|
||||
- **Performance Impact**: Permission checks shouldn't slow down regular site visitors
|
||||
|
||||
#### **Integration Points**
|
||||
- **Authentik OIDC**: Leverage existing auth provider for role information
|
||||
- **Database Schema**: Extend current content system with permission metadata
|
||||
- **API Endpoints**: New endpoints for permission management and validation
|
||||
- **Editor Interface**: Dynamic interface based on user permissions
|
||||
|
||||
**Priority**: Low - implement after core functionality is stable and enterprise customers request advanced permissions.
|
||||
|
||||
**Design Principle**: Keep simple `.insertr-gate` as default, add optional complexity only when needed.
|
||||
|
||||
Reference in New Issue
Block a user