Abgesicherte Middleware: Warum ich zwischen Access und WordPress eine Logikschicht setze

Warum nicht direkt?

Du kannst natĂŒrlich direkt von Access auf die WordPress-Datenbank zugreifen – per ODBC, MySQL-Link oder REST.
Du kannst auch direkt aus WordPress auf Access zugreifen – per API oder JSON-Export.

Aber: Nur weil es geht, ist es nicht gut.

Ich setze immer eine Middleware dazwischen.
Weil Sicherheit, StabilitÀt und Wartbarkeit sonst baden gehen.
Gerade in KMU-Setups mit begrenztem IT-Budget.

Was ist mit Middleware gemeint?

Eine separate Anwendung, die:

  • Anfragen von WordPress entgegennimmt
  • mit Access kommuniziert (z. B. per COM, Shell, ODBC)
  • Ergebnisse prĂŒft, filtert, protokolliert
  • nur die nötigsten Daten zurĂŒckgibt

Beispiele:

  • Node.js-Microservice
  • n8n-Flow mit HTTP-In & MS Access Node
  • selbst gebauter Python- oder .NET-Dienst
  • lokales Script auf dem Access-Server (z. B. api.exe oder accessproxy.py)

Vorteile auf einen Blick

Ohne MiddlewareMit Middleware
direkter Zugriffkontrollierter Zugriff
schwer zu debuggenLogs und Monitoring
potenzielle Datenlecksgefilterte RĂŒckgaben
SQL-Injection möglichvalidierte Parameter
keine Trennungsaubere ZustÀndigkeiten

Szenario: WordPress fragt Access nach Lieferstatus

Ohne Middleware:

$response = file_get_contents("http://accessserver:8080/get_lieferung?id=123");

Zugriff auf Access direkt, ggf. sogar als Admin.
Keine Authentifizierung, keine Begrenzung, kein Protokoll.

Mit Middleware:

$response = file_get_contents("https://api.firma.de/accessproxy/lieferung?id=123", false, $authContext);

Access wird nie direkt angesprochen.
Die Middleware prĂŒft:

  • Ist die Anfrage autorisiert?
  • Ist die ID gĂŒltig?
  • Darf der Benutzer diese Lieferung sehen?

Dann kommt ein valides, sauberes JSON zurĂŒck – ohne internen SQL-MĂŒll.

Beispiel: Node.js-Middleware (Express)

app.get('/lieferung', async (req, res) => {
  const id = parseInt(req.query.id);
  if (!id || id < 1) return res.status(400).json({ error: 'Invalid ID' });

  // Zugriff auf Access per Python, COM oder SQL Proxy
  const result = await fetchFromAccess(id);
  if (!result) return res.status(404).json({ error: 'Not found' });

  res.json({ id, status: result.status, termin: result.termin });
});

Zugriff auf Access aus Middleware: Optionen

Variante A: Access per Shell ansprechen (lokal)

const { exec } = require('child_process');
exec(`accesscli.exe --get lieferung --id 123`, (err, stdout) => {
  // Ergebnis als JSON zurĂŒckgeben
});

Variante B: Access mit VBA „bereitstellen“

Public Function HoleLieferungJSON(id As Long) As String
    Dim rs As DAO.Recordset
    Set rs = CurrentDb.OpenRecordset("SELECT * FROM tbl_Lieferungen WHERE ID=" & id)
    
    If rs.EOF Then
        HoleLieferungJSON = "{}"
    Else
        HoleLieferungJSON = "{""id"":" & rs!ID & ",""status"":""" & rs!Status & """}"
    End If
    rs.Close
End Function

Erreichbar ĂŒber COM oder lokal per REST-Shell-Dienst.

Authentifizierung

Die Middleware validiert einen API-Key oder JWT – bevor sie ĂŒberhaupt mit Access spricht.

app.use((req, res, next) => {
  const key = req.headers['x-api-key'];
  if (key !== 'mein-geheimer-key') return res.status(403).json({ error: 'Forbidden' });
  next();
});

Kein direkter Key-Zugriff in VBA, kein SchlĂŒssel im Access-Frontend.

Logging & Throttling

Die Middleware loggt alle Zugriffe:

console.log(`${new Date().toISOString()} - ${req.method} ${req.url} von ${req.ip}`);

Und kann bei Bedarf blocken:

if (requestsFromIP[ip] > 100) return res.status(429).json({ error: 'Rate limit' });

Access selbst bleibt davon unberĂŒhrt.

Mein Fazit

Access ist mĂ€chtig – aber verletzlich.
WordPress ist offen – aber neugierig.
Zwischen beiden gehört besser eine saubere Logikschicht.

Die Middleware ist wie ein Wachhund vorm Schafstall.
Und ja: Ich vertraue dem Schaf. Aber ich prĂŒf trotzdem, wer ans Tor klopft.

Kategorien:

Allgemein

Schlagwörter:

AccessLogikschichtMiddleware