mscholz3
I'm new here

Zugriff auf AccessControlDb in einer Executable im isolated-Modus

Jump to solution

Hallo liebe Community,

wie führen gerade eine IT-Infrastruktur Wechsel durch. Der neue FS-Server läuft nun im isolated-Modus.

Bisher läuft die Umstellung der Module auf isolated ganz gut. Nur bei einer Sache haben wir gerade noch Problem.

Wir bekommen in unseren Executable-Klassen keinen Zugriff auf die AccessControlDb bzw. auf das Objekt selbst. Leider gibt es bisher unseres Wissens nach keinen "offiziellen" Weg, wie man in einer Executable-Klasse die AC-DB aufruft.

Bisher haben wir es per Reflektion gelöst:

import java.io.IOException;

import java.lang.reflect.Method;

import de.espirit.firstspirit.access.schedule.*;

import de.espirit.firstspirit.acl.db.AccessControlDb;

Method method = context.getClass().getDeclaredMethod("getAccessControlDb");

method.setAccessible(true);

AccessControlDb accessControlDb =  (AccessControlDb) method.invoke(context);

Wenn wir diesen Code in einem Task-Script aufrufen, dann funktioniert alles prima.

Rufen wir allerdings den gleichen Code in einer Executable-Klasse auf, bekommen wir folgenden Fehler:

Caused by: java.lang.ClassCastException: class de.espirit.firstspirit.acl.db.AccessControlDb cannot be cast to class de.espirit.firstspirit.acl.db.AccessControlDb (de.espirit.firstspirit.acl.db.AccessControlDb is in unnamed module of loader de.espirit.common.FactoryRegistry$LibrariesLoader @397fbdb; de.espirit.firstspirit.acl.db.AccessControlDb is in unnamed module of loader de.espirit.firstspirit.server.module.SafeFindUrlClassLoader @8a2f74b)

Damit er die Klasse überhaupt findet, liefern wir zu unserem Modul die crc7.jar (aus fs-security.fsm) mit. Ohne diese Jar bekommen wir die Meldung, dass er AccessControlD nicht findet/kennt.

Im Legacy-Modus hatten wir die jar immer nur als "provided" in unserem Code.

Folgendes haben wir erfolglos ausprobiert:

  1. Den Scope von crc7.jar in der module-isolated.xml auf global gestellt.
  2. Das AccessControlDb-Objekt in einem extra Script-Taks als Property hinzugefügt:

context.setProperty("accessControlDb", accessControlDb);

Das hatte funktioniert, jedoch beim Casten im Modul wieder das gleiche Problem:

final AccessControlDb accessControlDb = (AccessControlDb) context.getProperty("accessControlDb"); --> Gleicher Fehler

Habt ihr Ideen wie ich das Objekt bekomme? Was machen wir hier falsch? Müssen wir vielleicht eine andere Jar mitliefern?

Und außerdem ganz wichtig:

Gibt es vielleicht bereits einen "richtigen" Weg um auf die AccessControlDb zuzugreifen?

Die einzige Aussage dazu habe ich in einem Thread gefunden, wo sich zuletzt 2011 ein Entwicklern hierzu geäußert hat:

https://community.e-spirit.com/message/5010#5010

Zu dem vorgeschlagenen „LegacyAccessControlDbProvider“ finde ich in der Doku nichts.

Ich weiß auch nicht aus welcher FS-Bibliothek dieser Provider kommt.

Liebe Grüße

Marcel

1 Solution

Accepted Solutions
StefanSchulz
I'm new here

Hallo Marcel,

Danke für die ausführliche Problembeschreibung.

Die Antwort ist eigentlich ganz einfach: Der Zugriff auf die AccessControlDB wurde und wird von FirstSpirit nicht unterstützt. Hier gibt es keine API zu und es ist auch keine API für den Zugriff auf die DB geplant. Im "Legacy"-Modus war der Zugriff über Druidenwissen möglich (LegacyAccessControlDbProvider ist einer dieser Wege). Dieser wird im Isolated-Modus jedoch nicht mehr funktionieren.

Dieses Problem haben bereits einige Partner, daher arbeiten wir an einer adäquaten Lösung. Eventuell kannst du mir ja beschreiben, was genau ihr fachlich mit den Informationen aus der DB macht, also welche Informationen ihr benötigt und was ihr erreichen wollt. Eventuell passt die geplante Lösung dann auch für euch.

Beste Grüße

Stefan

View solution in original post

0 Kudos
11 Replies
StefanSchulz
I'm new here

Hallo Marcel,

Danke für die ausführliche Problembeschreibung.

Die Antwort ist eigentlich ganz einfach: Der Zugriff auf die AccessControlDB wurde und wird von FirstSpirit nicht unterstützt. Hier gibt es keine API zu und es ist auch keine API für den Zugriff auf die DB geplant. Im "Legacy"-Modus war der Zugriff über Druidenwissen möglich (LegacyAccessControlDbProvider ist einer dieser Wege). Dieser wird im Isolated-Modus jedoch nicht mehr funktionieren.

Dieses Problem haben bereits einige Partner, daher arbeiten wir an einer adäquaten Lösung. Eventuell kannst du mir ja beschreiben, was genau ihr fachlich mit den Informationen aus der DB macht, also welche Informationen ihr benötigt und was ihr erreichen wollt. Eventuell passt die geplante Lösung dann auch für euch.

Beste Grüße

Stefan

0 Kudos

Hallo Stefan,

danke für deine schnelle Antwort.

Leider auch eine sehr schlechte Antwort für uns, da wir nun einiges umändern müssen.

Wir holen uns beispielsweise aus der DB mit einem Zeitstempel (die seitdem letzten laufenden Task) alle veränderten Medien.

Aus der Antwort holen wir uns dann die Metadaten, Berechtigungen etc.

Was wäre für dieses Beispiel denn die beste bzw. eine gute Alternative für die ACDB? Übern QueryAgent die Daten holen?

Wir sollten dann wahrscheinlich zukünftig komplett die crc7.jar nicht mehr nutzen, oder?

Liebe Grüße Marcel

0 Kudos

Hi Marcel,

wie geschrieben, im Isolation-Modus gibt es keinen Zugriff mehr auf die AccessControl-DB (den es ja auch vorher nicht offiziell gab Smiley Wink ).

An der Alternative arbeiten wir gerade mit Veröffentlichungsziel Herbst. Und, wenn ich deinen Anwendungsfall richtig verstanden habe, dürfte dieser Weg auch für euch passen.

Einen aktuell verfügbaren "Umweg" kenne ich leider nicht.

Beste Grüße

Stefan

0 Kudos

Hallo Stefan,

" dürfte dieser Weg auch für euch passen."

Meinst du damit die im Herbst kommenden Alternative von euch oder der von mir vorgeschlagenen QueryAgent?

Liebe Grüße

Marcel

0 Kudos

Hi Marcel,

ich meinte den API-Weg im Herbst.

Über den QueryAgent kommst du an Generierungsinformationen nicht ran.

Das generelle Problem, das meines Wissens mit dem "illegalen" AccessControlDB-Weg gelöst wird, ist, herauszufinden, was generiert wurde und einen Zusammenhang zwischen den Dateien und FirstSpirit-Elementen herstellen zu können. Dafür gibt es aktuell keinen Weg den ich kenne. Deshalb wird ja einer geschaffen.

Beste Grüße

Stefan

0 Kudos

Hallo Stefan,

alles klar. Als Zwischenlösung bis dahin könnten wir ja unsere Funktionen aus den Executables in den Script-Task auslagern.

Wird zwar bisher groß der Task, aber da sollte der Zugriff auf die DB ja problemlos funktionieren, oder?

Liebe Grüße

Marcel

0 Kudos

Hi Marcel,

das könnte funktionieren, weil bei Skripten kein Isolationstest durchgeführt wird. Garantiert ist das logischerweise nicht, weil keine API.

Beste Grüße

Stefan

0 Kudos
mscholz3
I'm new here

Hallo Stefan,

wir führen demnächst ein FS-Update durch und gehen gerade dafür die Relasenotes durch.

Dabei habe ich folgendes Kapitel gesehen: "Auf generierte Daten per Auftragsskript zugreifen 2020-09"

Höchstwahrscheinlich meintest du dies mit dem neuen "API-Weg im Herbst", oder?

Liebe Grüße

Marcel

0 Kudos

Hi Marcel,

ja, das meinte ich. Hätte mir diesen Thread merken sollen, um das zu kommunizieren. Sorry.

Beste Grüße

Stefan