# E-Mail Module Soap API - Doku?



## pezi (17. Sep. 2009)

Nach
http://www.ispconfig.org/news.htm

_*2009-09-03*
              ISPConfig 3.0.1.4 released

This is the final version of the ISPConfig 3.0.1.4. This release fixes 
sevaral bugs from ISPConfig 3.0.1.3, adds a *SOAP API* for the email module and improved translations. 
_ 
gibt es ein SOAP API für das E-Mail Modul. Gibt es zu dieser Schnittstelle eine Doku?

Peter


----------



## Till (17. Sep. 2009)

Es gibt keine Doku, aber Du findest die Beispieldateien im remote_client Verzeichnis des installer tar.gz.


----------



## pezi (17. Sep. 2009)

Hallo Till!
Danke für die prompte Antwort. Die Beispiele sollten reichen.

Hintergrund ist folgender. Ich bin der Entwickler vom folgendem Projekt
http://www.open-xchange.com/forum/showthread.php?t=3750
Eine freie Admin GUI für den OX6 Server. Über Plugins ist angedacht, dass beim Anlegen eines OX-Benutzers auch das entsprechen E-Mail Konto angelegt wird. Hier möchte z.B ein Plugin für ISPConfig 3 entwickeln.

Peter


----------



## Till (18. Sep. 2009)

Die GUI sieht ja nett aus  Wenn Due das SOAP API von ISPConfig testen möchtest, dann nimm am besten ein ISPConfig vom SVN, da wir da noch ein paar kleinere Bugs gefixt haben und auch noch fehlende Funktionen zum Abruf von Daten eingefügt wurden.


----------



## pezi (13. Nov. 2009)

Bei meinem Open-Xchange-GUI Projekt wurde die Plugin-Erweiterung fertiggestellt:
http://www.open-xchange.com/forum/showpost.php?p=15387&postcount=26

Auf dieser Erweiterung aufbauend will ich jetzt mit einem OX-ISPconfig3 Plugin beginnen. Wird ein OX-Benutzer angelegt, so soll dessen Mail-Box über das Plugin automatisch angelegt werden.  

Nur ich scheitere schon am Anfang:
Ein ISPConfig 3.0.1.6 Server

Das Remote Beispiel (example.php) auf einem Windows-Client mit PHP 5.3.0 an meine Gegebenheiten angepasst und innerhalb einer DOS-Box aufgerufen.


```
//* Login credentials
$username = 'admin';
$password = 'xxxxxx';

//* The URI to the remoting interface. Please replace with the URI to your real server
$soap_location = 'http://192.168.1.3:9000/remote/index.php';
$soap_uri = 'http://192.168.1.3:9000/remote/';
....
```
Zur Info: http://192.168.1.3:9000/remote/index.php - liefert: 

```
<SOAP-ENV:Envelope>
−
<SOAP-ENV:Body>
−
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring>Bad Request. Can't find HTTP_RAW_POST_DATA</faultstring>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
```
Ich bekomme aber immer den Fehler.
SOAP Error: The login failed. Username or password wrong.
Die Login-Daten stimmen - mit denen kann ich mich über das Panel anmelden. Detto habe ich es mit einem vorhandenen Benutzer versucht - gleiche Fehlermeldung.

Was mache ich falsch?
Peter

P.S: Meine PHP-Kentnisse sind leider eher bescheiden.


----------



## Till (13. Nov. 2009)

Remote user sind keine controlpanel Benutzer. Remote User werden extra angelegt da Du bei ihnen auch noch einschränken kannst, welche Funktionen im api sie aufrufen können. Schau mal unter system > remote users


----------



## pezi (13. Nov. 2009)

Vielen Dank für die promte Antwort! Jetzt funktioniert alles! Nochmals Danke!
Peter


----------



## pezi (18. Nov. 2009)

Ich bin momentan dabei eine Java-Lib auf AXIS basierend zu implementieren, die die SOAP Schnittstelle von ISPconfig3 ansteuert. Funktioniert eigentlich alles recht gut - mit Hilfe von Beispielen, den Sourcen und dem DB-Layout ist dies eine straight ahead Geschichte. Die fertige Lib wird  dann, wie das ganze OXGUI Projekt , als Open Source zur Verfügung stehen.

Als Feature für die Zukunft würde ich mir getAll() Methoden für die SOAP Schnittstellen wünschen. z.B. gibt mir alle MailDomains, MailUser, etc zurück. Solche Methoden sind notwendig wenn ich Konverter schreiben möchte - z.B lege für alle bestehende MailUser einer bestimmten MailDomain einen OX Account an. Für das erste werde ich für die Konverter direkt auf die DB gehen, um die Benutzer zu enumerieren. 

Weiters ist mir aufgefallen - dieTabelle remote_session beinhaltet die Sessions ID des Remote Users. Wie es scheint bleiben diese Sessions-Einträge erhalten, wenn der Remote-User - warum auch - immer es unterläßt die erzeugte Session explizit zu schließen. Ist dies Absicht - oder interpretiere ich die Tabelle falsch? Ansonsten sollten Sessions aus Sicherheitsgründen ein Timeout haben.


----------



## Till (18. Nov. 2009)

> Ich bin momentan dabei eine Java-Lib auf AXIS basierend zu implementieren, die die SOAP Schnittstelle von ISPconfig3 ansteuert. Funktioniert eigentlich alles recht gut - mit Hilfe von Beispielen, den Sourcen und dem DB-Layout ist dies eine straight ahead Geschichte. Die fertige Lib wird dann, wie das ganze OXGUI Projekt , als Open Source zur Verfügung stehen.


Hört sich gut an!



> Als Feature für die Zukunft würde ich mir getAll() Methoden für die SOAP Schnittstellen wünschen. z.B. gibt mir alle MailDomains, MailUser, etc zurück. Solche Methoden sind notwendig wenn ich Konverter schreiben möchte - z.B lege für alle bestehende MailUser einer bestimmten MailDomain einen OX Account an. Für das erste werde ich für die Konverter direkt auf die DB gehen, um die Benutzer zu enumerieren.


Stimmt, das fehlt noch. Nehm ich mit in die riadmap auf.



> Weiters ist mir aufgefallen - dieTabelle remote_session beinhaltet die Sessions ID des Remote Users. Wie es scheint bleiben diese Sessions-Einträge erhalten, wenn der Remote-User - warum auch - immer es unterläßt die erzeugte Session explizit zu schließen. Ist dies Absicht - oder interpretiere ich die Tabelle falsch? Ansonsten sollten Sessions aus Sicherheitsgründen ein Timeout haben.


Also die sessions laufen ab, d.h. Du kannst sie einem Timeout von 10 Minuten Inaktivität nicht mehr verwenden selbst wenn sie noch in der Tabelle stehen, da bei jedem Funktionsaufruf getestet wird.  Es fehlt aber trotzdem der Code zum "aufräumen" der Einträge, hab ich kurz im SVN eingefügt.


----------



## pezi (23. Nov. 2009)

Hallo!

Die SOAP Schnittstelle bietet diverse getter Methoden.

z.B. "mail_user_get"

Nur können diese Methoden momentan nicht benutzt werden, da diese  nicht in der Rechtetabelle

remote_user->remote_functions 

```
mail_domain_get,mail_domain_add,mail_domain_update,mail_domain_delete;mail_user_add,mail_user_update,mail_user_delete;mail_alias_add,mail_alias_update,mail_alias_delete;mail_forward_add,mail_forward_update,mail_forward_delete;mail_catchall_add,mail_catchall_update,mail_catchall_delete;mail_transport_add,mail_transport_update,mail_transport_delete;mail_whitelist_add,mail_whitelist_update,mail_whitelist_delete;mail_blacklist_add,mail_blacklist_update,mail_blacklist_delete;mail_spamfilter_user_add,mail_spamfilter_user_update,mail_spamfilter_user_delete;mail_policy_add,mail_policy_update,mail_policy_delete;mail_fetchmail_add,mail_fetchmail_update,mail_fetchmail_delete;mail_filter_add,mail_filter_update,mail_filter_delete
```
der Remote users vermerkt sind.

Peter


----------



## Till (23. Nov. 2009)

Ok, danke. Hab ich im SVN behoben.


----------



## pezi (25. Nov. 2009)

Hallo!

Zum Thema Remote user/SOAP ist mir noch etwas aufgefallen. Will ich einen bestehenden Remote User  bezüglich seiner Rechte modfizieren, bin ich gezwungen das schon bestehende PWD neu einzugeben, da ansonsten die Fehlermeldung 'Password cannot be empty' kommt.

Gruß
Peter


----------



## Till (25. Nov. 2009)

Ok. hab ich geändert.


----------



## pezi (26. Nov. 2009)

Hallo Till

Ich weiß, ich werde schon langsam lästig .

Aber ich habe eine Verständnissfrage zum Update von Objekten via Soap.

z.B. mail_user_update

Wenn ich z.B. das Quota von einem Benutzer änderen möchte, dann bin ich angehalten den Benutzer über SOAP per ID einzulesen. Dann die gewünschten Parameter zu ändern, und dann wieder alle Daten an mail_user_update weiterzureichen. Wenn ich das nicht tue - Parameter durchreichen - dann sind diese weg oder auf default zurückgesetzt. Einzige Ausnahme ist das Passwort des Mail Benutzers - dieses muss nicht erneut mitgeschickt werden. Es dürften alle Update-Funktionen so arbeiten.

Ist dies im Sinne des Erfinders? Eigentlich hätte ich mir erwartet, dass ich bei Änderungen nur die ID + Änderungen durchreichen müsste. Oder ist es so, dass die Update-Funktion von der GUI abgeleitet wurde? Da sind immer alle Daten vorhanden, die Bildschirmmaske wird ja ursächlich mit allen Werten befüllt. Und somit bekommt die Update-Funktion immer alle Daten ohne sich groß kümmern zu müssen, welcher Parameter sich wirklich geändert hat.


----------



## Till (26. Nov. 2009)

Die Updatefunktion nutzt die gleichen Libraries wie die GUI, damit bei Anpassungen an der GUI die API nicht zusätzlich angepasst werden muss. Daher müssen auch immer wieder alle Parameter bei einem Update mitgeschickt werden. Ich denke aber man kann das auch so ändern, dass er selbst in der API die Daten einliest und dann nur die mitgeschickten Parameter updatet. Müsste man sich mal ansehen.


----------



## pezi (26. Nov. 2009)

Guten Morgen!

Ist eigentlich nicht unbedingt notwendig. Ich habe meinen Code etwas geändert - das Objekt das geändert werden liest über die ID das Objekt per SOAP ein - ich bekomme eh  eine HashMap zurück wo alles drinnen. Und Änderungen führe ich nun gegen diese HashMap durch. 

Was anderes ist mir aufgefallen. Es geht um die Tabelle spamfilter_users - wo die E-Mail Adresse des Benutzers gepeichert ist. 
Szenario: 
- Bestehende Spampolicy für den Benuzer gesetzt
- ich ändere die E-Mail-Adresse des Benutzers 
- neuer Eintrag in der Tabelle spamfilter_users für die neue E-Mail Adresse wird erzeugt. Alte Eintrag für die alter E-Mail Adresse bleibt aber bestehen!
- ich ändere die E-Mailadresse wieder auf die alte E-Mailadresse - nun habe ich zwei Einträge zu dieser E-Mail Adresse - siehe Bild

Gruß
Peter


----------



## Till (27. Nov. 2009)

Hast Du das über die API oder das Interface geändert? Die API ist low level, d.h. Du musst Dich um das umbennen von möglicherweise zugehörigen Einträgen selbst kümmern während das Interface das über entsprechende events der web Forms selbst macht.


----------



## pezi (27. Nov. 2009)

Ich glaube diese Einträge alle mit der Oberfläche erreicht zu haben. Ich habe es zwar nicht noch einmal geschafft einen doppelten Eintrag zu erzeugten. Dass aber eine Änderung der E-Mail Adresse über die GUI den alten Eintrag (alte Email-Adresse) in der Tabelle spamfilter_users beläßt habe ich verifiziert.

Peter


----------



## pezi (28. Nov. 2009)

Hallo Till!

Mein ISPconfig3 Plugin für meine OX GUI ist schon langsam am werden - MailDomains, MailAccounts, Alias erzeugen/modfizieren/löschen implizit durch die OX GUI funktioniert schon recht gut. 

Nun stehe ich aber vor folgendem Problem - ich will ein optionales Mail Forwarding für einen MailAccount implementieren. Deiner Info nach habe ich einen custom_mailfilter angelegt, den ich beim Anlegen des Benutzer mail_user_add mitschicke. Nur scheint es so, wenn kein mail_filter für den Benutzer besteht, dann wird dieser Eintrag ignoriert. Die Logik für dan Anlegen eines Benutzer schaut bei mir so aus.

1.) Benutzer wird mit optionaler Fowarding rule angelegt
2.) optional - abhängig von den globalen Einstellungen wird ein mail_filter für den gerade erzeugten Benutzer angelegt.

Ich könnte zwar erst den Benutzer anlegen, dann einen  mail_filter für den Benutzer . Danach könnte ich die Benutzer custom_mailfilter hinsichtlich des Mail Forwardings modifizieren. Erstens etwas umständlich - und der mail_filter ist bei mir optional.

Gruß und Dank
Peter


----------



## Till (29. Nov. 2009)

Muss ich mir im Quelltext mal genauer ansehen, an welchem Event das schreiveb des custom_mailfilter mit dran hängt.


----------



## pezi (30. Nov. 2009)

Hallo Till!

Dieses Problem betrifft auf die "mail_user_filter_add" Funktion - das alleinige Hinzufügen eines Filters triggert noch kein Update des "custom_mailfilter" des Benutzers. 

Folgende Korrekturen möcht ich noch einbringen
Die "mail_user_filter_xxx" Funktion sind falsch in der remote_user-Tabelle (remote_functions) drinnen -  "mail_filter_xxx" statt mail_user_filter_xxx . In den Beispielen
soap-filtr-add.php 
soap-filtr-delete.php 
soap-filtr-update.php nennt sich die Funktion:
mail_filtr_xxx

Bei den Beispielen 
soap-users_spamfilter-add.php 
wird 
mail_spamfilter_user_add
statt
mail_users_spamfilter_add
verwendet.
Detto für 
soap-users_spamfilter-delete.php 
soap-users_spamfilter-update.php

Was manche Bespiele betrifft, da waren auch Probleme mit den Parametern. Wenn es Dir recht ist dann gehe ich mal alle Bespiele durch, korrigiere diese gegenenfalls und schiche Dir dann die Änderungen.

Gruß
Peter


----------

