No description
  • Go 52.3%
  • Svelte 35.7%
  • HTML 9.4%
  • TypeScript 1.3%
  • PLpgSQL 0.9%
  • Other 0.4%
Find a file
Alexander Ebel b2eea8bc24 feat: Portrait detection, upload progress, HTTPS web UI, screenshot throttling, dashboard
- Portrait mode: parse SCREEN_ROTATION from GETResponse, store is_portrait in DB
- Screenshots rotated 90° in grid when display is in portrait mode
- Media upload: progress bar with filename, percentage, file counter (XMLHttpRequest)
- Web UI HTTPS: WEB_UI_HTTPS=true serves frontend over TLS
- Screenshot forward throttling: SCREENSHOT_FORWARD_INTERVAL (minutes per device, default 30)
- Traffic file logging: TRAFFIC_FILE_ENABLED (default false, saves disk)
- Bind address: BIND_ADDRESS config for all listeners
- Silent mode: --silent flag suppresses console output
- Dashboard page with device stats, resource overview, quick actions
- Wartung dropdown menu (Monitoring, Protocol Inspector, Functions, Playlists, Admin)
- Org list with device/group/member counts
- Device assignment modal with live search and org grouping
- Delete org requires typing name to confirm
- Preset deploy via WSRMReverse SET queue
- Preset group modal with collapsible tree
- Configurable FFMPEG_PATH

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-30 19:03:49 +02:00
cmd feat: Portrait detection, upload progress, HTTPS web UI, screenshot throttling, dashboard 2026-03-30 19:03:49 +02:00
docs feat: Displays Overview Grid Layout, Device Tabs, and Group Management 2026-03-26 20:01:34 +01:00
gosignage-web feat: Portrait detection, upload progress, HTTPS web UI, screenshot throttling, dashboard 2026-03-30 19:03:49 +02:00
internal feat: Portrait detection, upload progress, HTTPS web UI, screenshot throttling, dashboard 2026-03-30 19:03:49 +02:00
migrations feat: Default Logo/Content per organization with S/W DOWNLOAD deploy via WSRMReverse 2026-03-30 12:33:48 +02:00
web Fix group filtering and add ListAssignments handler 2026-03-23 13:41:14 +01:00
.env.example Initial commit of gosignage proxy server 2026-03-22 20:53:08 +01:00
.gitignore chore: Remove binaries from git and add to .gitignore 2026-03-23 10:13:12 +01:00
AGENTS.md Fix playlist update tracking and add logging documentation 2026-03-23 14:11:37 +01:00
analyze_traffic.py feat: Displays Overview Grid Layout, Device Tabs, and Group Management 2026-03-26 20:01:34 +01:00
go.mod feat: Add user authentication with JWT, role-based access control, and Apple OAuth 2026-03-28 11:35:28 +01:00
go.sum feat: Add user authentication with JWT, role-based access control, and Apple OAuth 2026-03-28 11:35:28 +01:00
gosignage-server feat: Displays Overview Grid Layout, Device Tabs, and Group Management 2026-03-26 20:01:34 +01:00
main feat: Add rate limiting for WebSocket events (5 minutes per device) 2026-03-24 09:40:12 +01:00
PLAYLIST_PRIORITY.md Document playlist priority system 2026-03-23 14:08:18 +01:00
README.md feat: Add time synchronization for Samsung displays 2026-03-23 11:06:32 +01:00
TODO.md feat: Add rate limiting for WebSocket events (5 minutes per device) 2026-03-24 09:40:12 +01:00

GoSignage - Samsung MagicInfo Alternative

Eine in Go geschriebene Open-Source-Alternative zum Samsung MagicInfo Premium Server für Digital Signage Displays.

Features

  • Samsung-kompatible SOAP/OpenAPI: Displays können sich mit requestBootstrapping, isApproval und sendKeepAlive anmelden
  • Keine Lizenzbeschränkung: Alle Displays werden akzeptiert (keine "SPLAYER"-Lizenz nötig)
  • REST API: Verwalten Sie Displays über moderne REST-Endpunkte
  • Web-UI: Einfache Verwaltungsoberfläche auf Port 3000
  • Power-Control: Displays ein-/ausschalten über die API
  • Approval-System: Displays müssen manuell freigegeben werden

Schnelle Installation

1. Voraussetzungen

  • Go 1.21+
  • PostgreSQL 15+
  • OpenSSL (für Zertifikat-Konvertierung)

2. PostgreSQL Datenbank erstellen

CREATE DATABASE gosignage;
CREATE USER gosignage WITH PASSWORD 'gosignage';
GRANT ALL PRIVILEGES ON DATABASE gosignage TO gosignage;

3. Zertifikate vorbereiten

Die Samsung-Zertifikate wurden bereits aus dem MagicInfo-Server extrahiert:

  • ./certs/server.crt - Samsung Zertifikat
  • ./certs/server.key - Privater Schlüssel

4. Konfiguration

cp .env.example .env
# Bearbeiten Sie .env mit Ihren Datenbankeinstellungen

5. Starten

# Abhängigkeiten installieren
go mod tidy

# Bauen
go build -o gosignage ./cmd/server

# Starten
./gosignage

Der Server läuft dann auf:

  • Port 7001 (HTTPS): Für Display-Kommunikation und REST API
  • Port 3000 (HTTP): Web-Verwaltungsoberfläche

API Endpunkte

Display-Kommunikation (SOAP/OpenAPI)

  • POST /openapi - Haupt-Endpunkt für Displays
    • requestBootstrapping - Display registriert sich
    • isApproval - Prüft Freigabe-Status
    • sendKeepAlive - Heartbeat

REST API (für Management)

  • GET /api/v1/devices - Liste aller Displays
  • GET /api/v1/devices/:id - Einzelnes Display
  • POST /api/v1/devices/:id/approve - Display freigeben
  • POST /api/v1/devices/:id/power - Power steuern (Body: {"state": "ON"} oder {"state": "OFF"})
  • POST /api/v1/devices/:id/panel - Panel steuern (Body: {"state": "ON"} oder {"state": "OFF"})
  • POST /api/v1/devices/:id/screenshot - Screenshot anfordern
  • POST /api/v1/devices/:id/monitoring - Monitoring-Daten abfragen (CPU, RAM)
  • POST /api/v1/devices/:id/timesync - Uhrzeit synchronisieren
  • DELETE /api/v1/devices/:id - Display löschen

Web-UI

Gehen Sie zu http://localhost:3000 für die Verwaltungsoberfläche.

Display-Konfiguration

Auf den Samsung Displays muss die Server-URL konfiguriert werden:

Server URL: https://[IHRE-SERVER-IP]:7001/

Wichtig: Die Displays validieren das SSL-Zertifikat. Da wir das originale Samsung-Zertifikat verwenden, sollten die Displays es akzeptieren.

Architektur

┌─────────────┐      HTTPS (7001)      ┌──────────────┐
│   Display   │◄──────────────────────►│  GoSignage   │
│  (Samsung)  │   SOAP/OpenAPI          │    Server    │
└─────────────┘                         └──────┬───────┘
                                              │
                                              │ SQL
                                              ▼
                                        ┌──────────────┐
                                        │  PostgreSQL  │
                                        └──────────────┘
                                              ▲
                                              │ HTTP (3000)
┌─────────────┐      ┌──────────────┐         │
│   Admin     │◄────►│   Web UI     │◄────────┘
└─────────────┘      └──────────────┘

Entwicklung

Projektstruktur

gosignage/
├── cmd/server/          # Haupteinstiegspunkt
├── internal/
│   ├── config/          # Konfiguration
│   ├── database/        # Datenbankverbindung
│   ├── handlers/        # HTTP/REST Handler
│   ├── models/          # Datenmodelle
│   └── repository/      # Datenbank-Abstraktion
├── web/                 # Web-UI Dateien
├── certs/               # SSL Zertifikate
└── migrations/          # SQL Migrations

Tests ausführen

go test ./...

Lizenz

MIT License - Siehe LICENSE Datei

Wichtige Architektur-Erkenntnisse

Kommunikations-Protokoll

Wichtig: Sowohl GoSignage als auch der original MagicInfo Server können NICHT direkt mit den Displays kommunizieren! Die Kommunikation funktioniert ausschließlich über Reverse-Polling:

┌─────────────┐         Polling          ┌──────────────┐
│  Display    │◄───────────────────────►│   Server     │
│  (Port X)   │   (alle 5-10 Sekunden)   │ (Port 7001)  │
└─────────────┘                          └──────────────┘
       │                                        │
       │   1. Display fragt: "Gibt es Befehle?" │
       │◄─────────────────────────────────────────┤
       │                                        │
       │   2. Server antwortet mit Befehlen      │
       ├────────────────────────────────────────►│
       │                                        │
       │   3. Display bestätigt Ausführung      │
       │◄─────────────────────────────────────────┤

Konsequenzen:

  • Der Server kann keine Befehle initiieren
  • Befehle werden in einer Queue gespeichert
  • Das Display holt Befehle beim nächsten Polling ab
  • Monitoring-Daten (CPU, RAM, etc.) werden erst angezeigt, wenn das Display antwortet

MagicInfo-Protokoll Details

GET Befehl für Monitoring (basierend auf PCAP-Analyse):

<srm:GET>
  <srm:MO_SEQUENCE>
    <srm:MO>
      <srm:MO_PATH>.MO.DEVICE_CONF.SYSTEM_INFO</srm:MO_PATH>
      <srm:MO_VALUE/>
    </srm:MO>
  </srm:MO_SEQUENCE>
</srm:GET>

Antwort des Displays:

<srm:GETResponse>
  <srm:MO_SEQUENCE>
    <srm:MO>
      <srm:MO_PATH>.MO.DEVICE_CONF.SYSTEM_INFO.CPU_USAGE</srm:MO_PATH>
      <srm:MO_VALUE>19</srm:MO_VALUE>
    </srm:MO>
    <srm:MO>
      <srm:MO_PATH>.MO.DEVICE_CONF.SYSTEM_INFO.RAM_USAGE</srm:MO_PATH>
      <srm:MO_VALUE>58</srm:MO_VALUE>
    </srm:MO>
    ...
  </srm:MO_SEQUENCE>
</srm:GETResponse>

Danksagung

Dieses Projekt basiert auf der Reverse-Engineering-Analyse des Samsung MagicInfo Premium Servers.