La sala d'attesa virtuale aziendale

Avvio rapido: vivi in ​​meno di 2 minuti

Proteggi la tua applicazione in meno di 2 minuti: copia il tag script nella tua testa o pubblica il link del gateway. Nessuna modifica all'infrastruttura del tuo server. Solo quando desideri il massimo controllo abiliti le funzionalità avanzate opzionali: tutto il resto in questa pagina è esattamente questo: profondità opzionale per dopo.

1. 1

   Crea una sala d'attesa

   Nella console di amministrazione ADITUS: nome, indirizzo del negozio, tariffa di ingresso al minuto. Le impostazioni predefinite ragionevoli coprono tutto il resto.

2. 2

   Copia una riga

   Pubblica il collegamento del gateway già pronto anziché il collegamento del negozio oppure incolla il tag dello script preparato nella pagina del negozio, esattamente come uno snippet di analisi.

3. 3

   Fatto: la coda è armata

   Al di sotto della tariffa di ingresso i visitatori non vedono mai la sala d'attesa. Solo quando si verifica un picco entra in gioco la coda: ospitata, scalata e gestita da noi.

Cresce con te: tre livelli di protezione

La potenza della coda è un percorso di aggiornamento, non un requisito. Il livello 1 copre da solo la stragrande maggioranza dei casi d’uso.

Integrazione: due opzioni

Quale opzione si adatta dipende da una domanda: è possibile modificare il collegamento del negozio pubblicato? Se sì, il collegamento gateway è la scelta migliore: il traffico non raggiunge mai il negozio prima dell'ingresso. Se l'URL del negozio pubblicato è fisso, il tag script protegge il negozio senza alcuna modifica alla sua pubblicazione. Oltre a questi due, il controllo può essere applicato nel proxy inverso o CDN (sotto), gestito direttamente tramite l'API REST o verificato in qualsiasi linguaggio di backend con una libreria JWT: Node.js, PHP, Java, .NET, Python, Go.

Opzione A: il collegamento gateway (consigliato)

Ogni sala d'attesa fornisce il proprio URL di ingresso. Viene pubblicato ovunque venga altrimenti visualizzato il collegamento al negozio: newsletter, sito Web, social media. La coda prende la richiesta e decide lato server in un unico passaggio: al di sotto della tariffa di ingresso il visitatore viene indirizzato direttamente all'indirizzo del negozio configurato e non si accorge minimamente della coda; una volta superata la tariffa, il visitatore atterra nella sala d'attesa e viene inoltrato automaticamente al suo turno. Il negozio stesso non riceve traffico prima dell'ingresso: le richieste vengono assorbite prima di raggiungere l'infrastruttura del negozio.

<!-- Der veröffentlichte Shop-Link zeigt auf die Queue statt auf den Shop: -->
<a href="https://developers.aditus.com/queue/<slug>/enter">Tickets kaufen</a>

Per questa opzione è necessario configurare l'indirizzo di destinazione del negozio (Ziel-URL) per la coda: è l'indirizzo a cui vengono reindirizzati i visitatori ammessi. I visitatori ammessi arrivano al negozio con un token di ingresso firmato nell'URL: un JWT HS256 standard che il negozio può facoltativamente verificare offline nel proprio backend utilizzando il segreto condiviso.La struttura, le affermazioni e un esempio di backend sono documentati di seguito. Nota: il gateway protegge il punto di ingresso pubblicato; i visitatori che conoscono direttamente l'URL del negozio possono comunque ignorarlo. Se è importante, combina il collegamento del gateway con il tag script o verifica il token nel backend del negozio.

Opzione B: il tag script

Quando il collegamento al negozio pubblicato non può essere modificato, l'integrazione è un singolo tag script. Viene consegnato insieme alle pagine del negozio – nello stesso modo in cui viene consegnato uno snippet di analisi – e deve essere presente su ogni pagina che la sala d'attesa dovrebbe proteggere. Si consiglia il posizionamento in <head> con l'attributo defer; la posizione esatta non è critica.

<!-- Auf jeder zu schützenden Shop-Seite im <head>: -->
<script src="https://developers.aditus.com/queue/<slug>/embed.js" defer></script>

Il tag esatto per una sala d'attesa specifica, con lo slug corretto già inserito, è disponibile nella console di amministrazione ADITUS per coda. Lo script esegue tre controlli ad ogni caricamento della pagina:

1. 1

   Il visitatore è in possesso di un pass valido

   Non succede nulla. Il pass viene memorizzato per sessione del browser; il visitatore utilizza il negozio senza interruzioni.

2. 2

   Il visitatore ritorna dalla sala d'attesa

   Il token di ammissione nell'URL viene verificato lato server (firma, assegnazione coda, scadenza). Se valido, viene archiviato un pass di sessione e il token viene rimosso dalla barra degli indirizzi. I gettoni non validi o scaduti rimandano il visitatore alla sala d'attesa.

3. 3

   Il visitatore non ha pass

   Se nessuno sta aspettando, il visitatore viene ammesso silenziosamente in background e rimane sulla pagina: la sala d'attesa non viene mai mostrata. Solo quando viene superata la tariffa di ingresso configurata e si forma una coda il visitatore viene reindirizzato nella sala d'attesa; la pagina corrente viene trasmessa come URL di ritorno convalidato, quindi dopo l'ammissione il visitatore arriva esattamente alla pagina originariamente richiesta.

Hardening: imporre l'ammissione al proxy edge

Entrambe le opzioni sopra proteggono il punto di ingresso pubblicato. Se il negozio deve essere irraggiungibile senza ingresso anche per i visitatori che ne conoscono direttamente l'URL, l'assegno si sposta davanti al negozio, nel proxy inverso o CDN che ne termina il traffico. La logica è sempre la stessa in tre passaggi: prendere il token dal parametro URL aditus_queue_token quando il visitatore ritorna dalla sala d'attesa e memorizzarlo come cookie; ad ogni richiesta, verificare il token dal cookie come un JWT HS256 standard con il segreto condiviso (emittente aditus-queue, audience lo slug della coda, scadenza); senza un token valido, reindirizza alla sala d'attesa su https://developers.aditus.com/queue/<slug>. La verifica è offline: il proxy non chiama mai la coda e non aggiunge latenza. Gli schizzi seguenti mostrano lo schema di quattro ambienti comuni; adattateli al vostro setup.

# Skizze: Nginx mit njs (js_import) — prüft den Zugriffs-Token als HS256-JWT
# direkt am Proxy, ohne Rückruf an die Queue. An die eigene Umgebung anpassen.

# nginx.conf:
#   env ADITUS_QUEUE_SECRET;
#   js_import queue from /etc/nginx/queue.js;
#   server {
#     location /       { js_content queue.gate; }
#     location @shop   { proxy_pass http://shop_backend; }
#   }

// /etc/nginx/queue.js:
const crypto = require('crypto');
const SLUG = '<slug>';
const SECRET = process.env.ADITUS_QUEUE_SECRET; // Shared Secret der Queue

function claims(token) {
  const p = token.split('.');
  if (p.length !== 3) return null;
  const sig = crypto.createHmac('sha256', SECRET)
    .update(p[0] + '.' + p[1]).digest('base64url');
  if (sig !== p[2]) return null;
  const c = JSON.parse(Buffer.from(p[1], 'base64url'));
  const ok = c.iss === 'aditus-queue' && c.aud === SLUG && c.exp > Date.now() / 1000;
  return ok ? c : null;
}

function gate(r) {
  const fromUrl = r.args.aditus_queue_token;
  const m = (r.headersIn.Cookie || '').match(/(?:^|;\s*)aditus_queue=([^;]+)/);
  const token = fromUrl || (m && m[1]);
  if (!token || !claims(token)) {
    // Kein gültiger Token -> zurück in den Warteraum
    r.return(302, 'https://developers.aditus.com/queue/' + SLUG);
    return;
  }
  if (fromUrl) {
    // Token aus der Rücksprung-URL in ein Sitzungs-Cookie übernehmen
    r.headersOut['Set-Cookie'] =
      'aditus_queue=' + fromUrl + '; Path=/; Secure; HttpOnly; Max-Age=600';
  }
  r.internalRedirect('@shop');
}

export default { gate };

# Skizze: Caddy mit dem jwtauth-Plugin (github.com/ggicci/caddy-jwt).
# Token kommt beim Rücksprung als ?aditus_queue_token=… oder danach als Cookie;
# jwtauth prüft beide Quellen. An die eigene Umgebung anpassen.
shop.example.com {
  route {
    jwtauth {
      sign_key {env.ADITUS_QUEUE_SECRET}
      sign_alg HS256
      from_query aditus_queue_token
      from_cookies aditus_queue
      issuer_whitelist aditus-queue
      audience_whitelist <slug>
      user_claims qnr
    }
    # Token aus der URL einmalig in ein Cookie übernehmen
    @rueckkehr query aditus_queue_token=*
    header @rueckkehr Set-Cookie "aditus_queue={http.request.uri.query.aditus_queue_token}; Path=/; Secure; HttpOnly; Max-Age=600"
    reverse_proxy shop_backend:8080
  }
  # Ohne gültigen Token: zurück in den Warteraum
  handle_errors {
    @unauth expression {http.error.status_code} == 401
    redir @unauth https://developers.aditus.com/queue/<slug> 302
  }
}

// Skizze: Cloudflare Worker vor dem Shop — prüft den HS256-JWT offline per
// WebCrypto. Secret als Worker-Secret ADITUS_QUEUE_SECRET hinterlegen.
const SLUG = "<slug>";
const ROOM = "https://developers.aditus.com/queue/" + SLUG;

export default {
  async fetch(req, env) {
    const url = new URL(req.url);
    const fromUrl = url.searchParams.get("aditus_queue_token");
    const m = (req.headers.get("Cookie") || "").match(/(?:^|;\s*)aditus_queue=([^;]+)/);
    const token = fromUrl || (m && m[1]);
    if (!token || !(await valid(token, env.ADITUS_QUEUE_SECRET))) {
      return Response.redirect(ROOM, 302); // zurück in den Warteraum
    }
    if (fromUrl) {
      // Token in ein Cookie übernehmen und die URL bereinigen
      url.searchParams.delete("aditus_queue_token");
      return new Response(null, {
        status: 302,
        headers: {
          Location: url.toString(),
          "Set-Cookie": "aditus_queue=" + token +
            "; Path=/; Secure; HttpOnly; Max-Age=600",
        },
      });
    }
    return fetch(req); // gültiger Pass -> durch zum Shop
  },
};

async function valid(token, secret) {
  const p = token.split(".");
  if (p.length !== 3) return false;
  const key = await crypto.subtle.importKey(
    "raw", new TextEncoder().encode(secret),
    { name: "HMAC", hash: "SHA-256" }, false, ["verify"],
  );
  const ok = await crypto.subtle.verify(
    "HMAC", key, b64url(p[2]),
    new TextEncoder().encode(p[0] + "." + p[1]),
  );
  if (!ok) return false;
  const c = JSON.parse(new TextDecoder().decode(b64url(p[1])));
  return c.iss === "aditus-queue" && c.aud === SLUG && c.exp > Date.now() / 1000;
}

function b64url(v) {
  return Uint8Array.from(
    atob(v.replace(/-/g, "+").replace(/_/g, "/")),
    (ch) => ch.charCodeAt(0),
  );
}

// Skizze: AWS CloudFront mit Lambda@Edge (Viewer-Request, Node.js).
// Gleiches Muster: Token aus ?aditus_queue_token oder Cookie, HS256 offline
// prüfen, ohne gültigen Token in den Warteraum umleiten.
// Hinweis: Lambda@Edge hat keine Umgebungsvariablen — das Secret z. B. beim
// Deployment einbetten oder aus SSM/Secrets Manager cachen.
'use strict';
const crypto = require('crypto');
const SLUG = '<slug>';
const ROOM = 'https://developers.aditus.com/queue/' + SLUG;
const SECRET = '<ADITUS_QUEUE_SECRET>';

exports.handler = async (event) => {
  const req = event.Records[0].cf.request;
  const qs = new URLSearchParams(req.querystring || '');
  const fromUrl = qs.get('aditus_queue_token');
  const cookie = (req.headers.cookie || []).map((h) => h.value).join('; ');
  const m = cookie.match(/(?:^|;\s*)aditus_queue=([^;]+)/);
  const token = fromUrl || (m && m[1]);

  if (!token || !valid(token)) {
    return redirect(ROOM); // zurück in den Warteraum
  }
  if (fromUrl) {
    // Token in ein Cookie übernehmen und die URL bereinigen
    qs.delete('aditus_queue_token');
    const clean = req.uri + (qs.toString() ? '?' + qs.toString() : '');
    return redirect(clean, {
      'set-cookie': [{ key: 'Set-Cookie', value:
        'aditus_queue=' + token + '; Path=/; Secure; HttpOnly; Max-Age=600' }],
    });
  }
  return req; // gültiger Pass -> durch zum Shop (Origin)
};

function valid(token) {
  const p = token.split('.');
  if (p.length !== 3) return false;
  const sig = crypto.createHmac('sha256', SECRET)
    .update(p[0] + '.' + p[1]).digest();
  const got = Buffer.from(p[2], 'base64url');
  if (got.length !== sig.length || !crypto.timingSafeEqual(sig, got)) {
    return false;
  }
  const c = JSON.parse(Buffer.from(p[1], 'base64url'));
  return c.iss === 'aditus-queue' && c.aud === SLUG && c.exp > Date.now() / 1000;
}

function redirect(location, extraHeaders) {
  return {
    status: '302',
    headers: Object.assign(
      { location: [{ key: 'Location', value: location }] },
      extraHeaders || {},
    ),
  };
}

Nota: con l'applicazione dei limiti, ogni visitatore ha bisogno di un token, compresi quelli che altrimenti passerebbero silenziosamente al di sotto della tariffa di ammissione. Pubblica il collegamento del gateway (opzione A) accanto ad esso o lascia che il proxy reindirizzi i visitatori senza token alla sala d'attesa, che emette immediatamente un token mentre nessuno sta aspettando.

Dettagli tecnici

Le seguenti sezioni non sono necessarie per l'integrazione: il tag script riportato sopra è completo. Documentano come funziona il sistema per la valutazione tecnica e per i negozi che desiderano verificare l'ammissione nel proprio backend.

Come funziona l'ammissione

A ogni visitatore viene assegnato un numero di attesa sequenziale mediante un singolo incremento atomico del database. L'ammissione avanza continuamente: il numero attualmente ammesso è calcolato come base + tariffa × minuti trascorsi. Il polling dello stato è di sola lettura e non tocca il database per richiesta. Non esiste uno stato per visitatore sul server, nessun processo cron e nessun timer: il servizio di coda stesso non può diventare un collo di bottiglia sotto carico. La sospensione di una coda interrompe sia l'ingresso che l'emissione di nuovi numeri; le variazioni tariffarie sono continue ed il numero degli ammessi non diminuisce mai.

Equità: rigorosamente primo arrivato, primo servito

L'ingresso è rigorosamente first-come-first-served (FCFS): l'incremento atomico fissa la posizione di ciascun visitatore al momento dell'ingresso, e le posizioni non cambiano mai successivamente. Non c'è deliberatamente alcuna lotteria, nessuna randomizzazione e nessuna corsia prioritaria: in condizioni di scarsità, l'ordine di arrivo è l'unico ordine che i visitatori accettano come giusto, ed è l'unico su cui non è possibile giocare. Il salto della coda è tecnicamente escluso su due livelli: i numeri in attesa crescono sempre e il controllo di ammissione confronta il numero del visitatore con il numero attualmente ammesso sul server - il token di ammissione viene emesso solo una volta superato il controllo, firmato con il segreto della coda. Un visitatore non può rivendicare una posizione migliore e un token contraffatto non supera la verifica della firma. Gli operatori che necessitano di flussi separati, ad esempio una sala d'attesa per evento o per vendita, gestiscono più sale d'attesa indipendenti, ciascuna con il proprio slug, segreto, tariffa e configurazione.

Architettura sotto carico: numeri misurati

L'obiettivo di progettazione deriva direttamente dalla logica di ammissione di cui sopra: poiché il numero ammesso deriva dal tempo trascorso e il controllo dello stato non legge alcuno stato per visitatore, quasi l'intero traffico dei visitatori è un calcolo senza stato. Qualsiasi istanza può rispondere a qualsiasi richiesta, le istanze non condividono altro che il database e la piattaforma aggiunge automaticamente le istanze sotto carico. La scrittura del database singolo per visitatore, ovvero l'incremento atomico al momento dell'adesione, è l'unico punto di serializzazione e avviene esattamente una volta per visitatore, non per sondaggio. I numeri seguenti provengono dal runner di test di carico integrato descritto sopra, eseguito contro una sala d'attesa di test dedicata sul sistema di produzione: due worker generatori sollecitano due istanze di coda, con throughput e tasso di errore ricavati dalle ricevute firmate del servizio di coda. Il profilo mix combina l'adesione e il sondaggio sullo stato in proporzione al percorso reale del visitatore:

Tutte le esecuzioni hanno utilizzato il percorso del codice di produzione e si sono concluse senza un singolo errore HTTP, di trasporto o di limitazione. Due istanze reggono mille richieste di stato al secondo per due minuti – oltre diecimila visitatori in attesa che effettuano il polling al loro intervallo adattivo – e il profilo mix conferma che cinquecento richieste al secondo, adesioni incluse, passano senza essere frenate dai budget di richieste per IP. Il limite superiore della tabella è dato dal generatore di carico, non dalla coda: il p95 lato coda è rimasto a una cifra in millisecondi finché il generatore non ha lavorato al massimo. Questo ridimensionamento non è una scatola nera: ogni istanza in esecuzione si segnala continuamente con parametri in tempo reale (CPU, memoria, throughput delle richieste) visibili in qualsiasi momento nella console di amministrazione ADITUS, quindi è trasparente quante istanze sostengono una vendita e quanto margine rimane. I test di carico programmati verificano nuovamente questi numeri confrontandoli con il sistema di produzione e un'esecuzione chiaramente indietro rispetto ai predecessori viene contrassegnata automaticamente.

Endpoint

Dieci endpoint, nessuna autenticazione per i visitatori, CORS limitato ai domini configurati per coda. La pagina della sala d'attesa ospitata utilizza esattamente questa API: può anche essere gestita direttamente per un'esperienza di attesa completamente personalizzata.

1. Richiedi un numero di attesa

// Wartenummer anfordern (einziger Schreibzugriff im Besucherpfad).
const res = await fetch("https://developers.aditus.com/queue/<slug>/join", {
  method: "POST",
});
const ticket: {
  queue: string;              // Queue-Slug
  name: string;               // Anzeigename des Warteraums
  number: number;             // vergebene Wartenummer
  serving: number;            // bis zu dieser Nummer wird weitergeleitet
  ahead: number;              // Anzahl Nummern vor dieser
  admitted: boolean;          // true -> sofort weiter zu /token
  estimatedWaitSeconds: number;
  retryAfterSeconds: number;  // empfohlenes Polling-Intervall
} = await res.json();
// 423 Locked -> der Warteraum ist pausiert (keine Weiterleitung, keine neuen Nummern).

2. Interrogare lo stato

// Statusabfrage — rein lesend, beliebig oft wiederholbar.
// Der Server sendet zusätzlich einen Retry-After-Header.
const res = await fetch(
  "https://developers.aditus.com/queue/<slug>/status?number=" + ticket.number,
);
const status: {
  queue: string;
  name: string;
  active: boolean;            // false -> Weiterleitung pausiert
  number: number;
  serving: number;
  ahead: number;
  admitted: boolean;
  estimatedWaitSeconds: number;
  retryAfterSeconds: number;
} = await res.json();

if (status.admitted) {
  // -> Token abholen und zum Shop weiterleiten
}

3. Recupera il token di ammissione

// Sobald admitted=true: Zugriffs-Token abholen.
const res = await fetch("https://developers.aditus.com/queue/<slug>/token", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ number: ticket.number }),
});
// 425 Too Early -> die Nummer ist noch nicht zur Weiterleitung freigegeben.
const grant: {
  queue: string;
  number: number;
  token: string;              // signierter HS256-JWT
  tokenType: "JWT";
  expiresInSeconds: number;   // Standard: 600 s
  targetUrl: string | null;   // konfiguriertes Weiterleitungsziel
} = await res.json();

// Weiterleitung übernimmt die gehostete Warteraum-Seite automatisch:
// targetUrl + "?aditus_queue_token=" + grant.token

Facoltativo: verificare il token nel tuo backend

L'integrazione script-tag è completa da sola. I negozi che controllano il proprio backend possono inoltre verificare lì il token di ammissione: si tratta di un JWT HS256 standard, verificato offline con il segreto condiviso: nessuna richiamata alla coda, nessuna latenza aggiuntiva. Il segreto viene generato al momento della creazione della coda, mostrato esattamente una volta e può essere ruotato in qualsiasi momento. Reclami: iss è sempre aditus-queue, aud è lo slug della coda, qnr è il numero di attesa ammesso, validità limiti exp (default 10 minuti). Nota: il passaggio silenzioso alla tariffa di ingresso non produce un token: un backend che richiede rigorosamente un token dovrebbe inviare i visitatori che ne sono sprovvisti nella sala d'attesa, che quindi emette immediatamente un token quando nessuno sta aspettando.

// ZIELSYSTEM (dein Shop / deine Seite): Token prüfen — Standard-JWT (HS256).
// Das Secret erhältst du einmalig von ADITUS beim Einrichten des Warteraums.
import jwt from "jsonwebtoken";

const payload = jwt.verify(token, process.env.ADITUS_QUEUE_SECRET!, {
  algorithms: ["HS256"],
  issuer: "aditus-queue",     // iss ist immer aditus-queue
  audience: "<slug>",         // aud ist der Queue-Slug deines Warteraums
}) as { qnr: number; iat: number; exp: number };

// payload.qnr = die weitergeleitete Wartenummer.
// Gültiger Token -> Besucher passieren lassen (z. B. Cookie setzen).
// Fehlender/ungültiger Token -> zurück in den Warteraum:
//   https://developers.aditus.com/queue/<slug>

Sicurezza in un unico posto

I meccanismi di sicurezza sono descritti dove appartengono nel flusso sopra; questa sezione li raccoglie. Token firmati: i token di ammissione sono JWT HS256, firmati con un segreto per coda che viene mostrato esattamente una volta e può essere ruotato in qualsiasi momento; il legame del pubblico (slug della coda) e una scadenza breve (predefinita 10 minuti) limitano il valore di un token catturato. Protezione dei bot: il controllo opzionale della prova di lavoro rende proporzionalmente costosa l'adesione di massa da parte di bot farm; le sfide sono firmate HMAC e scadono dopo cinque minuti; una protezione per istanza basata sul massimo sforzo elimina inoltre il riutilizzo di una sfida spesa: il vero fattore di costo è il lavoro di hash stesso. Reindirizzamenti: gli URL di ritorno vengono convalidati lato server rispetto ai domini configurati per coda: la sala d'attesa non diventa mai un reindirizzamento aperto. Superficie API: gli endpoint dei visitatori non portano alcuna credenziale, CORS è limitato per coda, l'accesso amministrativo utilizza chiavi API legate ciascuna a una singola sala d'attesa, archiviate solo come hash, non possono gestire altre chiavi e lasciano una traccia di controllo. Picchi di traffico: l'architettura stateless assorbe il carico in base alla progettazione: qualsiasi istanza risponde a qualsiasi richiesta e la piattaforma ridimensiona le istanze automaticamente; il filtraggio DDoS a livello di rete è fornito dalla piattaforma di hosting prima del servizio.

Modalità di fallimento: cosa succede quando qualcosa si rompe

Una sala d'attesa si trova di fronte alle entrate: il suo comportamento in caso di fallimento conta tanto quanto il suo percorso felice.

• Servizio coda irraggiungibile (variante script-tag): lo script non si apre — il negozio rimane completamente utilizzabile. L'interruzione della sala d'attesa non blocca mai il negozio.
• Servizio coda non raggiungibile (variante gateway): nuovi inserimenti in pausa; i visitatori già ammessi restano sullo shop e continuano inalterati.
• Perdita di una singola istanza: nessun visitatore se ne accorge. Nessuno stato per visitatore risiede in nessuna istanza: ogni istanza risponde a ogni richiesta, il database condiviso è l'unico componente con stato.
• Aggiornamento del browser: il numero di attesa viene mantenuto nella sessione del browser: ricaricando si rientra nella stessa posizione, il posto in fila non viene mai perso.
• Il visitatore cancella i cookie o la memoria del browser: la posizione è deliberatamente non recuperabile: il visitatore disegna un nuovo numero alla fine della riga. Qualsiasi altra cosa aprirebbe la strada alla frode di posizione.
• Sala d'attesa in pausa: interruzione dell'ingresso e dell'ammissione con un segnale chiaro (HTTP 423) e un messaggio esplicativo nella sala d'attesa - nessun errore silenzioso.
• Il controllo dello stato del negozio fallisce (tariffa automatica): prima il tasso si blocca, poi scende al minimo configurato: un controllo dello stato irraggiungibile non apre mai le porte.

Confronto con i prodotti dedicati alle sale d'attesa

ADITUS-Queue risolve gli stessi problemi tecnici dei prodotti dedicati alle sale d'attesa virtuali aziendali. La tabella mappa le capacità con cui vengono misurati tali prodotti in base al modo in cui ADITUS-Queue li copre, inclusa un'omissione deliberata.

Amministrazione tramite chiave API

Tutto ciò che fa la console di amministrazione ADITUS per una singola sala d'attesa (regolazione della tariffa di ingresso, pausa, modifica della configurazione) è disponibile anche per le macchine. L'accesso utilizza una chiave API con il prefisso qak_, inviata come token al portatore; ogni chiave è creata esattamente per una sala d'attesa e può leggere e modificare solo quella stanza. Le chiavi vengono create e revocate nella console di amministrazione, mostrate esattamente una volta e archiviate solo come hash. Il caso d'uso tipico è un runbook in vendita: un job pianificato aumenta il tasso di ammissione subito prima dell'inizio, uno script mette in pausa la coda in caso di emergenza, il monitoraggio legge la configurazione corrente. Si applicano tre barriere: una chiave non raggiunge mai altre sale d'attesa o funzioni di amministrazione globale (test di carico, pianificazioni, istanze) - tali richieste vengono rifiutate lato server; la gestione delle chiavi in ​​sé non è deliberatamente possibile con una chiave: una chiave trapelata non può mai creare o elencare altre chiavi; e ogni modifica apportata con una chiave viene registrata nel registro di controllo sotto il nome della chiave e la sua sala d'attesa.

# Konfiguration des zugeordneten Warteraums lesen. Jeder Key ist an genau
# einen Warteraum gebunden — die Liste enthält daher höchstens diesen einen
# Eintrag; andere Warteräume und globale Verwaltungsfunktionen sind mit
# einem Key nicht erreichbar.
curl -H "Authorization: Bearer qak_…" \
  https://developers.aditus.com/api/admin/queue/sites

# Weiterleitungsrate im laufenden Betrieb anheben: Lesen -> Feld ändern -> Schreiben.
# PATCH erwartet die vollständige Konfiguration (ohne slug); unbekannte
# Felder wie id oder Zeitstempel werden serverseitig ignoriert.
KEY="qak_…"; BASE="https://developers.aditus.com/api/admin/queue"
SITE=$(curl -s -H "Authorization: Bearer $KEY" "$BASE/sites" \
  | jq '.sites[0]')
echo "$SITE" | jq '.ratePerMinute = 300' | curl -s -X PATCH \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d @- "$BASE/sites/$(echo "$SITE" | jq -r .id)"

# Zugeordneten Warteraum pausieren (keine Weiterleitung, keine neuen Nummern):
# active = false
echo "$SITE" | jq '.active = false' | curl -s -X PATCH \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d @- "$BASE/sites/$(echo "$SITE" | jq -r .id)"

# .github/workflows/onsale.yml — Weiterleitungsrate zum Vorverkaufsstart anheben.
# Den API-Key als Repository-Secret ADITUS_QUEUE_API_KEY hinterlegen. Der Key
# ist an den Warteraum des Vorverkaufs gebunden — mehr kann er nicht.
name: Weiterleitungsrate zum On-Sale anheben
on:
  schedule:
    - cron: "55 8 14 3 *"   # 14. März, 08:55 UTC — kurz vor dem On-Sale
  workflow_dispatch: {}

jobs:
  raise-rate:
    runs-on: ubuntu-latest
    steps:
      - name: Rate auf 300/min anheben
        env:
          KEY: ${{ secrets.ADITUS_QUEUE_API_KEY }}
        run: |
          BASE="https://developers.aditus.com/api/admin/queue"
          # Der Key sieht nur seinen gebundenen Warteraum — .sites[0] genügt.
          SITE=$(curl -sf -H "Authorization: Bearer $KEY" "$BASE/sites" \
            | jq '.sites[0]')
          echo "$SITE" | jq '.ratePerMinute = 300' \
            | curl -sf -X PATCH \
              -H "Authorization: Bearer $KEY" \
              -H "Content-Type: application/json" \
              -d @- "$BASE/sites/$(echo "$SITE" | jq -r .id)"