Access Control

Overview

The access control system restricts storefront access to approved B2B customers. It uses IP-based tracking with an admin approval workflow.

How It Works

Customer visits storefront
        │
        ▼
  Gatekeeper checks IP
        │
   ┌────┴────┐
   │ Approved │──► Full storefront access
   └─────────┘
   │ Pending  │──► "Your request is being reviewed" message
   └─────────┘
   │ Rejected │──► "Access denied" message
   └─────────┘
   │ None     │──► Show access request form
   └─────────┘

Enable/Disable

Set NEXT_PUBLIC_GATEKEEPER_ENABLED=true in the storefront environment to enable the gatekeeper.

When disabled, all visitors have full access.

Public Paths

These paths are always accessible, even when the gatekeeper is enabled:

• /toegang — Access request page
• /privacy — Privacy policy
• /terms — Terms of service
• /contact — Contact form

API Endpoints

Check Access (Storefront)

GET /store/access-check

Returns the current IP’s access status:

{
  "has_access": true,
  "status": "approved",
  "message": "Access granted"
}

IP detection checks headers in order:

1. x-forwarded-for
2. x-real-ip
3. socket.remoteAddress

Request Access (Storefront)

POST /store/access-request
{
  "name": "John Doe",
  "email": "john@company.nl",
  "company": "Company B.V.",
  "message": "Would like access for B2B ordering"
}

Manage Requests (Admin)

GET    /admin/aplt/access-requests           # List pending requests
PUT    /admin/aplt/access-requests/[id]      # Approve or reject

Database Table

aplt_access_requests

Column	Type	Purpose
id	int	Primary key
ip_address	varchar	Requesting IP
email	varchar	Requester email
company	varchar	Company name
message	text	Request message
status	varchar	pending, approved, rejected
approved_by	varchar	Admin who approved
approved_at	timestamp	When approved
created_at	timestamp	Request date

Admin UI

Access requests are managed at Admin Panel → ADVANCED → Access Requests (/admin/22-access-requests).