Beiträge von antondollmaier

    Guten Nachmittag zusammen,



    das hier ist der erste Thread (neben dem "Bump" bei "Kontakte löschen") einer kleinen Reihe an Problemen, die in den letzten Tagen insbesondere mit der SOAP-API aufgetreten sind.



    Die Installation lief verdammt angenehm durch, meinen herzlichen Dank dafür. Im Vergleich zu anderen Systemen macht das richtig Spass.


    Ein einziges Mini-Improvement habe ich für die Installation des Repositories:


    Code
    sudo wget -O/etc/apt/sources.list.d/liveconfig.list http://repo.liveconfig.com/debian-test/liveconfig.list


    (oder gab es einen Grund für die Aufteilung auf 2 Befehle (cd; sudo wget)?)



    Background-Infos zum Einsatzzweck: wir haben einen Server mit LiveConfig am Laufen, der zukünftig für Demo-Accounts genutzt wird.


    Interessent meldet sich auf einer Webseite an. Danach verwendet ein Cronjob die Daten, um den Interessenten im LiveConfig anzulegen sowie unsere Demo-Application im Account zu installieren. Der Interessent darf LiveConfig dabei nicht verwenden, sondern soll nur die Application einsetzen dürfen.



    Folgender vereinfachter Ablauf der Kommunikation mit LiveConfig:


    - ContactAdd
    - CustomerAdd
    - HostingSubscriptionAdd (mit "Demo" als Hosting-Angebot)
    - HostingDomainAdd
    - HostingSubdomainAdd (http://www.-Subdomain)
    - HostingDatabaseAdd


    Klappt alles gut, von kleineren (oder größeren) Problemen abgesehen:


    - beim Anlegen des Vertrages wird die Angabe der Server-Namen gefordert, obwohl überhaupt nur einer (Standard-Lizenz) vorhanden ist. Macht jetzt nicht soo viel aus, da zukünftig ja expandiert werden könnte bzw. es eh in der API so dokumentiert ist. Sinn macht es aber trotzdem bei einem einzigen vorhandenem Server nur wenig :)
    - Im Angebot ist "FTP: nein" definiert. Nach dem Anlegen des Vertrages per SOAP steht aber in der GUI "FTP-Zugänge: 1 (max. 0)" mit einem grünen Balken. Der Auslastungsbalken bei Datenbanken "1 (von max 1)" ist hingegen rot gefärbt.
    - Auch wird trotz "FTP: nein" der Systembenutzer so angelegt (muss für den Apachen / das Linux logischerweise eh), dass sich der Kunde, wenn ihm das Passwort bekannt wäre, per FTP anmelden könnte (das soll widerrum nicht). Habe ich nun dahingehend gelöst, dass beim Anlegen des Vertrages ein Zufallspasswort gesetzt wird. Per GUI ist die Passwort-Änderung eh nicht möglich, das passt letztendlich doch irgendwie.
    - Dadurch, dass der Kunde ohne LiveConfig-Benutzer-Account angelegt wird, wird die Steuerung des Accounts deutlich schwieriger. Es lässt sich im Nachhinein im LiveConfig für diesen Kunden unter Kunden -> Details -> "Übersicht" kein neuer Benutzer anlegen, so dass auch die Verwaltung der Domains/Datenbanken nicht mehr möglich ist. Der Button "Verbindung starten" fehlt ohne Benutzer ja komplett. Wurde dahingehend gelöst, dass zusätzlich noch "UserAdd" mit einem Random-Passwort aufgerufen wird.
    - Nach Ablauf der Demo-Phase kann zwar per SOAP-API der Hosting-Vertrag gelöscht werden, aber der Kunde nicht. Auch die Kontakte verbleiben als Leiche im System. Der Kunde könnte sich also noch weiterhin anmelden, sieht nur keine Daten mehr. Löschung müsste also per GUI manuell abgeschlossen werden.


    Bei den Kontakten wäre IMHO eine Übersicht, ähnlich der Kunden oder der Benutzer, recht vorteilhaft. Das würde dann "neuer Kontakt", "Kontakt editieren" sowie "Kontakt löschen" erleichtern - genau wie eine Detail-Anzeige, bei welchen Kunden bzw. Benutzern dieser Kontakt nun genau im Einsatz ist.




    Für 2014 hoffe ich eher auf Bugfixes statt auf neue Features. Wenn ich mir die Ticket-Liste unter liveconfig.com/dev so anschaue, wären die Bugfixes wichtiger als das nächste neue Feature mit u.U. noch mehr Bugs.



    Keep going! :)



    VG,
    Anton

    Guten Nachmittag,



    ich erlaube mir mal, den Thread aus der Versenkung zu holen.


    Wir werden auf einem Spezial-Server, auf dem LiveConfig primär wegen der SOAP-API (und einigen anderen Vorzügen gegenüber anderen Systemen...) läuft, einen hohen Durchlauf haben, was Kunden und Kundenkontakte angeht.


    Es wäre also richtig Klasse, wenn das Thema "Kunden löschen" bzw. "Kontakt löschen", nicht nur per SOAP-API, zeitnah umgesetzt werden könnte.



    Danke! :)

    Das erledigt eigentlich die SSL-Verschlüsselung (HTTPS).


    Ok, stimmt. Im Log/Traffic-Dump finden sich ja nur Hinweise auf die Domain/Server, nicht auf die tatsächliche URL.


    Zitat

    Mit "einfacher User" war aber nicht ein in LiveConfig eingeloggter User gemeint, oder? Denn die Session-ID ist immer an einen bestimmten Account innerhalb LiveConfig gebunden.


    War folgender Ablauf zwischen zwei Personen an unterschiedlichen Internetverbindungen und Browsern (Firefox/Chrome).


    - Person A loggt sich mit User A ein
    - Person B loggt sich mit User B ein
    - Person B gibt eine URL an Person A weiter: "/liveconfig/servers/manage?id=MxHGNnvy1i6aMKGjDsoie6qZ"
    - Person A ruft diese URL im Browser auf und hat nun die vollen Rechte von User B
    - im zweiten Tab ist immer noch die Session von User A aktiv und nutzbar, da andere Session-ID


    Funktionierte auch andersrum mit "/liveconfig/admin/account/contact?id=6pqjZCwf1cgiYhG0WVkVZZLu".


    Und das sollte eigentlich nicht passieren.


    Oder bin ich nur zu paranoid? :)

    Hallo,



    Da die Antwort nicht in einen Tweet passt, mache ich das hier etwas ausführlicher. :)


    Danke :)


    Zitat

    LiveConfig verwaltet seine Session-ID über die URL, da mehrere gleichzeitige Sessions mit dem selben Browser über Cookie-basierte Session-IDs nicht möglich sind.


    Macht auch durchaus Sinn, um somit gleichzeitig als unterschiedlicher User eingeloggt zu sein.


    Zitat

    Da LiveConfig nicht anfällig für XSS (Cross Site Scripting) ist, besteht die einzige "Gefahr" also in einer bewußten oder unbewußten Weitergabe der URL mitsamt Session-ID (z.B. Screenshot, ...).


    Mir fallen noch weitere Möglichkeiten ein:


    - Proxy-Caches/Logs
    - Internet-Cafes mit WLAN


    Zitat

    Um diesem vorzubeugen, werden wir in der nächsten Preview-Version (1.1.4) ein zusätzliches Cookie mit speichern, welches die Verwendung der Session-ID auf den jeweiligen Browser begrenzt.


    Klingt gut :)


    Zitat

    Eine Begrenzung auf die IP-Adresse des Logins (bzw. einer /16 (IPv4) oder /64 (IPv6) Maske) macht unserer Erfahrung nicht immer Sinn; wir haben häufig den Fall erlebt, dass ein Nutzer mehrere verschiedene Internet-Uplinks gleichzeitig nutzt (Outbound Load Balancing), die in völlig verschiedenen Netzbereichen lagen.


    Klar - auch AOL-Proxy-User dürften wenig begeistert von IP-Limitierungen sein.


    Allerdings war es etwas schockierend zu sehen, dass die simple Weitergabe der URL ("hier, schau mal!") plötzlich aus einem einfachen User einen Admin machte.


    Ansonsten bin ich auf die weiteren Tests und Funktionalitäten gespannt :)



    Viele Grüße,


    Anton Dollmaier