Hilfe & Dokumentation

Installation auf Windows Server

Diese Anleitung richtet Bestell-Bar auf einem Windows Server ein, auf dem IIS und Microsoft SQL Server bereits installiert sind. Die kostenlose SQL Server Express-Edition genügt; höhere Editionen funktionieren genauso.

Voraussetzungen

Programmpaket herunterladen

Unter www.bestell-bar.ch/download stehen diese Pakete bereit:

DateiInhalt
bestell-bar-1.10.2.zip Die Anwendung selbst – eine Datei je Version.
bestell-bar-hilfe-1.10.2.zip Diese Hilfe als statische Seiten – zum Einbinden in Schritt 6, ebenfalls je Version.
bestell-bar-install.zip Die Installations-Scripts. Ohne Versionsnummer: Es gibt immer nur den aktuellen Stand, und die Scripts laden die Anwendung selbst in der Version herunter, die Sie ihnen nennen.

Die Links zur Anwendung stehen auch auf der Impressum-Seite der Anwendung bei den Release-Notes.

Neben jedem Archiv liegt eine Datei .sha256 mit der Prüfsumme. So lässt sich nachweisen, dass das Archiv unverändert ist – die Lizenz erlaubt die Weitergabe nur unverändert. Prüfen in PowerShell:

Get-FileHash .\bestell-bar-1.10.2.zip -Algorithm SHA256

Der ausgegebene Wert muss mit dem Inhalt der .sha256-Datei übereinstimmen.

Hinweis zu Windows SmartScreen: Das Programm ist nicht signiert. Beim ersten Start meldet Windows daher möglicherweise, der Computer sei geschützt worden. Über Weitere Informationen → Trotzdem ausführen lässt sich der Start fortsetzen.

Benötigte IIS-Rollendienste

Die reine Rolle Webserver (IIS) genügt nicht – für Bestell-Bar müssen zusätzlich diese Rollendienste installiert sein (Server-Manager → Rollen und Features hinzufügen, oder per PowerShell):

Auf einem Windows Server installiert dieser Befehl (als Administrator in PowerShell) alles Nötige:

Install-WindowsFeature -Name Web-Server, Web-Static-Content, Web-Default-Doc, `
    Web-Http-Errors, Web-Http-Redirect, Web-WebSockets, Web-Stat-Compression, `
    Web-Dyn-Compression, Web-Mgmt-Console, Web-Scripting-Tools -IncludeManagementTools
Kein ASP.NET 4.x nötig Den Rollendienst ASP.NET 4.x braucht Bestell-Bar nicht. Die Verbindung zwischen IIS und der .NET-Anwendung stellt das ASP.NET Core Hosting Bundle her (siehe Schritt 1) – nicht ein IIS-Feature.

Benötigte SQL-Server-Features

Bei der Installation von SQL Server (Express oder höher) genügt für Bestell-Bar:

Abkürzung: Installation per Script

Die Schritte 1 bis 7 gibt es auch als PowerShell-Scripts. Sie tun genau das, was unten von Hand beschrieben ist – prüfen dabei aber zusätzlich Dinge, die man beim Klicken leicht übersieht, etwa ob der Anwendungspool wirklich nur einen Arbeitsprozess verwendet.

Auch die Hilfe richten die Scripts ein: Sie laden das Hilfe-Paket in der Version der Anwendung und legen es in den Unterordner Help des Anwendungsordners. Das geschieht bei jedem Lauf, also auch bei einem Update, sodass die Hilfe immer zur installierten Version passt.

Die Scripts kommen als bestell-bar-install.zip (siehe Programmpaket herunterladen). Das Archiv enthält den Ordner install – entpacken Sie es auf dem Zielserver, etwa nach C:\Setup, dann liegen die Scripts unter C:\Setup\install. Laden Sie es vor jeder Installation neu: Es gibt nur diesen einen, jeweils aktuellen Stand.

Heruntergeladene Dateien Windows markiert Dateien aus dem Internet als fremd. Der Befehl unten und setup.bat laufen deshalb mit -ExecutionPolicy Bypass – so starten die Scripts trotz dieser Markierung. Wer sie lieber entfernt, entsperrt das Archiv vor dem Entpacken:
Unblock-File .\bestell-bar-install.zip
Dann sind auch die entpackten Dateien ohne Markierung.

Als Administrator auf dem Zielserver, im Ordner über install:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\install\Install-BestellBar.ps1

Wer lieber klickt, startet stattdessen install\setup.bat. Die Datei ruft genau denselben Befehl auf, fordert bei Bedarf Administratorrechte an – Windows fragt dann nach – und lässt das Fenster am Ende offen, damit die Ausgabe lesbar bleibt.

Das Script fragt alles Fehlende ab. Wer erst sehen will, was geschehen würde, hängt -PreflightOnly an: dann werden nur die Voraussetzungen geprüft und der vollständige Plan ausgegeben, ohne etwas zu ändern.

Im Ordner install liegt nur dieses eine Script; die Einzelschritte stehen im Unterordner install\scripts und lassen sich bei Bedarf auch einzeln aufrufen.

Der ganze Lauf wird mitgeschrieben Das Protokoll landet in install\logs\BestellBar-Installation-<Zeitstempel>.log. Lässt sich dort nicht schreiben – etwa weil das Paket auf einer Freigabe oder unter C:\Program Files liegt –, schreibt das Script auf den Desktop und sagt das beim Start. Passwörter und Geheimnisse stehen nicht darin; das Protokoll überlebt den Lauf und ist das Erste, was Sie bei einer Rückfrage zur Hand haben sollten. Einzeln aufgerufene Schritte aus install\scripts schreiben nur auf die Konsole – wer deren Verlauf braucht, klammert den Aufruf in Start-Transcript / Stop-Transcript ein.
Vorher sichern Als Erstes empfiehlt das Script eine Datensicherung, am einfachsten eine Momentaufnahme der VM. Läuft Bestell-Bar auf dem Server schon, gehören mindestens die Datenbank, appsettings.json und der Schlüsselordner (%ProgramData%\BestellBar\keys) dazu. Das Script legt selbst keine Datenbanksicherung an und passt die vorhandene Datenbank an die neue Version an. Bis Sie den angezeigten Plan bestätigen, richtet das Script nichts ein; mit Strg+C brechen Sie ab.

Danach werden zwei Angaben erfragt, weil alles Weitere daran hängt:

FrageVorschlagBedeutung
Unter welcher Adresse soll die Anwendung erreichbar sein? <Servername> Das Script legt dafür eine eigene Website im IIS an – die Adresse wird deren Hostname und zugleich ihr Name. Der Servername ist im lokalen Netz ohne weiteres erreichbar. Soll die Anwendung aus dem Internet erreichbar sein, geben Sie einen öffentlichen Namen an (z. B. bestellbar.musterverein.ch), der im DNS auf diesen Server zeigt; das richtet das Script nicht ein. Ein Zertifikat von Let's Encrypt gibt es nur für einen solchen Namen.
In welchen Ordner soll die Anwendung? Eine Ebene über dem Webstammordner des IIS (meist C:\inetpub) plus die gewählte Adresse Also z. B. C:\inetpub\SRV01 – bewusst nicht unterhalb von wwwroot: dort läge der Ordner im physischen Pfad der Default Web Site, die ihn dann als Unterpfad mit ausliefern würde. Jeder andere Ordner geht auch – Schritt 2 unten beschreibt den Handweg mit einem eigenen Pfad.

Beide Vorschläge lassen sich an der Eingabeaufforderung überschreiben oder als -HostName und -AppPath mitgeben.

Kostenloses Zertifikat von Let's Encrypt

Als Zertifikat schlägt das Script Let's Encrypt vor. Es holt ein kostenloses Zertifikat und richtet die Erneuerung als geplante Aufgabe ein – täglich, mit etwas Zufallsversatz. Ein Zertifikat gilt 90 Tage und wird ab 30 Tagen vor Ablauf erneuert; Sie müssen sich darum nicht mehr kümmern. Alternativ wählen Sie ein vorhandenes Zertifikat aus dem Zertifikatspeicher oder ein selbstsigniertes zum Testen.

Ein selbstsigniertes Zertifikat trägt das Script auf dem Server als vertrauenswürdig ein. Ein Browser auf dem Server selbst öffnet die Anwendung deshalb ohne Warnung. Auf den übrigen Geräten im Netz erscheint die Warnung weiterhin. Für Gäste am Anlass taugt das nicht, dafür braucht es ein echtes Zertifikat.

Zwei Voraussetzungen – dauerhaft, nicht nur bei der Installation
  • Die gewählte Adresse muss im öffentlichen DNS auf diesen Server zeigen.
  • Port 80 muss aus dem Internet erreichbar sein. Let's Encrypt prüft darüber, dass Ihnen die Adresse gehört – bei der Ausstellung und bei jeder Erneuerung. Die nötige HTTP-Bindung legt das Script selbst an (das tut es auch ohne Let's Encrypt, damit http:// auf die Anwendung und von dort auf HTTPS führt); die Freigabe in Firewall und Router müssen Sie sicherstellen.
Beides wird vor dem Bezug geprüft. Das hat einen Grund: Let's Encrypt lässt nur fünf Fehlversuche pro Stunde und Adresse zu, danach ist die Ausstellung vorübergehend gesperrt.
Erst die Testumgebung Sind Sie unsicher, ob DNS und Portfreigabe stimmen, hängen Sie beim ersten Lauf -LetsEncryptStaging an. Das Zertifikat kommt dann aus der Testumgebung – im Browser nicht gültig, dafür ohne Anrechnung auf die Mengenbegrenzung. Stimmt alles, wiederholen Sie den Bezug ohne diesen Schalter:
.\install\scripts\Install-LetsEncryptCertificate.ps1 -HostName 'bestellbar.example.ch' `
    -SiteName 'bestellbar.example.ch' -ContactEmail 'admin@example.ch' -AcceptTermsOfService

Der Zertifikatsbezug läuft spät, aber noch vor der Abnahmeprüfung: Let's Encrypt stellt nur aus, wenn die Seite bereits erreichbar ist, und bis dahin verwendet die Installation ein selbstsigniertes Zertifikat, das dann ersetzt wird. Die Abnahmeprüfung kommt danach, damit sie das echte Zertifikat beurteilt – Aussteller, Erneuerungsaufgabe und die Bindung auf Port 80 lassen sich am Zwischenstadium nicht prüfen. Geht beim Bezug etwas schief, steht trotzdem eine fertige, laufende Installation da – nur mit Zertifikatswarnung, die sich mit dem Befehl oben nachträglich beheben lässt.

Zum Schluss: die Abnahmeprüfung install\scripts\Test-BestellBarInstallation.ps1 prüft die fertige Installation und ändert nichts – Rollendienste, Anwendungspool, Zertifikat, Datenbank, Schlüsselordner, Protokoll und die Live-Verbindung. Lassen Sie es nach jedem Update laufen, zusammen mit install\scripts\Set-BestellBarAcl.ps1: Dateirechte gehören nicht zum Dateiinhalt und gehen verloren, wenn der Anwendungsordner ersetzt wird.

Die folgende Anleitung bleibt gültig und vollständig – wer lieber von Hand installiert, folgt einfach den Schritten 1 bis 7.

Schritt 1: .NET Hosting Bundle installieren

  1. Das ASP.NET Core 10 Hosting Bundle von dotnet.microsoft.com herunterladen (Abschnitt ASP.NET Core Runtime → Hosting Bundle) und installieren. Es verbindet .NET mit dem IIS (ASP.NET-Core-Modul).
  2. Anschliessend in einer Administrator-Eingabeaufforderung iisreset ausführen (oder den IIS manuell neustarten).

Schritt 2: Anwendungsdateien ablegen

  1. Einen Ordner für die Anwendung anlegen, z. B. D:\Sites\bestellbar.
  2. Den kompletten Inhalt des zip-Archivs hineinkopieren (JKOrderManager.exe, appsettings.json, web.config, wwwroot usw.).

Schritt 3: IIS einrichten

  1. Im IIS-Manager einen neuen Anwendungspool anlegen, z. B. BestellBar, .NET-CLR-Version Kein verwalteter Code. Die Identität kann auf dem Standard (ApplicationPoolIdentity) bleiben (je nach Verbindung mit dem MS SQL Server).
  2. Eine Website (oder eine Anwendung unterhalb einer bestehenden Website, z. B. /bestellbar) anlegen: physischer Pfad = Ordner aus Schritt 2, Anwendungspool = BestellBar. Der Betrieb unter einem Unterpfad wird von Bestell-Bar vollständig unterstützt.
  3. Eine HTTPS-Bindung mit Zertifikat einrichten (die QR-Codes und die Bestellseiten der Gäste setzen eine sichere Verbindung voraus).

Schritt 4: Datenbank anlegen und Rechte vergeben

  1. Eine leere Datenbank anlegen, z. B. BestellBar:
    sqlcmd -S .\SQLEXPRESS -E -Q "CREATE DATABASE BestellBar"
    (bei einer Standardinstanz -S . statt .\SQLEXPRESS). Die Tabellen erstellt die Anwendung beim ersten Start selbst.
  2. Dem Konto des Anwendungspools Zugriff geben (empfohlen: Windows-Authentifizierung):
    sqlcmd -S .\SQLEXPRESS -E -Q "CREATE LOGIN [IIS AppPool\BestellBar] FROM WINDOWS"
    sqlcmd -S .\SQLEXPRESS -E -d BestellBar -Q "CREATE USER [IIS AppPool\BestellBar] FOR LOGIN [IIS AppPool\BestellBar]; ALTER ROLE db_owner ADD MEMBER [IIS AppPool\BestellBar]"
    Der Login-Name entspricht immer IIS AppPool\<Name des Anwendungspools>.
Alternative: SQL-Anmeldung Statt Windows-Authentifizierung kann auch ein SQL-Login (Benutzer/Passwort) verwendet werden – dann im Connection String User Id=…;Password=… statt Trusted_Connection=True eintragen.

Schritt 5: appsettings.json anpassen

Die Datei appsettings.json im Anwendungsordner öffnen und anpassen:

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=.\\SQLEXPRESS;Database=BestellBar;Trusted_Connection=True;TrustServerCertificate=True;MultipleActiveResultSets=true"
  },
  "Qr":         { "Secret": "…langer Zufallswert…" },
  "Encryption": { "Key": "…langer Zufallswert…" },
  "Seed": {
    "SuperAdminEmail": "admin@example.ch",
    "SuperAdminPassword": "…starkes Passwort…",
    "SuperAdminDisplayName": "Plattform-Administrator"
  },
  "Installation": { "Label": "" },
  "Security":     { "SuperAdminTwoFactorBypass": false },
  "DataProtection": {
    "KeyPath": "",
    "ApplicationName": "",
    "ProtectKeysWithDpapi": true
  },
  "Hosting": { "HttpsRedirectPort": 443 },
  "RateLimits": {
    "Enabled": true,
    "Registration":       { "Limit": 3,  "WindowMinutes": 60 },
    "Mail":               { "Limit": 5,  "WindowMinutes": 10 },
    "Receipt":            { "Limit": 3,  "WindowMinutes": 10 },
    "Login":              { "Limit": 10, "WindowMinutes": 5 },
    "AnonymousMailTotal": { "Limit": 20, "WindowMinutes": 60 }
  },
  "Imprint": {
    "Name": "Musterverein Zürich",
    "AddressLines": [ "Musterstrasse 1", "8000 Zürich", "CH" ],
    "Email": "info@musterverein.ch",
    "Representative": "Vorname Nachname"
  }
}

Impressum: Ihre eigenen Angaben

Bestell-Bar wird ohne Betreiberangaben ausgeliefert. Sobald Sie die Software selbst betreiben, sind Sie der Betreiber – und die öffentlichen Seiten Impressum und Datenschutz müssen Sie ausweisen, nicht den Hersteller.

Ohne Impressum kein Start Fehlen Imprint:Name oder Imprint:Email, startet die Anwendung ausserhalb der Entwicklungsumgebung nicht – gleich wie bei den nicht ersetzten Platzhaltern oben. So kann keine Installation online gehen, die niemanden ausweist oder noch fremde Angaben zeigt.
Korrektur ohne Neustart Änderungen am Abschnitt Imprint werden sofort übernommen – die Datei speichern genügt, ein Neustart der Anwendung ist nicht nötig.

Nicht betroffen sind Lizenz und Copyright der Software weiter unten auf der Impressum-Seite: Die bleiben beim Hersteller, unabhängig davon, wer die Installation betreibt.

Sicherheitsschlüssel: wo sie liegen und warum das zählt

Die Anwendung verschlüsselt mit einem Schlüsselbund, was sie den Browsern mitgibt: die Anmelde-Cookies, die Schutzmarken der Formulare und die Token in den Links aus den Bestätigungs- und Passwort vergessen-E-Mails.

Standardmässig legt die Anwendung diesen Schlüsselbund unter %ProgramData%\BestellBar\keys ab – also ausserhalb des Anwendungsordners, damit ein Update ihn nicht mitlöscht. Beim Start schreibt sie den verwendeten Pfad ins Log, dort können Sie ihn jederzeit nachsehen:

[INF] Data-Protection-Schlüssel: C:\ProgramData\BestellBar\keys (Installation 'BestellBar', DPAPI aktiv)
Geht der Ordner verloren, passiert Folgendes
  • Alle angemeldeten Benutzer sind abgemeldet.
  • Gerade geöffnete Formulare lassen sich nicht mehr abschicken (Fehler 400), bis die Seite neu geladen wird.
  • Bereits versendete Bestätigungs- und Passwort-Links funktionieren nicht mehr – die Betroffenen müssen einen neuen anfordern.
Nehmen Sie den Ordner darum in die Datensicherung auf und löschen Sie ihn nicht.

Die drei Einstellungen brauchen Sie nur, wenn Sie bewusst abweichen wollen:

EinstellungLeer / VorgabeWann ändern
KeyPath %ProgramData%\BestellBar\keys Wenn die Schlüssel woanders liegen sollen, etwa auf einem gesicherten Laufwerk. Der Ordner muss ausserhalb des Anwendungsordners liegen und das Anwendungspool-Konto muss darin schreiben dürfen.
ApplicationName BestellBar Wenn auf demselben Server mehrere Installationen laufen (z.B. Test neben Produktiv). Ohne eigenen Namen – oder eigenen Pfad – teilen sie sich die Schlüssel und damit die Anmeldungen.
ProtectKeysWithDpapi true Die Schlüsseldateien werden an diesen Server gebunden verschlüsselt. Das ist richtig so: Wer die Dateien lesen kann, könnte sonst eine Anmeldung fälschen. Nur bei einem geplanten Serverumzug relevant – siehe Kasten.
Beim Serverumzug Mit ProtectKeysWithDpapi: true sind die Schlüsseldateien auf einem anderen Server unlesbar. Das ist kein Datenverlust: Alle melden sich einmal neu an, und offene Passwort-Links müssen neu angefordert werden. Wollen Sie auch das vermeiden, setzen Sie den Wert vor dem Umzug auf false, starten die Anwendung einmal neu und kopieren den Ordner mit – schützen ihn dann aber mit Dateirechten.

HTTPS erzwingen

Die Anwendung gehört hinter HTTPS. Die Anmelde-Cookies werden ausserhalb der Entwicklungsumgebung ohnehin nur über eine verschlüsselte Verbindung gesendet – ruft jemand die Seite über http:// auf, kann er sich also gar nicht erst anmelden.

Damit niemand auf einer unverschlüsselten Seite landet, richten Sie die Umleitung ein. Zwei Wege, die sich ergänzen:

  1. Im IIS – der übliche Weg: Der Website nur eine https-Bindung geben, oder bei zusätzlicher http-Bindung eine Umleitungsregel (URL Rewrite) auf https einrichten.
  2. In der Anwendung – als zweite Absicherung: unter Hosting:HttpsRedirectPort den öffentlichen HTTPS-Port eintragen, meist 443. Die Anwendung beantwortet eine HTTP-Anfrage dann mit einer Umleitung auf dieselbe Adresse unter https://.
Ohne diesen Eintrag leitet die Anwendung nicht um Hinter dem IIS ist die Anwendung selbst nur über HTTP erreichbar – der IIS reicht die Anfragen intern weiter. Sie kann deshalb nicht erraten, unter welchem Port sie von aussen verschlüsselt erreichbar ist, und leitet ohne diesen Wert gar nicht um. Beim Start schreibt sie darum eine Warnung ins Log:
[WRN] Die Anwendung leitet HTTP-Anfragen NICHT selbst auf HTTPS um (Hosting:HttpsRedirectPort ist leer). …
Ist die Umleitung im IIS eingerichtet, können Sie die Warnung ignorieren.
Beim Testbetrieb leer lassen Der Start per Doppelklick läuft auf http://localhost:5000 ohne HTTPS. Steht dort ein Port drin, leitet die Anwendung auf eine Adresse um, die es nicht gibt – sie ist dann nicht mehr erreichbar. Für den Testbetrieb also "HttpsRedirectPort": null.

Nur ein Arbeitsprozess

Die Anwendung muss in einem einzigen Prozess laufen. Zwei Dinge hält sie im Speicher genau dieses Prozesses: die Live-Verbindungen zu den Stationsboards und den Zwischenspeicher der Artikelbilder; auch die Anfragebegrenzung zählt je Prozess.

Was bei mehreren Prozessen passiert Eine Bestellung, die bei Prozess A eingeht, erreicht ein Board, das an Prozess B hängt, nie. Die Karten bleiben einfach stehen – ohne Fehlermeldung, ohne Eintrag im Log. Am Anlass merkt das niemand, bis eine Bestellung liegen bleibt.

Häufigste Ursache ist ein Anwendungspool mit mehreren Arbeitsprozessen (eine sogenannte Webgarten-Konfiguration). So prüfen Sie das:

  1. Im IIS-Manager Anwendungspools öffnen und den Pool auswählen.
  2. Rechts Erweiterte Einstellungen… anklicken.
  3. Unter Prozessmodell muss Maximale Anzahl von Arbeitsprozessen auf 1 stehen (das ist die Standardeinstellung).
Zwei weitere Einstellungen, die sich lohnen Der IIS fährt einen Anwendungspool nach 20 Minuten ohne Anfrage herunter und startet ihn zusätzlich alle 29 Stunden neu. Beides trennt sämtliche Live-Verbindungen der Boards. Für einen Anlass, der zwischen Türöffnung und erster Bestellung eine Weile ruht, ist das unpraktisch. In den Erweiterten Einstellungen des Anwendungspools setzen Sie darum Leerlauftimeout und Regelmässiges Zeitintervall auf 0 und Startmodus auf AlwaysRunning. Die Installationsscripts tun das von sich aus.

Erkennt die Anwendung beim Start eine zweite laufende Instanz, schreibt sie eine Warnung ins Log:

[WRN] Es läuft bereits eine weitere Instanz dieser Installation ('BestellBar') auf diesem Rechner. …

Während eines Updates oder eines Neustarts kann diese Meldung kurz auftreten, weil der alte Prozess noch läuft – das ist normal. Erscheint sie im laufenden Betrieb, prüfen Sie den Anwendungspool.

Und auf mehreren Servern? Aus demselben Grund lässt sich die Anwendung nicht auf zwei Server verteilen. Für die Grössenordnung, für die Bestell-Bar gedacht ist – Vereinsanlässe –, reicht ein Server bei Weitem; ein Lasttest mit 600 gleichzeitigen Bestellungen lief in 4,4 Sekunden durch.

Anfragebegrenzung: Schutz vor Missbrauch

Ein paar Stellen der Anwendung kann jeder aufrufen, ohne angemeldet zu sein – und sie bringen den Server dazu, etwas zu tun: einen Verein anzulegen oder eine E-Mail über Ihren SMTP-Server zu verschicken. Ohne Bremse könnte jemand damit tausende E-Mails in Ihrem Namen auslösen; darunter leidet vor allem der Ruf Ihrer Absenderadresse.

Die Anwendung begrenzt darum, wie oft diese Aktionen in einem Zeitfenster aufgerufen werden dürfen. Wer darüber liegt, bekommt die Seite Zu viele Anfragen und muss kurz warten.

EinstellungVorgabeGilt für
Registration3 pro Stunde Selbstregistrierung eines Vereins über die Startseite.
Mail5 pro 10 Minuten Was Admins per E-Mail verschicken: Test-E-Mail, Zugangslink an eine Station oder an den Service, Quittung aus der Bestellliste, Rundmail an alle Vereine.
Receipt3 pro 10 Minuten Die Quittung, die sich ein Gast selbst schickt – gezählt je Bestellung, nicht je Adresse. Am Anlass teilen sich viele Gäste eine Internet-Adresse (WLAN des Festgeländes, Mobilfunk); eine Grenze je Adresse träfe alle zusammen. So kann jeder Gast seine Quittung bis zu dreimal anfordern, etwa nach einem Tippfehler in der Adresse.
Login10 pro 5 Minuten Anmeldeversuche – zusätzlich zur Kontosperre, die nach 5 Fehlversuchen für 5 Minuten greift. Die Sperre zählt je Konto, diese Grenze je Absender.
AnonymousMailTotal20 pro Stunde Gesamtobergrenze für die zwei Wege, die ohne Anmeldung eine E-Mail auslösen (Registrierung und Passwort vergessen) – über die ganze Installation. Wirkt auch dann, wenn die Anfragen von vielen verschiedenen Adressen kommen.

Die Grenzen gelten je Absenderadresse und Zeitfenster; Receipt zählt je Bestellung und AnonymousMailTotal über alle zusammen. Limit ist die erlaubte Anzahl, WindowMinutes die Länge des Zeitfensters; mit "Limit": 0 schalten Sie eine einzelne Grenze ab. Beim Start schreibt die Anwendung die geltenden Werte ins Log:

[INF] Anfragebegrenzung aktiv: Registrierung 3/60min, E-Mail 5/10min, Anmeldung 10/5min, Quittung je Bestellung 3/10min, anonymer Mailversand gesamt 20/60min
Der Bestellbetrieb ist bewusst nicht begrenzt Das Bestellen der Gäste, die Stationsboards und die Auslieferungsansicht haben keine Obergrenze – das sind die Hauptwege am Anlass, und eine Bremse, die dort zuschlägt, würde den Betrieb lahmlegen. Begrenzt sind ausschliesslich die oben genannten Aktionen.
Wenn Ihre Vereine hinter einer gemeinsamen Adresse sitzen Zählt wird nach der Absenderadresse der Anfrage. Kommen alle Zugriffe über denselben Ausgang ins Internet – etwa in einer Schule oder einem Firmennetz – teilen sich alle Benutzer ein Kontingent. Das betrifft nur die Anmeldung und den E-Mail-Versand, nicht den Bestellbetrieb; erhöhen Sie in dem Fall die Werte. Mit "Enabled": false schalten Sie die Begrenzung ganz ab – sinnvoll nur, wenn die Installation ohnehin nicht öffentlich erreichbar ist.
Serveruhr synchron halten Wenn Admins die Zwei-Faktor-Authentifizierung nutzen, muss die Uhr des Servers stimmen: Die Codes aus der App gelten nur rund ±90 Sekunden. Läuft die Uhr weg, schlagen Anmeldungen scheinbar grundlos fehl. Windows synchronisiert die Zeit normalerweise selbst – bei virtuellen Maschinen und in Domänen lohnt sich eine Kontrolle.

Notzugang für den Plattform-Administrator

Kommt der Plattform-Administrator wegen der Zwei-Faktor-Authentifizierung nicht mehr hinein, gehen Sie so vor:

  1. In der appsettings.json "SuperAdminTwoFactorBypass": true setzen und speichern. Ein Neustart ist nicht nötig – die Datei wird sofort neu eingelesen.
  2. Mit E-Mail und Passwort anmelden; der Code wird für dieses eine Konto übersprungen.
  3. Unter Mein Konto die 2FA mit dem Passwort deaktivieren und bei Bedarf neu einrichten.
  4. Den Schalter wieder auf false setzen.
Nur so lange wie nötig Solange der Schalter aktiv ist, zeigt jede Seite ein rotes Banner und jede so erfolgte Anmeldung wird als Warnung ins Log geschrieben. Er gilt ausschliesslich für das Plattform-Konto – Vereins-Admins bleiben auch dann durch ihre 2FA geschützt. Achten Sie darauf, dass die appsettings.json auf dem Server nur für Administratoren les- und schreibbar ist.
Wichtig: Platzhalter ersetzen Bleiben Qr:Secret, Encryption:Key oder das Seed-Passwort auf den mitgelieferten Beispielwerten, verweigert die Anwendung ausserhalb der Entwicklungsumgebung absichtlich den Start. Und: Wird Encryption:Key später geändert, werden bereits gespeicherte SMTP-Passwörter unlesbar und müssen neu erfasst werden.

Schritt 6: Hilfe-Seite einbinden

Wer mit den Scripts installiert, kann diesen Schritt überspringen. Sie legen die Hilfe im Unterordner Help des Anwendungsordners ab, zusammen mit einer kleinen web.config, damit der IIS die Seiten selbst ausliefert. Von Hand geht es so:

  1. Das Hilfe-Paket bestell-bar-hilfe-<Version>.zip herunterladen (siehe Programmpaket herunterladen) und in einen Ordner ausserhalb des Anwendungsordners entpacken, z. B. D:\Sites\bestellbar-help. Das Archiv enthält die Seiten direkt, ohne umschliessenden Ordner – legen Sie den Zielordner also vorher an.
  2. Im IIS-Manager unterhalb der Bestell-Bar-Anwendung ein virtuelles Verzeichnis mit Alias help anlegen, das auf diesen Ordner zeigt.

Damit funktioniert der Hilfe-Link im Seitenfuss der Anwendung, und die Seite bleibt bei Anwendungs-Updates unangetastet.

Die Hilfe aktualisiert sich nicht von selbst Genau weil sie getrennt liegt, bringt ein Update der Anwendung die Hilfe nicht mit. Spielen Sie bei jedem Update auch das passende Hilfe-Paket ein (siehe Updates einspielen) – sonst beschreibt die Hilfe weiter den Stand der Erstinstallation. Welche Version eine Hilfe-Seite zeigt, steht unten in ihrer Fusszeile.

Schritt 7: Erster Start

  1. Die Website im Browser aufrufen. Beim ersten Start legt die Anwendung die Datenbanktabellen an und erstellt das Administrator-Konto aus dem Seed-Abschnitt (das kann einige Sekunden dauern).
  2. Mit dem Seed-Konto Anmelden.
  3. Unter dem Zahnrad-Menü Administration → System-SMTP den zentralen E-Mail-Versand konfigurieren (Voraussetzung für Selbstregistrierung und «Passwort vergessen»).
  4. Unter Vereine den ersten Verein samt Vereins-Admin anlegen – oder die Selbstregistrierung auf der Startseite nutzen.

Updates einspielen

Wer mit den Scripts installiert hat, startet für ein Update dasselbe Script noch einmal und gibt die neue Versionsnummer ein; alle anderen Angaben schlägt es aus dem letzten Lauf vor. Es lädt die neue Version, hält erst dann die Anwendung an, ersetzt die Programmdateien und die Hilfe, behält appsettings.json und web.config und prüft am Ende die ganze Installation. Einstellungen, die eine neue Version neu mitbringt, ergänzt es in Ihrer appsettings.json – samt erklärendem Kommentar; Ihre bestehenden Werte bleiben dabei unverändert. Die Datenbank sichert es nicht – das bleibt Ihr erster Schritt. Von Hand geht ein Update so:

  1. Datenbank sichern.
  2. Anwendungspool BestellBar stoppen.
  3. Anwendungsdateien durch die neue Version ersetzen – appsettings.json und web.config dabei behalten (vorher sichern).
  4. Anwendungspool wieder starten. Nötige Datenbank-Anpassungen führt die Anwendung beim Start automatisch aus.
  5. Die Hilfe aktualisieren: den Inhalt des Hilfe-Ordners aus Schritt 6 durch das neue bestell-bar-hilfe-<Version>.zip ersetzen. Die Hilfe hat keine eigenen Einstellungen, der Ordner darf also vorher geleert werden. Ein Neustart ist nicht nötig.
Die Schlüssel bleiben stehen Der Ordner mit den Sicherheitsschlüsseln liegt bewusst ausserhalb des Anwendungsordners und wird beim Ersetzen der Dateien nicht angefasst – niemand wird durch ein Update abgemeldet. Haben Sie unter DataProtection:KeyPath einen eigenen Pfad gesetzt, achten Sie darauf, dass er weiterhin ausserhalb liegt.

Nur zum Testen: direkt starten (Konsole)

Dieselbe JKOrderManager.exe lässt sich auch direkt starten – per Doppelklick oder aus der Eingabeaufforderung. Es öffnet sich ein Konsolenfenster, und die Anwendung ist unter http://localhost:5000 erreichbar (ohne IIS).

Nicht für den Produktivbetrieb Der Direktstart ist zum Ausprobieren und für Tests gedacht: Es gibt kein HTTPS, keinen automatischen Start nach einem Neustart des Servers und keinen Neustart nach einem Absturz. Für den regulären Betrieb verwenden Sie den IIS (Schritt 3).

Alternativer Betrieb: als Windows-Dienst

Statt im IIS kann dieselbe Anwendung auch als Windows-Dienst laufen – praktisch, wenn auf dem Server kein IIS gewünscht ist. Der reguläre Weg bleibt der IIS-Betrieb.

  1. Dienst anlegen (Eingabeaufforderung als Administrator; das Leerzeichen nach binPath= gehört zur Syntax von sc.exe):
    sc.exe create BestellBar binPath= "D:\Sites\bestellbar\JKOrderManager.exe --urls http://localhost:5000" start= auto
    sc.exe description BestellBar "Bestell-Bar Web-Anwendung"
  2. Dienstkonto festlegen und diesem – wie in Schritt 4 – Zugriff auf die Datenbank geben. Ohne Angabe läuft der Dienst als LocalSystem:
    sc.exe config BestellBar obj= "DOMAIN\dienstkonto" password= "…"
  3. Starten bzw. stoppen:
    sc.exe start BestellBar
    sc.exe stop BestellBar
  4. Wieder entfernen (vorher stoppen): sc.exe delete BestellBar
HTTPS beachten Im Dienstbetrieb steht kein IIS davor, der das Zertifikat bereitstellt. Betreiben Sie den Dienst deshalb entweder nur im internen Netz, hinterlegen Sie ein Zertifikat für Kestrel, oder stellen Sie einen Reverse-Proxy davor – die Gäste-Bestellseiten und QR-Codes setzen HTTPS voraus.

Wenn es nicht läuft

SymptomPrüfen
HTTP-Fehler 500.30, Anwendung startet nicht Meist sind die Platzhalter in der appsettings.json nicht ersetzt (siehe Schritt 5). Für die genaue Fehlermeldung JKOrderManager.exe testweise direkt in einer Eingabeaufforderung im Anwendungsordner starten oder in die Windows-Ereignisanzeige schauen.
HTTP-Fehler 500.19 oder «Handler»-Fehler Das .NET Hosting Bundle fehlt oder wurde vor dem IIS installiert – (erneut) installieren und iisreset ausführen.
Datenbankfehler beim Start Connection String prüfen (Instanzname!); hat das Anwendungspool-Konto die Rechte aus Schritt 4?
Hilfe-Link zeigt «404» Ist das virtuelle Verzeichnis help aus Schritt 6 eingerichtet?
Keine Logdatei Serilog-Pfad in der appsettings.json prüfen; darf das Anwendungspool-Konto dort schreiben?
Stationsboards aktualisieren sich nicht mehr von selbst Läuft der Anwendungspool mit mehr als einem Arbeitsprozess? Siehe Nur ein Arbeitsprozess. Im Log steht in dem Fall eine entsprechende Warnung.
Seite Zu viele Anfragen beim Anmelden oder beim E-Mail-Versand Die Anfragebegrenzung hat zugeschlagen. Kurz warten – oder, wenn viele Benutzer über dieselbe Internet-Adresse zugreifen, die Werte unter RateLimits erhöhen.
Zertifikatswarnung im Browser, obwohl Let's Encrypt eingerichtet wurde Entweder stammt das Zertifikat aus der Testumgebung (Bezug ohne -LetsEncryptStaging wiederholen), oder der Bezug ist gescheitert und es gilt noch das selbstsignierte. Das Protokoll von win-acme liegt unter %ProgramData%\BestellBar\win-acme\Log.
Zertifikat läuft ab, obwohl die Erneuerung eingerichtet ist Läuft die geplante Aufgabe (Aufgabenplanung → Verlauf), und ist Port 80 weiterhin aus dem Internet erreichbar? Ohne ihn scheitert jede Erneuerung. install\scripts\Test-BestellBarInstallation.ps1 prüft beides.
Benutzer werden immer wieder abgemeldet, oder Formulare lassen sich nicht abschicken Der Schlüsselbund wird nicht dauerhaft gespeichert. Im Log den Pfad nachsehen (Zeile Data-Protection-Schlüssel) und prüfen, ob das Anwendungspool-Konto in diesem Ordner schreiben darf – siehe Sicherheitsschlüssel.