AndreasOesterle
I'm new here

WebClient: Prüfen ob Autor auf Zielseite berechtigt ist

Hallo zusammen,

Ich habe eine nicht geschützte Startseite für Redakteure gebaut. Dort möchte ich eine Linkliste bauen in der jeder Redakteur im WebClient nur genau die Links auf Seiten sieht auf die er auch WCMS seitig berechtigt ist. In das Livesystem wird meine Startseite nicht nicht publiziert.

Ich habe versucht:

$CMS_FOR(value,fr_cs_marken_value)$

    $CMS_IF(ref(pageref:"processPageName").target.getPermission().canSee())$

        <h3><a href="$CMS_REF(pageref:"processPageName")$">$CMS_VALUE(value.get("name"))$</a></h3>

    $CMS_END_IF$

$CMS_END_FOR$

Ich habe versucht über die PageRef auf den Permission Service zuzugreifen, jedoch bekommt jeder Autor bei canSee() immer true zurückgeliefert, auch wenn der Autor gar nicht auf die Zielsseite berechtigt ist.

Zugreifen auf alle im Editor berechtigten Gruppen kann ich über:

$CMS_FOR(principal, ref(pageref:processPageName).target.getInheritedPrincipalPermissions())$

    principal: $CMS_VALUE(principal)$

    canSee perm: $CMS_VALUE(ref(pageref:processPageName).target.getPermission(principal).canSee())$

$CMS_END_FOR$

Hier wird korrekt ausgegeben welcher Principal die Seite sehen darf. Leider kann ich aber nicht den aktuellen User über den Userservice laden.

Wenn ich versuchen den aktuellen User zu holen bekomme ich immer SYSTEM zurückgegeben über:

#global.project.getUserService().getUser().getLoginName()

Hat einer eine Idee wie man den aktuell im WebClient eingeloggten Benutzer als Objekt zurückbekommt oder direkt die canSee Berechtigung auswerten kann?

Labels (1)
7 Replies
MichaelaReydt
Community Manager
Community Manager

Re: WebClient: Prüfen ob Autor auf Zielseite berechtigt ist

Hallo Andreas,

auf einfachem Weg ist es nicht möglich, den aktuellen Benutzer zu ermitteln. Da die Preview auf dem Server läuft, wirst du immer den Benutzer "SYSTEM" erhalten. Du benötigst daher ein Skript, das im WebEdit-Kontext läuft.

Skript getUser:

//!Beanshell

import de.espirit.firstspirit.agency.UserAgent;

UserAgent userAgent = context.requireSpecialist(UserAgent.TYPE);

return userAgent.getUser().getId();

Dieses Skript musst du in deiner Seitenvorlage über folgenden Code aufrufen:

<script type="text/javascript">

        var sitemap = jQuery.parseJSON('{ $CMS_VALUE(fr_jsonnav.toString.quoteJS())$ }');

        window.parent.WE_API.Common.execute(

            "script:get_user",                     

            {},             

            function(userId) {          

                $("#module-list").append(renderfolder(sitemap, userId));

             });

            function renderfolder(folder, userId) {

                  var result = "";

                  for (subfolder in folder) {

                  rights = folder[subfolder].rights

                  if ($.inArray(userId, rights) >= 0) {

                    url = folder[subfolder].url;

                    result = result + "<li><a href=\"" + url + "\">" + subfolder + "</a>";

                      children = folder[subfolder].children;

                      if (children != null) {

                          result = result + "<ul>";

                          result = result + renderfolder(children,userId);

                          result = result + "</ul>";

                      }

                      result = result + "</li>";

                }

              }   

            return result;

          }

    </script>

Damit müsstest du den gewünschten User erhalten.

Mir ist noch aufgefallen, dass du - wie du schreibst - auf das "CAN_SEE"-Recht prüfst. Dieses bestimmt nur, ob der User die Struktur sehen kann. Einem User, der sehen (CAN_SEE), aber nicht lesen (CAN_READ) darf, würde in deinem Fall eine weiße Seite angezeigt werden.

Meiner Meinung nach wäre es also besser, auf das Leserecht zu prüfen, welches auch das Sichtbarkeitsrecht impliziert.

Viele Grüße

Michaela

AndreasOesterle
I'm new here

Re: WebClient: Prüfen ob Autor auf Zielseite berechtigt ist

Hallo Michaela,

danke für deine Antwort!

Gelernt habe ich mit deiner Antwort, dass wohl die CMS Tags einmal mit dem "System" User ausgeführt werden und das Kompilat dann im WebEdit für jeden Benutzer verwendet wird. Von daher kann man nicht mit CMS Tags Berechtigungen im WebEdit abfragen.

Mit JavaScript das Problem zu lösen finde ich nicht wirklich gut, da es eine Berechtigungsabfrage ist und diese der Server prüfen sollte und nicht der Client. Auch hilft alleine die UserId im JavaScript ja nicht viel, da ich danach immer noch nicht weiss ob der Benutzer Berechtigung auf die Seite hat. Die einzige Varainte die ich hierbei sehe ist mit AJAX jede einzelne Seite abzufragen und zu prüfen ob eine 403 Meldung zurückkommt. Das ist aber ziemlich unschön.

Ich denke mit JSP müsste es möglich sein zu abzufragen ob ein Benutzer Zugriff auf eine Seite hat oder nicht.

In diesem Blog wird diese Lösung auch einmal kurz erwhähnt, aber die Frage nicht komplett beantwortet: https://community.e-spirit.com/message/16443#16443

Für Berechtigungsabfragen habt ihr doch sicher eine JSP taglib die ich hier verwenden kann, oder? Könnt ihr mir hierzu Informationen senden?


VG
Andreas

0 Kudos
MichaelaReydt
Community Manager
Community Manager

Re: WebClient: Prüfen ob Autor auf Zielseite berechtigt ist

Hallo Andreas,

ich bin ein wenig verwirrt, da ich mir nicht sicher bin, ob wir aneinander vorbei schreiben.

Möchtest du die Abfrage auf die Berechtigungen des Users in der Preview oder im generierten Stand ausführen?

Die Vorschau wird im WebClient üblicherweise gecacht. Sie wird daher standardmäßig mit dem System-User ausgeführt und ist somit initial nicht personalisiert.

Wird diese jedoch benötigt, ist der Umweg über das von mir bereits gepostete Skript notwendig. Mit diesem lässt sich im WebClient der aktuelle User (und somit auch dessen Rechte) ermitteln.

Viele Grüße

Michaela

0 Kudos
AndreasOesterle
I'm new here

Re: WebClient: Prüfen ob Autor auf Zielseite berechtigt ist

Hallo Michaela,

ich möchte die Rechte eines Autors im WebClient abfragen ob er auf eine bestimmte Seite über seine Gruppenzuordnung berechtigt ist.

Wenn ich mir dein Script so anschaue, dann werden dort alle Navigationsknoten ausgegeben auf denen der Benutzer direkt berechtigt ist und nicht über Gruppen. Von daher denke ich das es für meinen Fall nicht gehen würde.

Ist es nicht möglich die Abfrage auf dem Server laufen zu lassen?

Wenn ich als Autor auf eine Seite im WebClient navigiere auf die ich keine Berechtigung habe, dann kommt auch die Meldung "Zugriff verweigert". Von daher muss der Server den User Kontext und die Berechtigungssituation prüfen.

Um die Abfrage auf dem Client laufen zu lassen, müsste man alle UserIds die den Gruppen zugeordnet sind zusätzlich als JSON rausrendern, was bei grossen User Store mit vielen Gruppen eine ganze Menge sein kann.

VG
Andreas

0 Kudos
MichaelaReydt
Community Manager
Community Manager

Re: WebClient: Prüfen ob Autor auf Zielseite berechtigt ist

Hallo Andreas,

das von mir bereits gepostete Skript ist natürlich nur ein Beispiel, dass ggf. an die individuelle Projektumgebung angepasst wird.

In unserem Fall rendert das Skript ein JSON-Element, das bei uns über die folgende Navigationsfunktion erzeugt wird:

<CMS_FUNCTION name="Navigation" resultname="fr_jsonnav">

<CMS_PARAM name="expansionVisibility" value="all" />

<CMS_ARRAY_PARAM name="delimiter">

<CMS_ARRAY_ELEMENT index="0..5">

<![CDATA[, ]]>

</CMS_ARRAY_ELEMENT>

</CMS_ARRAY_PARAM>

<CMS_ARRAY_PARAM name="beginHTML">

<CMS_ARRAY_ELEMENT index="0..5">

<![CDATA["$CMS_VALUE(#nav.label)$": { 

   

    $CMS_SET(set_PrinzipalList,[])$

   

    $CMS_FOR(for_prinzipal,#nav.ref.inheritedPrincipalPermissions)$

        $CMS_IF(for_prinzipal.getType() == class("de.espirit.firstspirit.access.Principal").GROUP)$

            $CMS_SET(void,for_prinzipal.getUsers().map(x->set_PrinzipalList.add(x)))$

        $CMS_ELSE$

            $CMS_SET(void,set_PrinzipalList.add.add(for_prinzipal))$

        $CMS_END_IF$

    $CMS_END_FOR$

    $CMS_SET(set_filter,x->#nav.ref.getPermission(x).canRead())$

    $CMS_SET(set_allowedUserIdList,set_PrinzipalList.filter(set_filter).map(x->x.id).distinct(x->x))$           

    "rights": [$CMS_VALUE(set_allowedUserIdList.toString(","))$],$--

--$"url": "$CMS_REF(#nav.ref)$"$--

--$]]></CMS_ARRAY_ELEMENT>

</CMS_ARRAY_PARAM>

<CMS_ARRAY_PARAM name="innerBeginHTML">

    <CMS_ARRAY_ELEMENT index="0..5"><![CDATA[, "children": {]]></CMS_ARRAY_ELEMENT>

</CMS_ARRAY_PARAM>

<CMS_ARRAY_PARAM name="innerEndHTML">

    <CMS_ARRAY_ELEMENT index="0..5"><![CDATA[}]]></CMS_ARRAY_ELEMENT>

</CMS_ARRAY_PARAM>

<CMS_ARRAY_PARAM name="endHTML">

    <CMS_ARRAY_ELEMENT index="0..5"><![CDATA[}]]></CMS_ARRAY_ELEMENT>

</CMS_ARRAY_PARAM>

</CMS_FUNCTION>

In diesem Fall werden alle für die entsprechende Seite berechtigten User (= User mit dem Recht CAN_READ) ermittelt - unabhängig davon, ob sie in einer Gruppe sind oder nicht. Dabei werden sowohl direkt gesetzte als auch geerbte Rechte berücksichtigt.

Viele Grüße

Michaela

AndreasOesterle
I'm new here

Re: WebClient: Prüfen ob Autor auf Zielseite berechtigt ist

Hallo Michaela,

danke für dein Codesnippet.

Ich habe dieses Snippet jetzt einmal bei mir eingebaut und die Lösung funktioniert für Benutzer die in einer internen Gruppe Mitglied sind.

Für externe Gruppen gibt die Methode getUser des in deinem Snippet verwendeten Interface Group eine leere Liste zurück. Meinst du das ist ein Fehler und ich soll dazu ein Helpdesk Ticket aufmachen oder kann FirstSpirit einfach keine externen Gruppen nach Usern durchsuchen?

Damit die Lösung auch funktioniert, müsste alle Benutzer der LDAPs schon in FirstSpirit eingelesen sein, was nach meinem Wissen aber nicht passiert. Die Benutzer werden mit Gruppenzugehörigkeiten erst in FS angelegt, wenn sich ein Benutzer einmal angemeldet hat.

Auf meine obenstehenden Fragen bist du noch gar nicht eingegangen. Kannst du dazu auch noch etwas sagen?


VG
Andreas

0 Kudos
AndreasOesterle
I'm new here

Re: WebClient: Prüfen ob Autor auf Zielseite berechtigt ist

Ich habe mir jetzt selber beholfen, in dem ich per ajax Call im WebClient prüfe ob ein 403 HTTP code zurückkommt oder ein HTTP Success code.

Eine schöne Lösung ist das aber nicht und funktioniert wohl auch nur in meinem Einzelfall.

Für die Navigationslösung mit Javascript zu denen die Codesnippets gepostet sind, gibt es wohl keine Lösung für externe Gruppen.

0 Kudos