[ic] Error in strap for interchange e-commerce.

[davideth at whojamadoogle.com]

Thanks,


As a note: I have been working on a cgi ( written in C for speed )  that 
can be called through .htaccess redirects. The cgi checks for a specific 
cookie and if not present it send the checkbox. Each call to the cgi 
checks for the cookie, if no cookie, it send the checkbox again.  If the 
cookie is present, the current env and requests, etc. is passed to the 
interchange cgi. The cookie is set to time out after 30 days.


This eliminates the overhead of interchange, logging, session files, 
etc. unless the customer checks the valid human checkbox, allowing the 
cookie to be sent.


As per your message: What the AI replied with:

Where and What Happens on an Initial Page Request?

Interchange handles page request flows primarily through Core Perl 
modules located under the lib/Vend/ directory.

The Entry Point (src/vlink.c or tlink.c): Interchange uses a lightweight 
binary (C program) called vlink (CGI mode) or tlink (UNIX domain 
socket/TCP mode). When a web server (like Apache or Nginx) receives a 
request for the main page, it executes vlink or forwards the request to it.

The Handshake (lib/Vend/Server.pm): The link program forwards the 
request environment variables and CGI parameters over a socket to the 
main Interchange daemon (interchange). The daemon listens and catches it 
inside lib/Vend/Server.pm.

The Core Processor (lib/Vend/Dispatch.pm): This is where the magic 
happens. Vend::Server parses the incoming connection data and hands 
control off to the core dispatcher method: sub dispatch inside 
lib/Vend/Dispatch.pm.

What happens step-by-step in dispatch for a first-time user:CGI Parsing: 
It reads and standardizes the incoming headers and parameters 
(adjust_cgi()).Session Initiation: It calls out to lib/Vend/Session.pm 
to look up or establish a session.

For a first-time user, Interchange realizes no session ID exists in the 
query string or cookie headers. It automatically generates a unique 
string (the session ID) and provisions an empty in-memory session 
structure ($Vend::Session).Action/

Page Mapping: It looks for the target page (e.g., index.html or the 
catalog's default home page specified by your configuration).

Parsing & Interpolation: It passes the template to the Interchange Tag 
Language (ITL) parser (Vend::Interpolate), executes any logic embedded 
on the landing page, fetches database products, and builds the HTML 
response.

2. At What Point Does Interchange Place a Cookie?

The session cookie is initialized early but injected into the client 
response during the execution of lib/Vend/Dispatch.pm.Inside sub 
dispatch, after a session ID has been successfully generated or assigned 
to the user,

Interchange verifies its cookie tracking rules. Look for logic similar 
to:Perl# Set a cookie if applicable.
if ( ... ) {
     # It builds the HTTP 'Set-Cookie' header mapping the MV_SESSIONID
}

If cookies are enabled (CookiePattern or default session configuration), 
Interchange places the MV_SESSIONID cookie into the HTTP headers 
immediately after the session initialization block within Dispatch.pm 
but before the page output is streamed back to the user.

By the time the response containing the HTML for the "main page" leaves 
the Interchange application daemon, the Set-Cookie tracking string is 
already embedded in the response headers.

3. The Best Place to Send a Checkbox Page (Mitigating Spoofed IP DDoS)

You are looking to deliver a checkbox page (similar to a custom 
Captcha/turnstile challenge) and isolate the client until they 
successfully confirm it and accept a cookie.

Architectural Warning: Don't do this inside Interchange!Because you 
mentioned "preventing a new form of DDoS that sends requests from 
fake/spoofed IPs," handling this inside the Interchange daemon 
(lib/Vend/Dispatch.pm or Session.pm) will fail to protect your server. * 
Interchange is built on Perl. Spawning a Perl instance, processing 
session generation code, and invoking

Dispatch.pm for every malicious packet consumes a massive amount of CPU 
and memory.If an attacker hits you with a DDoS using spoofed IPs, the 
Interchange process table will exhaust immediately, throwing 500/504 
gateway errors.

The Recommended Strategy (Reverse Proxy Layer)To completely stop a 
spoofed-IP DDoS attack before it consumes your application's resources, 
you should handle this constraint at the Web Server (Nginx/Apache) or a 
Reverse Proxy / Firewall layer (like Cloudflare, OpenResty, or an 
iptables/nftables layer)—not inside Interchange.

If you must manage it locally on your server, the best configuration is 
using an Nginx Layer positioned in front of your Interchange vlink/tlink 
socket:

The Handshake / Cookie Test: When a request hits Nginx, Nginx checks for 
a specific verified verification cookie (e.g., Validated_User=true).The 
Interception: If the cookie is missing, Nginx intercepts the request 
before passing it downstream to Interchange. Nginx serves a lightweight, 
static HTML challenge page containing your checkbox directly from 
memory.Validating the Spoofed IP: Because a TCP handshake requires a 
3-way completion (SYN $\rightarrow$ SYN-ACK $\rightarrow$ ACK), an 
attacker spoofing random fake IPs cannot complete a 3-way handshake. 
They will never receive your checkbox page, and they cannot send back a 
response form.

Setting the Cookie: When a legitimate client clicks your checkbox, the 
form submits to a lightweight Nginx endpoint (or a highly isolated Lua 
script via OpenResty). This endpoint generates the validated cookie on 
the client computer and redirects them to the main catalog page.Passing 
to Interchange:

Now that the client has the Validated_User cookie, Nginx allows future 
requests to safely pass straight through to Interchange (vlink/tlink).If 
you absolutely must do it inside Interchange:If your network layout 
restricts you to writing this inside Interchange's codebase, the only 
clean gateway to achieve this is at the absolute beginning of sub 
dispatch in lib/Vend/Dispatch.pm:

Open lib/Vend/Dispatch.pm.At the very top of sub dispatch { ... }, right 
after the CGI arguments are read (adjust_cgi();), inject a custom 
subroutine hook checking the user's browser environment.If they don't 
have your custom validation cookie, you must short-circuit the entire 
method, bypass standard session generation entirely, assign a raw 
hardcoded HTML string (your checkbox form) to @Vend::Output, and 
immediately return or call $H->respond(). This keeps Interchange from 
running heavy database lookups or session-writing overhead for 
unverified bots.


On 5/20/26 11:48, davideth at whojamadoogle.com wrote:
> Is there any documentation available about how interchange does its 
> initial processing for a requested page.
>
> I am looking in particular as to where and what happens when ab 
> initial page request is received.
>
> For example when a first time user requests to see the main page.
>
> Also, at what point does interchange place a cookie on the requester's 
> computer.
>
> I am looking for the best place to send the user a checkbox page and 
> then place that IP address on hold until a response is received and a 
> 'valid' cookie is placed on the requester's device.
>
> I had asked about this a while back, did receive some help but 
> apparently, it needs to be improved to prevent a new form of DDos that 
> send requests from fake IPs.
>
> Any help would be appreciated.
>
>
> Thanks, David
>
>