User Rollen lokal aus dem richtigen xxxnames.nsf abfragen?

[LisaS]

Hallo,
ich habe ein Problem mit den User Rollen auf eine lokalen XPage-Replik.
Und zwar benutze ich

Code

context.getUser().getRoles().contains('[Admin]');

um zu prüfen ob der User in der Admin-Gruppe ist.
Das klappt auf dem Server auch wunderbar, nur lokal nicht.
Das liegt ja nun daran, dass auf das lokale Benutzeradressbuch names.nsf zugegriffen wird in der die Rollen gar nicht definiert sind.
Jeder User hat in seiner Lokalen Umgebung das Server names.nsf als lokale replik unter einen anderen Namen (servernames.nsf) vorliegen.

Jetzt die Frage: Wie bringe ich der lokalen XPage-Applikation bei, in das lokale servernames.nsf zu schauen anstatt in das lokale names.nsf?
Ich stehe da gerade echt auf dem Schlauch..

Grüße
Lisa

[koehlerbv]

Hast Du für diese DB konsistente ACL eingestellt?

Bernhard

[LisaS]

Ja

[LisaS]

Lustig:
Wenn ich in Client Preferences, Mail -> Sending and Receiving servernames.nsf, names.nsf anstatt names.nsf, servernames.nsf eingebe funktioniert es.
Die Reihenfolge ist entscheidend?! Security mäßig nicht akzeptabel.

Grüße
Lisa

[LisaS]

Gibt es denn eine Möglichkeit/Einstellung die lokale servernames.nsf fix für die Rollen-/Rechteabfrage zu nutzen, ohne das der User darauf Einfluss nehmen kann?

[Peter Klett]

Das sollte eigentlich bei Verwendung von konsistenter ACL korrekt funktionieren (wie Bernhard schon geschrieben hat), wobei dazu m.W. keine lokale Replik des Serveradressbuches notwendig ist. Ein Verdrehen der Einträge der Adressbücher in den Einstellungen hat mit Sicherheit negative Auswirkungen beim Client (zumindest früher musste zwingend erst das persönliche Adressbuch eingetragen sein), das würde ich lassen.

Bei "normaler" Programmierung ist das so, ob das ein Bug bei den XPages ist oder etwas anderes faul ist, kann ich nicht beurteilen.

[fritandr]

Ein Verdrehen der Einträge der Adressbücher in den Einstellungen hat mit Sicherheit negative Auswirkungen beim Client (zumindest früher musste zwingend erst das persönliche Adressbuch eingetragen sein), das würde ich lassen.

Da gebe ich Peter völlig recht. Habe das auch schon erlebt, dass der Client dann schon beim Neustart seltsamste Fehlermeldungen (die names.nsf ist schreibgeschützt, ....) ausgespuckt hat.

Viele Grüße
Andreas

[LisaS]

Richtig, in allen anderen Applikationen die nicht XPages sind funktioniert es auch, bloß die XPages weigern sich.
Und du hast auch recht mit dem pers. Adressb. an erster Stelle, da hatten wir auch Probleme, deswegen haben wir auch diese Reihenfolge.
Nur das ist natürlich bitter für die Programmierung von XPage-DBs mit lokalen Repliken.  

[Peter Klett]

Da hat wohl keiner dran gedacht, weil die alle nur noch an Browser denken und lokale Repliken beim Browser eher selten sind ...

[Jens Winkelmann]

Ich habe wenigstens gehofft, dass der folgende Code funktioniert.

Code

<xp:text escape="true" id="computedField3">
       <xp:this.value><![CDATA[#{javascript:var vec:java.util.Vector = session.evaluate("@UserRoles");
        return vec.toString();
}]]></xp:this.value>
</xp:text>

Aber wenn man lokal die konsistente ACL aktiviert, kracht es bei mir.

[Sven Hasselbach]

Hallo,

erst war ich etwas schockiert, als ich den Beitrag gelesen hatte, denn wenn die ACL neuerdings derartig einfach ausgetrickst werden kann, wären sämtliche Sicherheitskonzepte von Notes ad absurdum geführt.

Ich habe versucht, daß Problem nachzuvollziehen, und habe beruhigt feststellen können, daß die Gruppenausflösung in lokalen Repliken auch weiterhin so funktioniert, wie üblich. Auch bei XPages.

Siehe dazu auch: http://atnotes.de/index.php/topic,44559.msg286526.html#msg286526

Viele Grüße
Sven

[Jens Winkelmann]

So wie ich es verstanden habe, ist das hier diskutierte Problem folgendes:

Wie kann ich in einer XPage feststellen, ob der aktuelle Benutzer Inhaber einer bestimmten Rolle ist?
Dieses benötigt man beispielsweise in einer Visible Formel.

Läuft die XPage auf dem Server ist dieses kein Problem. Nur lokale Repliken machen Probleme.

Das Sicherheitskonzept als solches funktioniert - nur die Ermittlung macht Probleme.

[m3]

Code

context.getUser().getRoles().contains('[RoleName]');

oder

Code

var v:Array = database.queryAccessRoles(session.getEffectiveUserName());
@IsMember("[role]", v)

[Pyewacket]

Ich denke das Kernproblem ist die auf dem Client nicht vorhandene Directory Assistance Funktionalität
für die Authorisierung über Gruppen in einem alternativen Adressbuch.

Gruss
 Peter