Man o man 
Du hast recht. Ich hab mich da total verannt mit dem Passwort SOAP-API.
SOAP-API = Zugangspass zur API überhaupt
und
// check checksum 'LiNk-PaSsWoRd' = das generierte Passwort für den Link.
Ich danke für Deinen Klapps auf mein Haupt. Schönen Abend noch.
Gruss Sabine
Danke Dir, aber die Seite hab ich gelesen. Und ganz ehrlich? Ich sehe hier keine Angabe zu
// check checksum
'LiNk-PaSsWoRd'
Denn wenn ich das in der example richtig ersehe, ist dies erforderlich um die Userdaten ausgeben zu lassen. Z.B. Kundennummer oder persönliche Anrede.
In dem verlinkten Text wird nur auf das SOAP-Passwort eingegangen
Gruss Sabine
Hallo,
beim hinzufügen eigener Links hab ich mir mal die examples.zip angesehen.
Darin enthalten steht folgendes
// initialize API instance
$LC = new LC(
// full URL to the LiveConfig SOAP API:
'https://liveconfig.example.org:8443/liveconfig/soap',
'admin', // LiveConfig user for SOAP API (usually 'admin')
'SoAp-PaSsWoRd' // SOAP API password
);
// check checksum
if (! $LC->checkSession('LiNk-PaSsWoRd')) {
die('<p class="error">Session check failed (' . htmlspecialchars($LC->getLastError()) . ')</p></body></html>');
}Dabei finde ich keine Info wie oder wo ich das 'LiNk-PaSsWoRd') erzeuge !
Kann mir da jemand mal einen Link angeben wo das Thema beschrieben ist?
Herzlichen Dank im Voraus.
Sabine
Mach auch Sinn wenn ein Kunde anruft, zufällig Meier heist und dann sagt: "Bei meiner Domain rapunzel.org" lauft Email nicht". Macht doch Sinn sich dann in LC einzuloggen, Domainliste anzeigen, Domain anklicken und ab zum Kundenaccount/zum Benutzer um dann von dort weitere Schritte zu unternehmen.
MfG
Hallo bady,
das ist kein Fehler sondern absichtlich so eingerichtet, da das Sperren des Email-Empfangs rechtlich sehr schwierig sein kann. Bitte informiere dich diesbezüglich bei einem Juristen.
eiclinde
Korrekt ist: Willkürliche Sperrung des Emailverkehres ist bedenklich. Insbesondere wenn die Maßnahme den Eindruck gewinnen läßt, dass dies zum Beispiel auf eine Nötigung herausg geht.(Umgangssprachlich: Ich will den Kunden nötigen zu zahlen.)
Daher Maßnahme unter 1) vornehmen.
Richtig ist:
1) Basiert die Sperrung auf das Erbringen meiner Leistung und der Kunde zahlt zum Beispiel nicht , kann nach angemessener Mahnung die Leistung gesperrt werden.
2) Bei Störungen oder Beeinträchtigungen die Auswirkungen auf Andere oder die Betriebssicherheit des Servers haben und ihren Ursprung beim Kundenaccount und dessen Inhalte etc haben, ist mir zur Vermeidung weiterer Beeinträchtigung auch Ohne vorheriger Meldung eine kurzfristige Sperrung erlaubt. Bin jedoch verpflichtet den betroffenen Kunden unverzüglich zu informieren. (Dies sollte in einer Form erfolgen, die ich im Nachhinein auch belegen kann)
3) Eine Sperrung ist auch dann zulässig, wenn ich von gesetzes Wege dazu veranlasst werde. Gerichtsbeschluss, Kenntnisnahme von illegalen Handlungen, nachweislich eine kriminelle Handlung unter Zuhilfenahme des Accountes erfolgt (z. Beispiel Kinderpornographie etc. )
Und nund as Wichtige: mein Text stellt keine Rechtsberatung dar.
Gruss Sabine
Hallo,
bei mir wie folgt das gleiche Problem:
Kunde hat SSL und http://domain.de rewrite to https://domain.de im LC
Entsprechend wird nun der Link http://domain.de/.stats/ wie folgt behandelt:
https://domain.de:8443/livecon…?http://domain.de/.stats/
aber durch obigen SSL und http://domain.de rewrite to https://domain.de im LC
wieder zu https geleitet
Gruss Sabine
Hallo,
ich bräuchte mal die Hilfe von Profis.
Gerade stelle ich beim Server fest, dass ich unter Verwendung meines EMailprogrammes und
Herstellen einer normalen pop3/smtp Verbindung
SMTP Standart Port: 25
POP3 Standart Port: 110
folgenden Fehler zurück bekomme:
!16.11.2014, 23:00:27: SEND - Nachricht wurde nicht versandt. Server Antwort - 5.7.1 <test@DOMAIN.de>: Relay access denied
Abholung geht scheinbar.
Anzumerken sei, dass TLS Verbindungen gehen. POP / SMTP
in der /etc/dovecot/dovecot.conf steht
Zitat
login_greeting = server ready
auth_mechanisms = plain login cram-md5
disable_plaintext_auth = no
Unter LiveConfig die Einstellungen von DOVECOT und POSTFIX geprüft.
Debian GNU/Linux 7.7 (wheezy)
LiveConfig 1.7.5-r3127
Dovecot: 2.1.7 (1:2.1.7-7+deb7u1)
Hat mir jemand einen guten Rat, woran das liegen kann?
Danke schön
Sabine
Ochhhh NÖÖÖÖ - schon wieder bin ich darauf reingefallen.
Ich danke Dir für den Hammer auf den Kopf
genau daran liegt es .
Hallo,
ich hoffe hier mal auf Hilfe bei einem seltsamen Problem.
Was wollte ich machen? Ich wollte ein Content Management System ( kajona ) unter einer Suddomain die über ein eigenen Unterordner verfügt , installieren.
Diesen Vorgang erledige ich immer erfolgreich bei Servern mit Confixx, Plesk, Froxlor, ISPConfig.
Bei LC wird nach dem Aufruf der Subdomain ( SUBDOMAIN.DOMAIN.de ) um das CMS zu installieren jedoch nicht:
SUBDOMAIN.DOMAIN.de/index.php genutzt sondern geht dann auf DOMAIN.de/UNTERORDER/index.php
Die SubDomain wurde wie folgt angelegt: Bild Subdomain anlegen
Was könnte die Ursache sein, dass LC dem Script nicht die Subdomain meldet sondern die Hauptdomain mit Unterverzeichnis ??
Besten Dank für Eure Hilfe und jeden Tip
Gruss Sabine
###################
Serverdaten:
Debian GNU/Linux 7.6 (wheezy)
Apache2
LiveConfig 1.7.4-r3086
###################
Kurzer NACHTRAG
Ich habe nun auf dem Testserver gesehen, dass ich bereits erfolgreich, schon einmal mit einer anderen Domain und unter einer vorherigen LC Version, eine Sudomain entsprechend oben angelegt hatte.
Ich habe nun geprüft und getestet, was der Unterschied ist oder war?
In der erfolgreichen variante wird die Hauptdomain auch bereits in ein Unterverzeichnis geleitet.
DOMAIN.de /htdocs/WEBSEITEN/
test.DOMAIN.de /htdocs/SUBDOMAINWEBSEITEN/
Das funktioniert.
Somit entsteht das Problem wohl nur wenn die Hauptdomain direkt auf /htdocs/ geht. Und dann eine Subdomain auf /htdocs/VERZEICHNIS/
