Suche
Teilen
startseite » forum

Mehrere SysOrdner als Quelle für Login

  • dapo dapo
    TYPO3-Anwärter
    0 x
    5 Beiträge
    0 Hilfreiche Beiträge
    24. 03. 2004, 10:21

    Hallo zusammen,

    ich versuche verschiedenen BE-Usern die Möglichkeit zu geben ihre FE-User selbst zu pflegen. Dazu müssen diese ja Zugriff auf den SysFolder haben der im Template als 'styles.content.loginform.pid' eingetragen ist. Da aber jeder BE-User nur 'seine' User sehen und bearbeiten soll, habe ich gedacht ich könnte gut mehrere SysFolder verwenden. Ich kann aber scheinbar nur einen im Template anmelden. Ist das richtig? Welche Möglichkeit gibt es sonst eine getrennte Verwaltung einzurichten?

    Vielen Dank!
    MfG

    Daniel Potysch

  • 1
  • dapo dapo
    TYPO3-Anwärter
    0 x
    5 Beiträge
    0 Hilfreiche Beiträge
    24. 03. 2004, 14:32

    Hallo,

    ich habe mittlerweile selbst eine Lösung gefunden von der ich aber nicht genau weiß ob sie wirklich so elegant ist.

    Man kann in den Einstellungen des Login-Formulars in dem Feld "Zielseite" neben der eigentlichen Zielseite auch noch zusätzlich den SysFolder eintragen. Dann sucht Typo da nach den Usern.

    Das scheint mir allerdings nicht sehr intuitiv zu sein. Ist das der einzige Weg?

    Gruß,
    Daniel Potysch

  • sw-student sw-studen...
    Jedi-Ratsmitglied
    0 x
    677 Beiträge
    0 Hilfreiche Beiträge
    05. 08. 2004, 12:09

    Hallo!

    Mir geht es im Moment genauso. Hatte mir damals den Login aus irgendwelchen Codeschnipseln selbst zusammengebastelt, musste ich nun aber mit der LDAP Umstellung wieder rausnehmen. Damals konnte ich im Quelltext mehrerer pid's von Sysfoldern angeben, die nach FE Usern durchsucht werden sollen.

    Jetzt hab ich mir die arotea_loginbox (Loginbox for Better Login Plugin) installiert. Hier kann man im Setup auch den Sysordner angeben:

    [code:1:3f871f9368]plugin.tx_arotealoginbox_pi1.pidUserstorage = 765,126,735[/code:1:3f871f9368]

    Sobald ich jedoch mehrere angeben, erscheinen MySQL Fehler beim Login. Der Login selbst funktioniert aber!

    Es wäre ärgerlich alle aufgesplitteten Benutzerordner wieder zusammenzuwerfen müssen :(

    Hier mal die ERRORs:
    [code:1:3f871f9368]Warning: mysql_fetch_assoc(): supplied argument is not a valid MySQL result resource in /usr/local/typo3/htdocs/quickstart/t3lib/class.t3lib_db.php on line 689

    Warning: Cannot modify header information - headers already sent by (output started at /usr/local/typo3/htdocs/quickstart/t3lib/class.t3lib_db.php:689) in /usr/local/typo3/htdocs/quickstart/t3lib/class.t3lib_userauth.php on line 243

    Warning: Cannot modify header information - headers already sent by (output started at /usr/local/typo3/htdocs/quickstart/t3lib/class.t3lib_db.php:689) in /usr/local/typo3/htdocs/quickstart/t3lib/class.t3lib_userauth.php on line 244

    Warning: Cannot modify header information - headers already sent by (output started at /usr/local/typo3/htdocs/quickstart/t3lib/class.t3lib_db.php:689) in /usr/local/typo3/htdocs/quickstart/t3lib/class.t3lib_userauth.php on line 245

    Warning: Cannot modify header information - headers already sent by (output started at /usr/local/typo3/htdocs/quickstart/t3lib/class.t3lib_db.php:689) in /usr/local/typo3/htdocs/quickstart/t3lib/class.t3lib_userauth.php on line 246

    Warning: Cannot modify header information - headers already sent by (output started at /usr/local/typo3/htdocs/quickstart/t3lib/class.t3lib_db.php:689) in /usr/local/typo3/htdocs/quickstart/t3lib/class.t3lib_userauth.php on line 247[/code:1:3f871f9368]

    Vielleicht kennt jmd das Problem, bzw. kann mit der Fehlermeldung was anfangen und mir eine evtl. eine Lösung posten.

    Danke & Gruß
    SW:STUDENT

  • maxhb maxhb
    Flash Gordon
    0 x
    2148 Beiträge
    0 Hilfreiche Beiträge
    05. 08. 2004, 12:34

    Hi!
    [quote:71921cc967="sw-student"]Hier mal die ERRORs:
    [code]Warning: mysql_fetch_assoc(): supplied argument is not a valid MySQL result resource in /usr/local/typo3/htdocs/quickstart/t3lib/class.t3lib_db.php on line 689
    [/quote:71921cc967]
    Ich kenne die Extension zawr überhaupt nicht, allerdings kann ich mir vorstellen, warum dieser Fehler auftaucht. Vermutlich steht im Quelltext, knapp vor der o.g. Zeile 689 ein SQL Statement, in dem mittels 'uid=xyz' exakt eine Seite abgefragt wird. Das müßte ändern in 'uid in(xyz)'.

    Ist nur so geraten...

    CU
    maxhb

  • Dander Dander
    Flash Gordon
    0 x
    2287 Beiträge
    0 Hilfreiche Beiträge
    06. 08. 2004, 10:07

    entweder das oder es fehlt was in der DB was aber bei
    diesem fall eher unwarscheinlich ist

  • dan33 dan33
    R2-D2
    0 x
    99 Beiträge
    0 Hilfreiche Beiträge
    06. 08. 2004, 11:37

    Interessant ist ja nur der erste Fehler.
    Alle weiteren folgen dann aus dem ersten Fehler.

    Da es "nur" ein Warning ist, könntest du entweder die Warnings in der php.ini deaktivieren oder in der Betreffenden Zeile im Quellcode ein "@" vor dem PHP-Befehl stellen, damit werden die Warnings unterdrückt.

    Ist zwar nicht "die" Lösung aber ein Workaround der funktionieren sollte (da ja das Login ansonsten funktionier).

    lg,
    Daniel

  • maxhb maxhb
    Flash Gordon
    0 x
    2148 Beiträge
    0 Hilfreiche Beiträge
    06. 08. 2004, 11:44

    [quote:e2a380439d="dan33"]Ist zwar nicht "die" Lösung aber ein Workaround der funktionieren sollte (da ja das Login ansonsten funktionier).[/quote:e2a380439d]
    In der Tat ist das zwar nur eine Warnung, jedoch sollte man die im Prinzip ernst nehmen, wenn es heisst, dass keine korrekte MySQL-Ressource verwendet wird. Das bedeutet in der Praxis ja meistens, dass der verwendete SQL-String nicht in Ordnung ist.

    CU
    maxhb

  • sw-student sw-studen...
    Jedi-Ratsmitglied
    0 x
    677 Beiträge
    0 Hilfreiche Beiträge
    07. 09. 2004, 08:53

    Hi!

    ... hab nun nach etwas längerer Suche die entsprechenden Codezeilen gefunden.

    Die angegebene Zeile 689 der Fehlermeldung liefert diese Funktion:
    [code:1:349443817d] /**
    * Returns an associative array that corresponds to the fetched row, or FALSE if there are no more rows.
    * mysql_fetch_assoc() wrapper function
    * Usage count/core: 307
    *
    * @param pointer MySQL result pointer (of SELECT query) / DBAL object
    * @return array Associative array of result row.
    */
    function sql_fetch_assoc($res) {
    return mysql_fetch_assoc($res);
    }[/code:1:349443817d]

    Also hab ich mich nach dieser in der LDAP Extension auf die Suche begeben. Nach einigem auskommentieren bin ich nun auf die betreffende Zeilen gestossen:

    [code:1:349443817d] if (t3lib_extMgm::isLoaded('eu_ldap')) {
    $dbres = $GLOBALS['TYPO3_DB']->exec_SELECTquery(
    '*',
    'tx_euldap_server',
    ($this->checkPid ? 'pid = '.$this->checkPid_value : '')
    );

    while (($row = $GLOBALS['TYPO3_DB']->sql_fetch_assoc($dbres)) && !($OK)) {
    if ($F_uname && $F_uident) {
    $ldapres = tx_euldap_div::checkNTUser($row,$F_uname,$F_uident);
    } else {
    //if SSO
    $ldapres=tx_euldap_div::sso($row);
    $F_uname=$ldapres['cn'][0];
    }[/code:1:349443817d]

    Kommentiere ich die Zeile mit der sql_fetch_assoc Funktion aus, verschwinden die Warnungen. Hab nun leider kein Plan woran das liegen könnte. Klar ist wohl dass man $dbres untersuchen muss. Der Tipp mit "IN" anstelle von "=" war gut, leider nicht erfolgreich.

    Ne Idee auf den ersten (oder zweiten) Blick?

    @dan33: Ein '@' in betreffender Zeile funktioniert übrigens wunderbar, behebt aber leider die eigentlich Ursache nicht. Trotzdem danke dafür.

    Danke, Gruß
    []s[#]w[]

  • 1
Präsentiert von