- admin/api/upload-splash.php had NO admin-auth check (included the public
customer header, not admin/includes/header.php) and both upload endpoints
trusted the client-supplied MIME type and filename extension, so an
attacker could name a file "shell.php", spoof Content-Type: image/png,
and get PHP written into a web-reachable uploads/ directory. Added
AdminAuth check and centralized real-content validation (getimagesize +
server-side extension mapping) in a new handleImageUpload() helper used
by both admin/upload-image.php and admin/api/upload-splash.php.
- Removed CURLOPT_SSL_VERIFYPEER => false from the CyberMail email calls
in includes/email.php and includes/functions.php (MITM risk on the API
key). Rewrote functions.php's sendEmail() as a thin wrapper around
Email::send() so there's one implementation instead of two that could
drift (this is what had the second copy of the TLS bypass).
- Escaped customer-controlled fields (customer_name, tracking info, reset
URL) before interpolating into outbound HTML emails — name is free text
from registration/checkout with no length/char restriction, so it was
stored-HTML-injectable into every transactional email.
- Fixed api/redeem-gift-card.php referencing a nonexistent `balance` column
on gift_cards (actual column is current_balance) — gift card redemption
was completely broken, always returning "no remaining balance".
- Fixed api/submit-review.php inserting into nonexistent `content`/`status`
columns on reviews (actual columns are `comment`/`is_approved`) — review
submission was crashing on every request.
- Hardened .htaccess: block /db/*, /.git/*, and *.sql. Live site currently
serves db/schema.sql and the full .git directory (including .git/config,
which contains a GitHub PAT with push access) over HTTP — the existing
config/includes RedirectMatch rules are also not being enforced live,
see report for details; this needs a server-level fix too.
- Cleaned up README's leftover install instructions pointing at a deleted
create-admin.php with a documented default password.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- LoyaltyProgram now loads tiers from loyalty_tiers DB table in constructor
with fallback to hardcoded defaults if table is empty
- awardPoints() accepts order_id param with duplicate-prevention check so
points cannot be double-awarded for the same order
- Inserts balance_after into loyalty_transactions for accurate history
- payment-status.php: award points after Stripe checkout session or
PaymentIntent confirmed as paid
- create-checkout-session.php: award points in demo mode payment path
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
DB column is stripe_session_id but code was writing to stripe_checkout_session,
causing a 500 on checkout and breaking payment status checks.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Mirrors the checkout.session.completed case which checks
payment_status === paid before acting. Now checks data.status
=== succeeded on the PaymentIntent object, consistent with how
Stripe structures the event and defensive against any future
edge case where the event fires in a non-final state.
Replaced local sendOrderConfirmationEmail() with emailService()->sendOrderConfirmation().
Order confirmations now log to email_log table and use the branded template
(orange header, full subtotal/tax/discount breakdown) instead of the minimal
brown-header version that was invisible to the admin Email Log.
When using Stripe Checkout, both checkout.session.completed and
payment_intent.succeeded fire for the same payment. After the stripe.php
change propagated order_id into PI metadata, the PI handler also found
an order_id and sent a second confirmation email.
Fix: fetch the order first in payment_intent.succeeded and skip if
already confirmed. Also records stripe_payment_intent in this path
for direct PI flows that bypass checkout.session.completed.
myron