Methode für Backend / Frontend / User abprüfen

[darki777]

Hi,
habe jetzt eben die halbe API (library) von TL durchgerattert, allerdings finde ich keine Methode in der ich überprüfen kann ob man im Backend oder Frontend eingeloggt ist oder nicht, ggf. noch ob er als Admin eingeloggt ist oder nicht. Das einzige was ich bisher fand, war nur eine Methode bei der ich abprüfen kann ob der User von der Gruppe XYZ stammt oder nicht. Weis jemand wie die Methode(n) lauten könnte(n)? Notfalls Workaround? Danke.

Gruß,
darki

[Antipitch]

Hi darki,
die Klasse frontend kennt die Methode getLoginStatus (boolean), prüft ob ein BE oder FE User angemeldet ist.

Zumindest für's BE (FE weiß ich nicht) steht User->isAdmin zur Verfügung (guck z.B. mal im Newsmodul > dca > tl_news, Zeile 391). API hab ich hierüber allerdings nichts gefunden.

Hoffe das hilft schon mal bißchen...


cheers
Antipitch

[Dani]

Dies könnte dir nützlich sein:

        if (TL_MODE == 'FE')
        {
            $this->import('FrontendUser', 'Member');
            if (FE_USER_LOGGED_IN)
            {
               $memberId = $this->Member->id;
            }
            else
            {
               $memberId = 0;
            }
        }

[andreas.schempp]

Dani's aussage stimmt:

if (FE_USER_LOGGED_IN)
{
    echo 'frontend angemeldet'
}

if (BE_USER_LOGGED_IN)
{
    echo 'backend angemeldet'
} 

Beachten dass die Konstanten sind und keine Variablen, $ ist also nicht nötig. Ausserdem können beide Optionen aktiv sein, wenn der Backend-Benutzer die Frontend-Vorschau aufruft, einen Benutzer auswählt und "versteckte Elemente anzeigen" wählt.

[billy]

Habe versucht die Konstante BE_USER_LOGGED_IN in meinem Frontend-Modul (TL-Version 2.8.2) zu verwenden, hat aber leider nicht funktioniert.

if(BE_USER_LOGGED_IN) echo 'Backend-User ist eingeloggt!'; 

Muss hier vorher noch etwas importiert werden?

[BugBuster]

Meines Wissens geht das nicht, du kannst nur im Frontend nach Mitgliedern prüfen und im Backend nach Benutzern, zumindest wenn du über die Konstanten gehst,
die sind ja gesetzt wenn der aktuelle Nutzer der die Seite aufruft eingeloggt ist.

Es ist natürlich möglich, mein Modul backend_user_online ist zwar ein Backend Modul, zeigt aber von allen Mitgliedern und Benutzern an ob diese online sind. (mit leichter Unschärfe)

[andreas.schempp]

Habe versucht die Konstante BE_USER_LOGGED_IN in meinem Frontend-Modul (TL-Version 2.8.2) zu verwenden, hat aber leider nicht funktioniert.

if(BE_USER_LOGGED_IN) echo 'Backend-User ist eingeloggt!'; 

Muss hier vorher noch etwas importiert werden?

Ausserdem können beide Optionen aktiv sein, wenn der Backend-Benutzer die Frontend-Vorschau aufruft, einen Benutzer auswählt und "versteckte Elemente anzeigen" wählt.

Rufst du das Frontend korrekt auf?

[Andreas]

Hallo, ich muss mich hier nochmal dran hängen.

Auch ich muss im FE checken, ob im BE ein Benutzer (am besten Admin, aber erstmal egal) eingeloggt ist, und soll dann im Frontend zusätzlich was ausgeben wenn true.

Ich bin im Template mod_article.xhtml Contao 2.11.10.

Obwohl im BE als Admin eingeloggt, haben die Konstanten folgende Werte:

BE_USER_AUTH = 'BE_USER_AUTH'
BE_USER_LOGGED_IN = bool(false)

Weiß jemand, wie ich im Template mod_article.xhtml prüfen kann, ob ich im BE eingeloggt bin?

[heyho]

Hallo,

gibt es bereits eine Lösung dafür?

Wäre folgendes denkbar?
Mit dem postLogin Hook und dem postLogout Hook speicher man im tl_user den login_status.
Man weiß jetzt wann sich ein User einloggt, ausloggt oder ausgeloggt wird.

In meinem Fall muss ich wissen ob ein Backend User die Frontend Vorschau verwendet.
Beim LoginHook wird also die PHPSESSIONID mitgespeichert.
Bei der Frontend Vorschau wird dann überprüft ob der User mit selber PHPSESSIONID eingeloggt ist und Admin ist...

lg

[Andreas]

Das einzige, was ich rausgefunden hatte ist, dass der Marker BE_USER_LOGGED_IN nur dann auf true gesetzt wird, wenn man über den Frontend-Vorschau-Link aufs Frontend geht und dann 'Unveröffentlichte Elemente anzeigen' aktiviert. Finde ich ein bisschen doof jetzt, müsste man vielleicht mal ein Ticket zu erstellen.

[Zero]

Ich kann nur auf diese Zeile verwiesen:
https://github.com/contao/core/blob/...ogle.html5#L12

Allerdings nur als Admin User getestet. Was als anderer BE User passiert keine Ahnung .
Wichtig ist vermutlich die Cookie Abfrage, welche ganz hinten drin steht.

[Andreas]

Wie gesagt, BE_USER_LOGGED_IN ist false, wenn du im BE eingeloggt bist. Nur über die FE-Vorschau mit "unveröffentlichte anzeigen" aktiviert ist es true.

[Zero]

Ich meine diesen Teil speziell:

sha1(session_id() . (!$GLOBALS['TL_CONFIG']['disableIpCheck'] ? Environment::get('ip') : '') . 'BE_USER_AUTH') != Input::cookie('BE_USER_AUTH') 

Der geht auch nicht?

[Andreas]

Ist ja ne UND Verknüpfung und die Konstante BE_USER_AUTH ist string 'BE_USER_AUTH'. Das heißt, in deinem Beispiel müsste Analytics auch ausgeführt werden, wenn du im BE eingeloggt bist, halt nur nicht, wenn du über die FE-Vorschau mit unv. anzeigen gehst.

[Zero]

Ist ja ne UND Verknüpfung und die Konstante BE_USER_AUTH ist string 'BE_USER_AUTH'. Das heißt, in deinem Beispiel müsste Analytics auch ausgeführt werden, wenn du im BE eingeloggt bist, halt nur nicht, wenn du über die FE-Vorschau mit unv. anzeigen gehst.

Hi Andreas,

kann ich nicht bestätigen. Dieser Code funktioniert. Ich bin im Backend angemeldet und rufe die Seite ohne Preview auf. Das script wird nicht ausgegeben.

Zuersteinmal wird ein sha1 hash erzeugt indem geprüft wird ob das array $GLOBALS['TL_CONFIG'] existiert mit der aktuellsten session ID und dem String BE_USER_AUTH

sha1(session_id() . (!$GLOBALS['TL_CONFIG'] ? Environment::get('ip') : '') . 'BE_USER_AUTH') 

Dann wird abgefragt ob das ganze nicht gleich dem Im Cookie gespeicherten Wert ist

 != Input::cookie('BE_USER_AUTH') 

Ich verstehe dein Problem nicht. Bei mir geht es ob mit Frontend Preview oder ohne. Ebenso wird hier keine Konstante abgefragt... 'BE_USER_AUTH' ist ein String. Teste es einfach mal. Es muss gehen

[Andreas]

Ja, ok, da hast du Recht, da habe ich mich von der Schreibweise irreführen lassen. BE_USER_AUTH gibt es nicht als Konstante.

Aber mich wunderte eben die Konstante BE_USER_LOGGED_IN, die besser BE_USER_SHOW_UNRELEASED heißen sollte.

Denn für die Überprüfung im FE reicht tatsächlich das hier

if(sha1(session_id().(!$GLOBALS['TL_CONFIG']['disableIpCheck'] ? Environment::get('ip') : '').'BE_USER_AUTH') != Input::cookie('BE_USER_AUTH')) {
  // code here
} 

Und in der Abfrage verstehe ich das "&& !BE_USER_LOGGED_IN" nicht. Wenn ich das entferne, habe ich das gleiche Ergebnis. Oder hat das was mit "$GLOBALS['TL_CONFIG']['disableIpCheck']" zu tun?

Auf jeden Fall finde ich die Konstante unglücklich und irreführend gewählt.

[Andreas]

Hier noch die Version für Contao 2.11.10

$this->Import('Environment');
if(
  (sha1(session_id().(!$GLOBALS['TL_CONFIG']['disableIpCheck'] ? $this->Environment->ip : '').'BE_USER_AUTH') == $this->Input->cookie('BE_USER_AUTH')) {
  // Code here
} 

Achtung hier habe ich == benutzt, also Prüfung, ob BE User eingeloggt ist, im Post zuvor war es != - prüfen, ob er nicht eingeloggt ist.

edit:
Code, den ich für Contao 3.5 benutze

if(sha1(session_id().(!Config::get('disableIpCheck') ? Environment::get('ip') : '').'BE_USER_AUTH') == Input::cookie('BE_USER_AUTH'))
{
  $beUserLoggedIn = true;
} 

[Samson1964]

Für eine einfache Abfrage, ob ein BE-Benutzer eingeloggt ist, nutze ich in meinem Modul folgenden Code:

$objSession = $this->Database->prepare('SELECT * FROM tl_session WHERE sessionID=?')->execute(session_id());
if($objSession->name == 'BE_USER_AUTH')
{
  // Session-ID gehört einem eingeloggtem BE-Benutzer
} 

Ist im Frontend des gleichen Browsers ein Mitglied eingeloggt, gibt es einen weiteren Datensatz mit der gleichen Session-ID, der in der Spalte name = 'FE_USER_AUTH' enthält. Deshalb ist vielleicht die (Auswertung der) Abfrage nicht ganz sauber, denn 'FE_USER_AUTH' kann bereits im ersten zurückgegebenen Datensatz stehen. Besser also:

$objSession = $this->Database->prepare('SELECT * FROM tl_session WHERE name=? AND sessionID=?')->execute('BE_USER_AUTH', session_id()); 

[minstyle]

Die hier vorgestellten Lösungsanätze funktionieren bei mir in der aktuellen Contao-Version nicht.

Den Umweg über die "Frontend-Vorschau > Unveröffentlichte Elemente: anzeigen" finde ich nicht gut, da ich versteckte Inhalte dem Redakteur nicht anzeigen möchte.

Ich habe das Problem in Contao 3.4.5 derzeit so für mich gelöst:

<?php if ($GLOBALS['_COOKIE']['BE_USER_AUTH']): ?>
BE-User oder Admin ist eingeloggt
<?php endif; ?>

[Stranger]

Danke
Weiß auch jemand wie man bei Multidomain Installationen überprüft, ob jemand als Backend-User eingeloggt ist?
Da funktioniert $GLOBALS['_COOKIE']['BE_USER_AUTH'] nämlich nicht.

[Andreas]

@Stranger

Ich habe oben meinen Code für Conao 3.5 hinzugefügt. https://community.contao.org/de/show...l=1#post277111

Für Multidomains weiß ich auf Anhieb auch nicht, außer, dass du versuchen kannst dich mit einer der Multidomains im BE einzuloggen.

[Zero]

@Stranger schau mal hier: https://community.contao.org/de/show...reifend-nutzen

Generell ist ein Cookie an eine Domain gebunden.
Alternative wäre die Session als GET Parameter übergeben.

[kalterwind]

Bis Contao 4.4 habe ich über

 if(sha1(session_id().(!Config::get('disableIpCheck') ? Environment::get('ip') : '').'BE_USER_AUTH') == Input::cookie('BE_USER_AUTH')){ } 

abgefragt, ob der Benutzer im Backend eingeloggt ist.
Mit 4.8 funktioniert es nicht mehr.

Kann mir Jemand helfen?
Nutze es im Template mod_article.html5, um dem Contao Nutzer einen Link zum passenden Artikel bereit zu stellen für etwas einfacheres pflegen.

[andreas.schempp]

Contao 4.8 verwendet Symfony Security, nicht mehr die Zeilen aus Contao 3. Etwa so müsste es gehen:

 if (System::getContainer()->get('contao.security.token_checker')->hasBackendUser()) { } 

[heyho]

Is Backend-User:

$security = System::getContainer()->get('security.helper'); 
if ($security->isGranted('ROLE_ADMIN')){} 

Backend-User ist eingeloggt:

$objTokenChecker = \System::getContainer()->get('contao.security.token_checker');
if ($objTokenChecker->hasBackendUser()) {} 

Frontend-User ist eingeloggt:

$objTokenChecker = \System::getContainer()->get('contao.security.token_checker');
if ($objTokenChecker->hasFrontendUser()) {} 

Frontend-User gehört zur Gruppe:

$security = System::getContainer()->get('security.helper'); 
$security->isGranted('contao_member.groups', $idDerGruppe); 

[heyho]

Folgendes funktioniert zwar im Backend, beim System-Update oder beim Cache leeren (und WARMUP) im Manager verursacht es aber einen Error.

$security = System::getContainer()->get('security.helper'); 
if ($security->isGranted('ROLE_ADMIN')){
    echo "zB. Neu Button nur bei Admins anzeigen";
} 

Fehler beim Cache WARMUP (DEV und PROD)

CRITICAL  [console] Error thrown while running command "cache:warmup --env=dev". Message: "The token storage contains no authentication token. One possible reason may be that there is no firewall configured for this URL." ["exception" => Symfony\Component\Security\Core\Exception\AuthenticationCredentialsNotFoundException { …},"command" => "cache:warmup --env=dev","message" => "The token storage contains no authentication token. One possible reason may be that there is no firewall configured for this URL."]
In AuthorizationChecker.php line 74:
                                                                               
  The token storage contains no authentication token. One possible reason may  
   be that there is no firewall configured for this URL.                       
                                                                               
cache:warmup [--no-optional-warmers]

Also verwende ich weiterhin:

$objUser = BackendUser::getInstance();
if($objUser->isAdmin){} 

[Spooky]

Wo genau hast du diesen Code verwendet?

[heyho]

Im eigenen tl_article.php um z.B

$objUser = BackendUser::getInstance();
if(!$objUser->isAdmin){
    $GLOBALS['TL_DCA']['tl_article']['config']['closed'] = false;
} 

# Erzeugt den Fehler
$security = System::getContainer()->get('security.helper'); 
if (!$security->isGranted('ROLE_ADMIN')){
    $GLOBALS['TL_DCA']['tl_article']['config']['closed'] = false;
} 

Nicht im Callback sondern einfach im SpagettiCode..

[Spooky]

Das darfst du nicht machen. Nutze einen Callback mit Dependency Injection.

[Tim G]

Hi Leute,
eine Frage. Warum loggt Contao (4.13) direkt aus, wenn man ein Recht direkt abfragt.

Beispiel für die Rechte-Abfrage direkt auf ein Formular (id=1) (angewendet in einem loadDataContainer Hook Callback)

...

System::importStatic(BackendUser::class,'User');

$security = System::getContainer()->get('security.helper');
$hasAccess = $security->isGranted( ContaoCorePermissions::USER_CAN_ACCESS_FORM,1 ); // Contao loggt aus 

Contao loggt direkt aus. Ein weiterer Login ist nicht mehr möglich, ausser man kommentiert die isGranted Abfrage wieder aus. Auch die Kappselung in eine vorherige "Backend-Logged In" Abfrage ändert nichts.

[Spooky]

Poste den gesamten Code.

[Tim G]

Hi,

config.php

$GLOBALS['TL_HOOKS']['loadDataContainer'][]    = array('PCT\Test','loadDataContainerCallback'); 

Test.php

<?php 
    
namespace PCT;

use Contao\CoreBundle\Security\ContaoCorePermissions;
use Contao\System;
use Contao\BackendUser;

class Test
{
    public function loadDataContainerCallback($strTable)
    {
        System::importStatic(BackendUser::class,'User');
        $security = System::getContainer()->get('security.helper');
        $hasAccess = $security->isGranted( ContaoCorePermissions::USER_CAN_ACCESS_FORM,1 );
    }
}

[Spooky]

Warum führst du

System::importStatic(BackendUser::class,'User'); 

aus? Und statt

System::getContainer()->get('security.helper'); 

solltest du Dependency Injection nutzen.

[Tim G]

Warum führst du

System::importStatic(BackendUser::class,'User'); 

aus? Und statt

System::getContainer()->get('security.helper'); 

solltest du Dependency Injection nutzen.

Mhh... vielleicht fehlt etwas in der Kette.
Der Code ist quasi ähnlich bzw. gleich dem Contao Core. \tl_content getForms macht es exakt nach diesem Muster bzw. überall wo Rechte abgefragt werden. Die Backend Klasse z.B. quasi exakt nach diesem Muster auch:

Kannst du ein Beispiel geben, wie es aussehen sollte. Thx.

ps. In einem rohen 4.13.12 passt es. Dann wird etwas auf dem Weg dahin hängen. Ich grabe mal tiefer. Danke Dir.

pps. Es handelt sich wohl um einen redirect beim Öffnen eines dynamisch erstellen Backend-Moduls z.B. durch CustomCatalog erstellt. Hier leitet ->isGranted direkt auf /contao/login um, würde ich sagen. Eine Meldung wird nicht ausgegeben. Führt man ->isGranted nicht aus, läuft alles wie gewohnt.

[Tim G]

Zur Info woran es gelegen hat und falls jemand mal ein ähnliches Problem hat

Es kommt auf den Zeitpunkt der Abfrage an. Abfragt wurde im initializeSystem Hook (eine initconfig.php kann zum Test genutzt werden).
Zu diesem frühen Zeitpunkt wird kein Benutzer gefunden im security helper ($security->getUser()), auch nicht wenn man bereits im Backend angemeldet ist. Damit scheitert die Anfrage auf ->isGranted und leitet auf den Login.

Zur Info: BackendUser::getInstance() hingegen ist gefüllt.

[Spooky]

Für solche Zwecke sollte ein Request Listener benutzt werden (der eine geringere Priorität als die Symfony Firewall hat).