From be47884ee0a9fa7061775e4de588215654718db9 Mon Sep 17 00:00:00 2001 From: Andras Bacsai <5845193+andrasbacsai@users.noreply.github.com> Date: Mon, 25 Aug 2025 11:33:27 +0200 Subject: [PATCH] feat(docs): expand authorization documentation for custom Alpine.js components; include manual protection patterns and implementation guidelines --- .cursor/rules/security-patterns.mdc | 153 ++++++++++++++++++++++++++++ 1 file changed, 153 insertions(+) diff --git a/.cursor/rules/security-patterns.mdc b/.cursor/rules/security-patterns.mdc index 104dbd71b..a7ab2ad69 100644 --- a/.cursor/rules/security-patterns.mdc +++ b/.cursor/rules/security-patterns.mdc @@ -227,6 +227,159 @@ public function __construct( - New authorization parameters are optional - Legacy @can/@else patterns still function but are discouraged +### Custom Component Authorization Patterns + +When dealing with **custom Alpine.js components** or complex UI elements that don't use the standard `x-forms.*` components, manual authorization protection is required since the automatic `canGate` system only applies to enhanced form components. + +#### Common Custom Components Requiring Manual Protection + +**⚠️ Custom Components That Need Manual Authorization:** +- Custom dropdowns/selects with Alpine.js +- Complex form widgets with JavaScript interactions +- Multi-step wizards or dynamic forms +- Third-party component integrations +- Custom date/time pickers +- File upload components with drag-and-drop + +#### Manual Authorization Pattern + +**✅ Proper Manual Authorization:** +```html + +
+
+ + +
+ @can('update', $resource) + +
+ +
+ + +
+
+ @else + +
+ + + + +
+ @endcan +
+``` + +#### Implementation Checklist + +When implementing authorization for custom components: + +**🔍 1. Identify Custom Components:** +- Look for Alpine.js `x-data` declarations +- Find components not using `x-forms.*` prefix +- Check for JavaScript-heavy interactions +- Review complex form widgets + +**🛡️ 2. Wrap with Authorization:** +- Use `@can('gate', $resource)` / `@else` / `@endcan` structure +- Provide full functionality in the `@can` block +- Create disabled/readonly version in the `@else` block + +**🎨 3. Design Disabled State:** +- Apply `readonly disabled` attributes to inputs +- Add `opacity-50 cursor-not-allowed` classes for visual feedback +- Remove interactive JavaScript behaviors +- Show current value or appropriate placeholder + +**🔒 4. Backend Protection:** +- Ensure corresponding Livewire methods check authorization +- Add `$this->authorize('gate', $resource)` in relevant methods +- Validate permissions before processing any changes + +#### Real-World Examples + +**Custom Date Range Picker:** +```html +@can('update', $application) +
+ +
+@else +
+ + +
+@endcan +``` + +**Multi-Select Component:** +```html +@can('update', $server) +
+ +
+@else +
+ @foreach($selectedValues as $value) +
+ {{ $value }} +
+ @endforeach +
+@endcan +``` + +**File Upload Widget:** +```html +@can('update', $application) +
+ +
+@else +
+

File upload restricted

+ @if($currentFile) +

Current: {{ $currentFile }}

+ @endif +
+@endcan +``` + +#### Key Principles + +**🎯 Consistency:** +- Maintain similar visual styling between enabled/disabled states +- Use consistent disabled patterns across the application +- Apply the same opacity and cursor styling + +**🔐 Security First:** +- Always implement backend authorization checks +- Never rely solely on frontend hiding/disabling +- Validate permissions on every server action + +**💡 User Experience:** +- Show current values in disabled state when appropriate +- Provide clear visual feedback about restricted access +- Maintain layout stability between states + +**🚀 Performance:** +- Minimize Alpine.js initialization for disabled components +- Avoid loading unnecessary JavaScript for unauthorized users +- Use simple HTML structures for read-only states + ### Team-Based Multi-Tenancy - **[Team.php](mdc:app/Models/Team.php)** - Multi-tenant organization structure (8.9KB, 308 lines) - **[TeamInvitation.php](mdc:app/Models/TeamInvitation.php)** - Secure team collaboration