Nie można załadować danych użytkownika.

[Jerry77]

Witam,

Właśnie się przesiadłem na Joomla! 2.5.8 i jestem zachwycony. Niestety mój zachwyt nieco zmalał po doinstalowaniu komponentu Admin Tools od Akeeba. Wszystko było pięknie aż do momentu w którym zadecydowałem się zmienić ID Administratora i otrzymałem komunikat, że: JUser::_load: Nie można załadować danych użytkownika o ID: 42. Niby ID zostało zmienione, ale ten błąd jednak mnie niepokoi więc prosiłbym o poradę co z tym można zrobić

[zwiastun]

Gdzie się ten błąd pojawia? Kiedy?

[Jerry77]

Błąd pojawia się na zapleczu Joomla! w panelu Admin Tools podczas próby utworzenia bezpiecznego ID Administratora. Dodaję zrzut ekranu podczas błędu.


Załącznik 6079

[ugly kid joe]

domyślny super_user ( id42 ) wprowadzał pewnie jakieś zmiany w akeeba, i jako właściciela tych zmian akeeba zalogował tego użytkownika.

problem pojawił się, kiedy nadałeś nowego super_usera, a wyłączyłeś starego ( id 42 ) ?

można to cofnąć identyczną systematyką, o ile rejestrujesz na bieżąco zmiany w dodatkach bezpieczeństwa lub ze względu na ilość wprowadzonych, nowych instrukcji ( dla komponentu ), nie jest to kłopotliwe.

nie można cofnąć komunikatu, kiedy super_user ( id 42 ) nie istnieje, chociaż spotkałem się, kiedy wiedząc, którą instrukcję w komponencie wprowadzał domyślny super_user, została ona nazwijmy to "nadpisana" instrukcją wydaną przez nowego super_usera.

dodatki bezpieczeństwa pomyslane są w ten sposób, aby logować zmiany użytkowników, w hierarchii uprawnień, dlatego jesli już mamy akeeba admin tools zainstalowany, należy tę hierarchię i konsekwencję przejrzystej praktyki utrzymywać.

zmiana lub utworzenie nowego super_usera przez dodanie nowego uzytkownika z uprawnieniami w panelu zarządzania użytkownikami i "twarde" usuniecie domyślnego właściciela skutkuje właśnie brakiem odwołania do właściciela, na co wskazuje komunikat.

bezpieczna zmiana identyfikatora właściciela po zainstalowaniu admin tools, powinna odbyć się via admin tools, żeby dodatek bezpieczeństwa, zalogował tę zmianę w systemie.

zaznaczam, że są to przypadki, które ja znam, a ze względu na specyfikę działań administratorów, ani nie można jej wykluczyć, ani uznać za jedyną i ostateczną.

[Jerry77]

Dokładnie tak, problem pojawił się właśnie wtedy gdy nadałem nowe ID dla starego (42). Może jeszcze jakieś wskazówki?

[ugly kid joe]

nadałeś nowe id staremu 42, czy stworzyłeś nowego i usunąłeś 42 ?

w przypadku tego komponentu to duża różnica.

pytam, bo operacje na tych samych profilach, nie rodzą komunikatów o błędach.

[Jerry77]

Nadałem nowe ID staremu. Rozważam mozliwość rezygnacji z tego dodatku dla 2.5. Nota bene na 1.5 czegoś takiego nie miałem z tąd mój niepokuj

[ugly kid joe]

dziwne, ale i nie logiczne, z mojego punktu widzenia.

co na twój problem, oficjalny support ?

[Jerry77]

Nie mam pojęcia, jak na razie odkryłem, że w bazie zamiast 42 był jakis inny wpis. Zmieniłem wiec na 42 i teraz sie nie moge dostać na zaplecze

[Gall Anonim]

Pytanko
Od której wersji Joomla stratowałeś w przypadku Joomla 2.5.?
- jeżeli od bodajże 2.5.6 - ID administratora jest przypisywane losowo więc nadanie bezpiecznego ID odbywa się przy instalacji Joomla - i próba nadania bezpiecznego ID z poziomu komponentu AdminTools jest pomyłką - bo już jest bezpieczne ID, a komponent próbuje zmienić ID domyślnego administratora z poprzednich wersji Joomla nie sprawdzając faktycznego ID w obecnej instalacji. Błąd twórców komponentu ale tak naprawdę mało istotny - i raczej tylko irytujący - nie stanowi żadnego zagrożenia ani wskazania o błędach w ACL Joomla czy też danych użytkowników jako takich.
Pzdr

aaa- widzę że namieszałeś - a kopia zapasowa jest (przynajmniej DB), albo wróć do poprzednich ustawień o ile uda ci się jeszcze bardziej nie namącić.