Eigenes Script im Admin-Backend platzieren

Deutsches Forum
1

Hallo,

ich würde gerne ein bereits bestehendes PHP-Script im Backend platzieren. Hintergrund ist der, dass sich der Nutzer bis jetzt für dieses Script immer über ein extra System einloggen muss. Ich würde es gerne auf einen Login bei OXID reduzieren. Auf die OXID-API muss das Script nicht zugreifen. Wie gehe ich da jetzt vor?

2

Hallo Albert,

wenn ich das richtig verstehe, geht es um den Abgleich der Benutzerverwaltung = Schnittstelle. Du könntest überlegen, die Benutzerverwaltung (login-Routine) für das “3rd party” Script auszuschalten. Dann wäre Dein Script von außen erreichbar. Also muss eine richtige Schnittstelle ran. Oder ein SSO-Service. Und dann tritt es außerhalb des trivialen Bereiches.

Gruß

3

Könnte ich das ganze nicht als Modul implementieren?

Ich habe mir die Seiten zur Modulerstellung bei OXID durchgelesen und würde es folgendermaßen probieren:

  • Eintrag in die modules/$module/menu.xml (z.B. <SUBMENU id=“cus_script” cl=“cus_script” /> )
  • Datei cus_script.php in modules/$module erstellen. Dort eine neue Klasse erstellen und das 3rd-Party Script einsetzen.
  • cus_script.tpl in out/admin/tpl erstellen

Wäre der Gedankengang soweit richtig?

4

Wäre der Gedankengang soweit richtig?

Ja klar, Du kannst das externe Script sicher problemlos als Link in den Admin integrieren. Dort anmelden musst Du Dich sicher weiterhin.

Gruß

5

Kann ich den Login aus dem Script dann nicht entfernen? Die Authentifizierung ist doch dann bereits von OXID übernommen worden.

6

[QUOTE=Albert43;14689]Kann ich den Login aus dem Script dann nicht entfernen? Die Authentifizierung ist doch dann bereits von OXID übernommen worden.[/QUOTE]

Ich kann mir nicht vorstellen, dass das so einfach geht: Wenn, dann ist das Script ja immer von außen erreichbar…

7

Das kann ich nicht ganz nachvollziehen, die anderen Funktionen im Backend lassen sich doch auch erst nach einem Login aufrufen. Wie werden die denn geschützt?

8

[QUOTE=Albert43;14691]Das kann ich nicht ganz nachvollziehen, die anderen Funktionen im Backend lassen sich doch auch erst nach einem Login aufrufen. Wie werden die denn geschützt?[/QUOTE]
Probier doch einfach die Einbindung des Scripts aus. Wir werden ja sehen, was passiert :wink:

9

[QUOTE=Marco Steinhäuser;14692]Probier doch einfach die Einbindung des Scripts aus. Wir werden ja sehen, was passiert ;)[/QUOTE]

Werde ich probieren. Ich wüsste allerdings doch gerne, wie OXID die Scripte im Backend schützt.

Ich habe jetzt eine cus_script.php erstellt. Jetzt ist die Frage, wie muss ich die Klasse definieren? Hatte es so probiert:

class cus_script
{

public function helloworld() {
     echo "hello world";

}

}

Das scheint so nicht zu klappen, da nicht weiß wie ich die Klasse jetzt bei OXID registriere. Muss ich Klassen bei Modulen daher immer nach dem folgenden Muster definieren?


class cus_script extends cus_script_parent
{

public function helloworld() {
        echo "helloworld";
}

}

Dann wäre die nächste Frage mit welchem Mutterklasse ich das Modul bei OXID registrieren soll. Ich hatte es mit oxadmindetails => adminmenu/cus_script probiert. Das liefert allerdings mit folgender cus_script.tpl


[{include file="headitem.tpl" title="ORDER_PACKAGE_TITLE"|oxmultilangassign box=" "}]
[{$cus_script -> helloworld()}]
</body>
</html>

den Fehler

“Warning: Smarty error: unable to read resource: “” in /var/www/vhost/testing/shop/core/smarty/Smarty.class.php on line 1092”

10

Hallo!!!

Hast Du hier schon eine Lösung gefunden?

Dies ist nämlich auch mein Problem im Moment. Ich denke, dass noch eine Klasse im Ordner “view” angelegt werden muss, weiß aber noch nicht genau wie.

Grüße & Danke

tvtotal