TypoLIGHT Desktop Management

[matze]

Hallo.

Nach der ganzen Aufregung um die Sicherheitslücke kam ich auf die Idee ein Tool, das ich bereits intern bei mir nutze etwas aufzubohren.

Ich stelle mir das so vor: Es gibt ein Programm, welches auf eurem Windows-PC installiert wird. Dieses Programm kann dann Funktionen auf den verschiedenen TL Installationen auf verschiedenen Servern ausführen.

Mein internes Tool mach im Moment noch nicht viel mehr als ein Interface um Informationen der Server anzuzeigen.

Darum also meine Frage an alle Admins und Entwickler:
Besteht denn generell Interesse seitens der Admins das zu benutzen und seitens der Entwickler evtl Funktionen ihrer Erweiterungen da einzubinden? Denn dann würde ich das nämlich mal richtig programmieren und durchdenken.

Was würdet ihr denn von einem solches Programm erwarten?

Liebe Grüße,
Matze

[lindesbs]

- Welchen Vorteil soll das Tool denn bieten ?
- Wie wird die Kommunikation zwischen TL Installation und deinem Tool geregelt ?
- Sollen mehrere Installationen "behandelt" werden ?
- Was soll man generell damit machen koennen, was man mit der "Online" Version nicht machen kann ?

[andreas.schempp]

BÖÖÖÖSE

was ist mit den Mac-Usern?

Ich würde empfehlen ein Web-Tool zu machen. Die Funktionen sind natürlich die Frage, aber interessant wäre z.B. welche TYPOlight-Version wo läuft. Cool ist die Übersicht beim Live-Update-Check, aber ich hab meist pro Installation eine Update-ID (damit der Kunde die nicht "klauen" kann). Weiter wäre ggf. Interessant ob Erweiterungs-Updates verfügbar wären.

[matze]

- Welchen Vorteil soll das Tool denn bieten ?

Verwaltungsaufgaben bzw Programmfunktionen gleichzeitig auf mehreren Server auszuführen bzw Meldungen von mehreren Server in einer Oberfläche zu haben.

- Wie wird die Kommunikation zwischen TL Installation und deinem Tool geregelt ?

HTTP

- Sollen mehrere Installationen "behandelt" werden ?

Das ist der Sinn.

- Was soll man generell damit machen koennen, was man mit der "Online" Version nicht machen kann ?

Das müssten wir noch überlegen...


Das mit den Erweiterungsupdates ist ne gute Idee!!

[Schlauchbeutelmaschine]

Hallo matze,

erstmal super Idee, ich war auch um überlegen so etwas umzusetzen.

Wie würdest du das Tool den aufbauen? Gerade auch aus Gründen der Sicherheit?
Ich habe da immer die Befürchtung das man dadurch Angreifern neue Möglichkeiten eröffnet.

Aber wenn du eine erste Version fertig haben solltest und Unterstützung beim Testen brauchst biete ich mich gerne an.

Gruß Sabri

[matze]

Im Endeffekt müsste sich das Tool mit einem Account, der die erforderlichen Rechte besitzt bei TL anmelden. Das geschieht wie beim normalen Browser-LogIn via HTTP. Da bleibt es dann dem Admin selber überlassen, wie er sein System schützt.
Auf der Client-Seite würde ich die Daten und evtl Passwörter (wenn der User sie im Client hinterlegen will) in einer verschlüsselten Datenbank ablegen.

[Toflar]

Wir haben ganz viele verschieden Usergruppen hier...

Wenn schon, dann schreibt das ganze in Java, damit ihr nicht mit Anfragen der Non-Windows-User überhäuft werdet
Aber an sich fände ich ne Übersicht meiner Kunden und wo welche Version läuft, sehr, sehr cool!

[andreas.schempp]

PHP

[matze]

Also wenn ich sowas mache, dann auf jeden Fall nur für Windows.
Aber man kann die Schnittstelle ja so offen halten, dass jemand anderes eine Max-OS Version oder eine PHP Version machen kann.

Wie gesagt: Wenn ich das mache wirds Windows. Aber meine Tools sind immer so aufgebaut, dass sie unter den Wine-artigen Emulatoren laufen.

Ich würde gerne mal eine Umfrage starten, wer denn alles MacOS und wer Windows hat (so zahlenmäßig unter den Usern) und wer überhaupt größere bzw mehrere TL Installationen verwalten muss.
Ich habe da mal Nina angeschrieben aber noch keine Reaktion.

[Toflar]

PHP

Ich dachte nur es müsse als lokales Programm laufen

[andreas.schempp]

Auch PHP kann als lokales Programm laufen...

Ich weis dass sehr viele Webdesigner und TYPOlight-Anwender auf Mac arbeiten, von daher fände ich eine Win-Version wirklich nicht gut (aus welchem Grund denn?).

[matze]

Wie läuft denn PHP als eigenständiges Programm?

Auf dem Mac entwickle ich nicht weil ich
a) keinen Mac da habe um darauf zu programmieren
b) ich es unheimlich nervig und aufwändig finde nativ für Mac zu entwicklen
c) ich unter Windows einfach besser zurechtkomme und selber auch Win habe
d) es schon sein kann dass es viele Mac User gibt, aber das müssten wir wenn schon mal per Statistik ermitteln und außerdem gibt es für den Mac ja Emulatoren. Für Windows nicht.

Das wären jetzt mal die objektiven Gründe. Wie gesagt: Ich definiere meine Schnittstelle gerne so offen, dass jeder andere auch dafür Software schreiben kann.

Du bist aber hartnäckig

[planepix]

Interessante Idee - wie wäre eine Anwendung in Adobe Air? Das liefe lokal und auf WIN und Mac..

[andreas.schempp]

Air wär natürlich auch eine Idee. Ich hab halt mehr gedacht ein Paket das ich auf meinen Webserver laden und damit die Kundensysteme überwachen kann. Könnte sogar ein TYPOlight-Modul sein!

[matze]

Ich hab halt mehr gedacht ein Paket das ich auf meinen Webserver laden und damit die Kundensysteme überwachen kann. Könnte sogar ein TYPOlight-Modul sein!

das wäre auch nicht schlecht. Da wärst dann du als Modul-Crack gefordert da was zu bauen

[andreas.schempp]

Hehe, kann dich gerne unterstützen, aber zuerst fehlen ja mal die Ideen

[planepix]

Ok ich tippe mal Vorschläge ein

- erhöhter Zugriffsschutz, wenn dort Accountdaten hinterlegt werden.
- pro Kunde / Projekt Eingabemaske für URL, FTP-Daten, MySQL-Link
- Anzeige ob LiveUpdate ID vorhanden
- ggf. Eingabefeld für Notizen (letzte Änderung, Umstellungen etc.)
- Auflistung der installierten Erweiterungen (aktuell, neue Version verfügbar)
- Check ob die Seite erreichbar ist (grüne "LED" ok, rote "LED" nicht ok)

[matze]

- erhöhter Zugriffsschutz, wenn dort Accountdaten hinterlegt werden.
- pro Kunde / Projekt Eingabemaske für URL, FTP-Daten, MySQL-Link

Was ist für dich denn ein erhöhter Zugriffsschutz?
Und wozu denn die FTP und MySQL Daten?

[planepix]

erhöhter Zugriffsschutz:
z. B. 2-stufige Authentifizierung, damit man nicht wirklich ohne weiteres von außen an die Daten kommt (2 x htaccess z. B.).
Als Module wäre dies mit salted MD5 Verschlüsselung schon sicher genug?

FTP / SQL:
Quasi als Ablage, damit man alle relevanten Daten direkt zur Verfügung hat.

FTP-Link stellt z. B. Verbindung zu FireFTP / Filezilla her, Link auf MySQL direkt zu phpMyAdmin (ok,, vielleicht Overkill )

[matze]

Also zum Thema Zugriffsschutz:
Ich hätte einfach den gleichen LogIn-Mechanismus wie TL selber verwendet. Damit kann sich jeder Admin aussuchen, ob und wie er das schützt.

[xtra]

erhöhter Zugriffsschutz:
Als Module wäre dies mit salted MD5 Verschlüsselung schon sicher genug?

s/MD5/SHA1/ dann sollte es passen.

Als Modul wuerde ich eine XMLRPC(habe ich erst letztens ein generisches Servermodul fuer TYPOlight programmiert) oder SOAP Schnittstelle(erinnert mich daran nusoap aus tenside in ein plugin auszulagern) begruessen.
Dann kann man wirklich komplett unabhaengig vom OS arbeiten und einen client in jeglicher Sprache programmieren, da die Schnittstelle offene Standards unterstuetzt.
Die kann ich auch beides schreiben, wenn gewuenscht und eine entsprechende API des "Moduls" bereitgestellt ist, welche Daten ich liefern soll.

Gruss
Chris

[FloB]

Wenn das noch eine Rolle spielt: Adobe Air ist sicherlich nicht schlecht, man könnte auch über XULRunner nachdenken, das ist die Applikation, die unter (fast) allen Mozilla-Produkten läuft .

[schman]

was ich noch cool finden würde wäre der letzte eingeloggte User anzuzeigen, und welchen Artikel/Modul etc. er/sie geändert hat.

[matze]

Hallo.

Also ich habe mich mal hingesetzt und das Ganze mal angefangen.
Ich präsentiere hier also die allererste Alpha-Version.

Screenshot:
tldm.PNG

Im Anhang findet ihr ein Zip. Darin ist die EXE mit dem Monitoring-Tool sowie die Erweiterung, die in TypoLight in den Modules-Ordner zu installieren ist.

Dann einfach den Pfad zu dem Modul in der Software eintragen. Das müsste eigentlich selbsterklärend sein.

Der Modul für TL ist so konzipiert, dass jeder Entwickler mittels Hooks seine eigenen Meldungen an die Monitoring-Software schicken kann. Zur Demonstration habe ich eine Klasse geschrieben, die sich meldet, sobald eine neue TL Version verfügbar ist.

Es gibt bis jetzt 2 Hooks: Einer der einmal beim Start der Software (also bei erstern Verbinden) ausgeführt wird. Hier frage ich z.B. ab, ob es eine neue TL Version gibt.
Mit dem 2. Hook kann man dann Ereignisse an die Software senden. Hierbei kann man Informationen, Warnungen und Fehler unterscheiden.

Die Software speicher sämtliche Passwörter usw in einem verschlüsselten ZIP File auf dem Rechner. Das ZIP File ist mit AES 265 Bit verschlüsselt, sodass das kaum zu knacken ist. Das Passwort für die Verschlüsselung vergibt man selbstverständlich selber. Das Passwort kann auch im Falle des Falles nicht wiederhergestellt werden!
Wer möchte, kann sich selbst davon überzeugen. Das Zip wird unter C:\Dokumente und Einstellungen\USER\Anwendungsdaten\Matthias Feist\TypoLight Desktop Management\ gespeichert. Achtung: Nicht alle ZIP-Tools können mit AES 256 umgehen. Ich hab es mit 7zip probiert. Das geht.

Wer möchte bitte testen und Feedback geben!

Danke!

Hier der Download-Link: http://www.matf.de/tldm.zip

[schman]

find ich cool danke schon mal dafür aber irgendwie bin ich zu blöd den Pfad richtig einzugeben

Ich hab nicht ganz verstanden was für ein Pfad ich eingeben muss.

Dann einfach den Pfad zu dem Modul in der Software eintragen

Ist das der Pfad zum Plugin in TL? Könntest du hier ev. bitte einen Beispielpfad angeben?

Danke nochmals

[Corazon]

ich hab das so verstanden das du den ordner tldm-api in dein moduls verzeichnis der tl installation copiern mußt und dann bei desctopmanager dir URL zum modulverzeinis eingeben mußt.. bin aber auch noch am testen des wegen ohne gewähr
gruß

[schman]

so hab ich das auch verstanden. Ich hab jetzt folgendes ausprobiert

http://domain.tld/system/modules
http://domain.tld/system/modules/tldm-api

HTTP Verbindung: Fehler
Fehlertext: HTTP/1.1 404 Not Found
API meldet:

[andreas.schempp]

Probier doch mal http://domain.tld/system/modules/tldm-api/api.php

@matze: Könntest du (mir) kurz erklären warum du eine eigene User-Klasse gemacht hast?

[schman]

das sieht schon besser aus
Danke Andreas.

Der Verbindungstest funktioniert jetzt, leider hab ich jetzt noch ein Unauthorized wenn ich die Installation überprüfen lasse. Benutzername und Passwort stimmen aber

[planepix]

Hallo zusammen, ich habe das auch so getestet - ich vermute mehr passiert in diesem Status des Tools noch nicht...?
So wie Andreas es geschrieben hat hatte ich es auch eingetragen, die Meldung bleibt die gleiche.

[Corazon]

so mein ergebnis
HTTP Verbindung: OK
Fehlertext:
API meldet: Test OK.

aber bei details HTTP/1.1 401 unauthorized..

wie aber planepix sacht mehr is ja auch noch nicht..
getestet überrings mit 2.8

gruß

ach .. man muß es wenn der test gut ging einmal schlißen und wieder starten dann kommt bei mir als ergebins die Tlversion !!

[schman]

so ich hab da gleich ein paar Fragen

• Namen sollte selbständig vergeben werden können
• http automatisch voransetzen

Ich habe mehrere Installationen auf meiner Domain und lege jedes mal ein Unterverzeichnis an somit sieht das dann zb so aus:
http://dev.domain.tld/tl1
http://dev.domain.tld/tl2

In der Übersicht sehe ich jetzt nur dev.domain.tld, hier wäre es fein wenn der namen selbst gewählt werden könnte.

dummerweise vergesse ich immer das http:// davor, ev könntest du das standardmäßig angeben, wenn jemand zB mit https arbeitet muss man halt das s dranhängen

[matze]

Uff gleich so viel Feedback

Also mal der Reihe nach:

Als Pfad zum Modul muss tatsächlich der ganze Pfad von http:// bis zu api.php eingegeben werden. Ich dachte das ist klar, denn es steht ja ein Beispiel in hellem Grau in dem Feld, wenn noch nichts eingetragen ist.

Das Tool kann wirklich noch nicht sehr viel, bis auf die Anzeige der Version. Hier kann aber von Seiten der Extension-Entwickler eigene Funktionalität mittels des Hooks eingefügt werden (bzw das soll später einmal so laufen, wenn den Interesse an dem Tool besteht)

Es kann schon sein, dass gerade wenn man viel rumspiel zwischendurch die Meldung "Unauthorized" kommt. Da hilft ein einfacher Neustart Das muss ich noch ändern. Der Grund ist: Die Software erkennt noch nicht, dass was geändert wurde und schickt deswegen den Login nicht nochmal neu.

Die Idee den Namen selbst vergeben zu lassen werde ich demnächst mal umsetzen. Daran hab ich gar nicht gedacht,

@Andreas: Ich habe mir eine eigene User-Klasse gebaut, weil ich einen Backend-User haben wollte zur Authentifizierung. Die Backend-User-Klasse konnte ich aber nicht nehmen, weil ich von der nicht gemeldet bekomme, ob erfolgreich authentifiziert wurde oder nicht. Stattdessen macht die Backend-User-Klasse einfach einen Header redirect.
Fällt dir eine besser Lösung ein? Ich persönlich bin damit nämlich nicht wirklich zufrieden. Am liebsten wäre es mir, eine fertige Klasse aus TL zu verwenden. Damit wäre ich nämlich vor Änderungen in künfigen Version recht sicher...

[xtra]

@Andreas: Ich habe mir eine eigene User-Klasse gebaut, weil ich einen Backend-User haben wollte zur Authentifizierung. Die Backend-User-Klasse konnte ich aber nicht nehmen, weil ich von der nicht gemeldet bekomme, ob erfolgreich authentifiziert wurde oder nicht. Stattdessen macht die Backend-User-Klasse einfach einen Header redirect.
Fällt dir eine besser Lösung ein? Ich persönlich bin damit nämlich nicht wirklich zufrieden. Am liebsten wäre es mir, eine fertige Klasse aus TL zu verwenden. Damit wäre ich nämlich vor Änderungen in künfigen Version recht sicher...

Der redirect erfolgt nur bei fehlgeschlagenem login.
Ich verwende bei mir in meinem xmlrpc handler (stark vereinfacht) folgendes:

    $this->import('BackendUser', 'User');
    // Login
    if ($this->User->login())
    {
        // ok, we can work.
    } 

Wichtig ist, dass im post data die Felder username und password gesetzt sind, aber das ist ja logisch.

[matze]

Ja aber wenn der Login fehlschlägt, dann wird in deinem Fall der redirect ausgelöst. Ich wollte da aber gerne eine Meldung ausgeben...

[xtra]

Ja aber wenn der Login fehlschlägt, dann wird in deinem Fall der redirect ausgelöst. Ich wollte da aber gerne eine Meldung ausgeben...

Wer sagt dass du den redirect akzeptieren musst?
Du bist ein HTTP client und kannst entsprechend reagieren wie du willst.
Sollte jemand auf die Verlegenheit kommen mit einem anderen client auf die API zuzugreifen, so wird er auf den normalen login redirected, was ich als eine recht gute Loesung empfinde.

[matze]

Das müsste man jetzt mal überlegen.
Ich wollte das eigentlich so machen, dass die Software den HTTP Output wirklich auch so interpretiert wie er gemeint ist. Also ein Redirect soll auch wirklich ein Redirect sein und nicht als "der Login hat nicht geklappt" interpretiert werden.
Es kann ja auch sein, dass ein Admin lieber seine Api woanders liegen hat und der Software mit dem Redirect den Weg weisen will...

Generell habe ich da kein Problem auch auf den Redirect zu reagieren

[andreas.schempp]

Du könntest natürlich auch "isAjax" als GET setzen, dann wird auch nicht weitergeleitet.

[FloB]

Ja aber wenn der Login fehlschlägt, dann wird in deinem Fall der redirect ausgelöst. Ich wollte da aber gerne eine Meldung ausgeben...

Ähm, sollte nicht trotz redirect ein Forbidden-Error kommen? Das schließt sich ja nicht aus.

[matze]

Ähm, sollte nicht trotz redirect ein Forbidden-Error kommen? Das schließt sich ja nicht aus.

Doch leider schon. Denn die meisten HTTP Client Libraries lassen dann keinen Zugriff auf den Content zu sonder führen den Redirect durch.

Das mit dem isAjax werde ich mir mal anschauen Danke für den Tipp!