1 - będą 3 poziomy level 0 - brak logowania level 1 - podstawowe informacje że nastąpiła zmiana tu i tu level 2 - to co w level1 + diff
i teraz pytanie, czy tą opcje umieścić w phpui czy tylko w lms.ini, umieszczenie w lms.ini w sekcji [syslog] zabezpieczy nam, swobodne wyłączenie logowania przez pracowników , ja był bym za tym rozwiązaniem, również w lms.ini umieścił bym zmienną która zawierałaby ID użytkowników którzy mogą kasować logi, natomiast ustalenie prawa do przeglądania logów umieścił bym normalnie w karcie użytkownika
jaką wersję przyjąć ?
2 - kogo logować, czy zrobić jeden globalny przełącznik który loguje każdego, czy zrobić personalizację, czyli wybieramy kogo ma logować ?
W dniu 2012-11-01 14:09, Sylwester Kondracki pisze:
1 - będą 3 poziomy level 0 - brak logowania level 1 - podstawowe informacje że nastąpiła zmiana tu i tu level 2 - to co w level1 + diff
i teraz pytanie, czy tą opcje umieścić w phpui czy tylko w lms.ini, umieszczenie w lms.ini w sekcji [syslog] zabezpieczy nam, swobodne wyłączenie logowania przez pracowników , ja był bym za tym rozwiązaniem, również w lms.ini umieścił bym zmienną która zawierałaby ID użytkowników którzy mogą kasować logi, natomiast ustalenie prawa do przeglądania logów umieścił bym normalnie w karcie użytkownika
Ja bym w ogóle nie umożliwiał wyłączanie tego, log ma być nieusuwalny nienaruszalny, ewentualnie żeby go kasować po upływie jakiegoś tam czasu (z pominięciem zmian IP itp.)
jaką wersję przyjąć ?
2 - kogo logować, czy zrobić jeden globalny przełącznik który loguje każdego, czy zrobić personalizację, czyli wybieramy kogo ma logować ?
Wszystkich bez wyjątku, tak żeby było wiadomo kto narozrabiał
W dniu 2012-11-01 14:09, Sylwester Kondracki pisze:
1 - będą 3 poziomy level 0 - brak logowania level 1 - podstawowe informacje że nastąpiła zmiana tu i tu level 2 - to co w level1 + diff
i teraz pytanie, czy tą opcje umieścić w phpui czy tylko w lms.ini, umieszczenie w lms.ini w sekcji [syslog] zabezpieczy nam, swobodne wyłączenie logowania przez pracowników , ja był bym za tym rozwiązaniem, również w lms.ini umieścił bym zmienną która zawierałaby ID użytkowników którzy mogą kasować logi, natomiast ustalenie prawa do przeglądania logów umieścił bym normalnie w karcie użytkownika
jaką wersję przyjąć ?
2 - kogo logować, czy zrobić jeden globalny przełącznik który loguje każdego, czy zrobić personalizację, czyli wybieramy kogo ma logować ?
Korzystajac z chwili wolnego czasu opisze jak to zrobione jest w programie ktory obsluguje (duza firma ISP). Log zawsze jest niemodyfikowalny, nieusuwalny, logujacy wszystko! Oczywiscie jest to baza danych wiec tak z tym nieusuwaniem itp to bym sie klocil. Jest podzial na userow ktorzy wykonuja dane czynnosci. Czyli w skrocie - admin widzi wszystkie logi wszystkich uzytkownikow Dany uzytkownik widzi tylko swoje logi (zowie sie to historia czynnosci)
W logu do ktorego mam dostep jako user widze: date, ip z ktorego sie loguje, kazda operacje jaka wykonalem. Zaznaczajac log szczegolowy widze nawet ktore karty przegladalem. Czy liste userow, czy ich platnosci etc. Tak wiec jak mniemam logowane jest wszystko! Nie wiem jak ma sie to do wielkosci bazy, ale tego systemu uzywa ok 200 pracownikow, a w bazie sa dane ok 230tys klinetow.
To tak na szybkiego - moze w czyms te info pomoze.
pozdrawiam
Dnia 2012-11-01, czw o godzinie 14:50 +0100, Andrzej Banach pisze:
W dniu 2012-11-01 14:09, Sylwester Kondracki pisze:
1 - będą 3 poziomy level 0 - brak logowania level 1 - podstawowe informacje że nastąpiła zmiana tu i tu level 2 - to co w level1 + diff
i teraz pytanie, czy tą opcje umieścić w phpui czy tylko w lms.ini, umieszczenie w lms.ini w sekcji [syslog] zabezpieczy nam, swobodne wyłączenie logowania przez pracowników , ja był bym za tym rozwiązaniem, również w lms.ini umieścił bym zmienną która zawierałaby ID użytkowników którzy mogą kasować logi, natomiast ustalenie prawa do przeglądania logów umieścił bym normalnie w karcie użytkownika
jaką wersję przyjąć ?
2 - kogo logować, czy zrobić jeden globalny przełącznik który loguje każdego, czy zrobić personalizację, czyli wybieramy kogo ma logować ?
Korzystajac z chwili wolnego czasu opisze jak to zrobione jest w programie ktory obsluguje (duza firma ISP). Log zawsze jest niemodyfikowalny, nieusuwalny, logujacy wszystko! Oczywiscie jest to baza danych wiec tak z tym nieusuwaniem itp to bym sie klocil. Jest podzial na userow ktorzy wykonuja dane czynnosci. Czyli w skrocie - admin widzi wszystkie logi wszystkich uzytkownikow Dany uzytkownik widzi tylko swoje logi (zowie sie to historia czynnosci)
W logu do ktorego mam dostep jako user widze: date, ip z ktorego sie loguje, kazda operacje jaka wykonalem. Zaznaczajac log szczegolowy widze nawet ktore karty przegladalem. Czy liste userow, czy ich platnosci etc. Tak wiec jak mniemam logowane jest wszystko! Nie wiem jak ma sie to do wielkosci bazy, ale tego systemu uzywa ok 200 pracownikow, a w bazie sa dane ok 230tys klinetow.
To tak na szybkiego - moze w czyms te info pomoze.
pozdrawiam
a jak jest w karcie kompa czy klienta, też widzisz tylko swoje logi ?
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 2012-11-01 15:07, Sylwester Kondracki pisze:
Dnia 2012-11-01, czw o godzinie 14:50 +0100, Andrzej Banach pisze:
W dniu 2012-11-01 14:09, Sylwester Kondracki pisze:
1 - będą 3 poziomy level 0 - brak logowania level 1 - podstawowe informacje że nastąpiła zmiana tu i tu level 2 - to co w level1 + diff
i teraz pytanie, czy tą opcje umieścić w phpui czy tylko w lms.ini, umieszczenie w lms.ini w sekcji [syslog] zabezpieczy nam, swobodne wyłączenie logowania przez pracowników , ja był bym za tym rozwiązaniem, również w lms.ini umieścił bym zmienną która zawierałaby ID użytkowników którzy mogą kasować logi, natomiast ustalenie prawa do przeglądania logów umieścił bym normalnie w karcie użytkownika
jaką wersję przyjąć ?
2 - kogo logować, czy zrobić jeden globalny przełącznik który loguje każdego, czy zrobić personalizację, czyli wybieramy kogo ma logować ?
Korzystajac z chwili wolnego czasu opisze jak to zrobione jest w programie ktory obsluguje (duza firma ISP). Log zawsze jest niemodyfikowalny, nieusuwalny, logujacy wszystko! Oczywiscie jest to baza danych wiec tak z tym nieusuwaniem itp to bym sie klocil. Jest podzial na userow ktorzy wykonuja dane czynnosci. Czyli w skrocie - admin widzi wszystkie logi wszystkich uzytkownikow Dany uzytkownik widzi tylko swoje logi (zowie sie to historia czynnosci)
W logu do ktorego mam dostep jako user widze: date, ip z ktorego sie loguje, kazda operacje jaka wykonalem. Zaznaczajac log szczegolowy widze nawet ktore karty przegladalem. Czy liste userow, czy ich platnosci etc. Tak wiec jak mniemam logowane jest wszystko! Nie wiem jak ma sie to do wielkosci bazy, ale tego systemu uzywa ok 200 pracownikow, a w bazie sa dane ok 230tys klinetow.
To tak na szybkiego - moze w czyms te info pomoze.
pozdrawiam
a jak jest w karcie kompa czy klienta, też widzisz tylko swoje logi ?
Nie ma czegos takiego jak karta klienta/kompa :) To program calkowicie nie lms'opodobny. W kazdym razie dostep do logow jest tylko ze strony glownej. Po kliknieciu otwiera sie okno z logiem czynnosci i tam kazde logowanie, jakakolwiek operacja itp sa "zanotowane". Widze tylko swoje zmiany/czynnosci jakie zrobilem. Admin widzi wszystkie zmiany wszystkich userow. Ten log nie sluzy do codziennego sprawdzania co kto zrobil i czy wykonuje swoja prace. Ten log sluzy w razie godziny W do sprawdzenia kto np klientowi zmianil taryfe czy zmienil jego dane. Poza userami fizyczyni sa tez userzy automatow. Tak wiec widac na biezaca ze jakis automat np zmienil taryfe etc. Ale to sa tylko logi czynnosci ktore ciazko sie czyta jakby ktos chcial codziennie je sobie przegladac.
Do takich czynnosci jak zmiana taryf itp jest historia operacji. Tam sa zawarte takie dane ktorych potrzebujemy na codzien. Ze np zmieniono taryfe (z jakiej na jaka), ze wymieniono urzadzenie (dane starego i nowego), ze wlaczono wifi itp. Tu takze widnieja przyszle operacje (np ze za miesiac zmieniona zostanie taryfa na wieksza. Po prostu jak klient podpisuje umowe to juz po wklepaniu do systemu nigdy nie zagladamy na jego konto by cos przestawic - tam system pamieta by czynnosc wykonac. Ta historia czynnosci (nie log) dotyczy takze zmian u klienta (zmiana adresu, zmiana danych osobowych itp). Ale te dwie historie nie maja nic wspolnego z logiem. W logu sa tysiace rekordow. W historiach zmian po kilka, kilkanascie max.
pozdrawiam
W dniu 01.11.2012 14:09, Sylwester Kondracki napisał(a):
1 - będą 3 poziomy level 0 - brak logowania level 1 - podstawowe informacje że nastąpiła zmiana tu i tu level 2 - to co w level1 + diff
i teraz pytanie, czy tą opcje umieścić w phpui czy tylko w lms.ini, umieszczenie w lms.ini w sekcji [syslog] zabezpieczy nam, swobodne wyłączenie logowania przez pracowników , ja był bym za tym rozwiązaniem, również w lms.ini umieścił bym zmienną która zawierałaby ID użytkowników którzy mogą kasować logi, natomiast ustalenie prawa do przeglądania logów umieścił bym normalnie w karcie użytkownika
To nie jest kwestia takiego wyboru, gdyż od dawien dawna LMS korzysta z ustawień trzymanych w DB, a w drugiej kolejności z lms.ini.
jaką wersję przyjąć ?
2 - kogo logować, czy zrobić jeden globalny przełącznik który loguje każdego, czy zrobić personalizację, czyli wybieramy kogo ma logować ?
--
_Pozdrawiam_ Sylwester Kondracki
gg: 6164816
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Dnia 2012-11-02, pią o godzinie 18:17 +0100, Tomasz Chiliński pisze:
W dniu 01.11.2012 14:09, Sylwester Kondracki napisał(a):
1 - będą 3 poziomy level 0 - brak logowania level 1 - podstawowe informacje że nastąpiła zmiana tu i tu level 2 - to co w level1 + diff
i teraz pytanie, czy tą opcje umieścić w phpui czy tylko w lms.ini, umieszczenie w lms.ini w sekcji [syslog] zabezpieczy nam, swobodne wyłączenie logowania przez pracowników , ja był bym za tym rozwiązaniem, również w lms.ini umieścił bym zmienną która zawierałaby ID użytkowników którzy mogą kasować logi, natomiast ustalenie prawa do przeglądania logów umieścił bym normalnie w karcie użytkownika
To nie jest kwestia takiego wyboru, gdyż od dawien dawna LMS korzysta z ustawień trzymanych w DB, a w drugiej kolejności z lms.ini.
w tym przypadku, moim zdaniem jest ważniejsze zabezpieczenie przed swobodnym wyłączeniem logowania przez jakiegoś pracownika, niż trzymanie wszystkich opcji konfiguracyjnych w miarę łatwo dostępnym miejscu. Domyślnie syslog będzie włączony, jeżeli będziemy chcieli wyłączyć to będzie trzeba umieścić dany wpis do lms.ini dla tego ja jestem za tym, aby możliwość wyłączenia logowania była tylko w lms.ini w sekcji [syslog], bo : 1 - nie będzie to dostępne z poziomu panelu, 2 - żaden pracownik nie wyłączy logowania, zwłaszcza jak ma dostęp do konfiguracji 3 - przez przypadek też tego nie wywalimy 4 - a wejście do lms.ini i zmiana ustawień potwierdzi tylko że jesteśmy świadomi tego co robimy.
a swoją drogą powrócił bym do ustawień w lms.ini jeżeli chodzi o loginy, hasła itp. do różnego rodzaju kont, po grzyb pracownikowi widzieć to i owo, dzisiaj jest jutro go nie ma, a nikt nie będzie pamiętał że dobrze by było zmienić hasło np. na skrzynce nadawczej (@) bo ktoś może to nieładnie wykorzystać. ot takie moje małe rozważanie :D
jaką wersję przyjąć ?
2 - kogo logować, czy zrobić jeden globalny przełącznik który loguje każdego, czy zrobić personalizację, czyli wybieramy kogo ma logować ?
--
_Pozdrawiam_ Sylwester Kondracki
gg: 6164816
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 2012-11-02 18:33, Sylwester Kondracki pisze:
Dnia 2012-11-02, pią o godzinie 18:17 +0100, Tomasz Chiliński pisze:
W dniu 01.11.2012 14:09, Sylwester Kondracki napisał(a):
1 - będą 3 poziomy level 0 - brak logowania level 1 - podstawowe informacje że nastąpiła zmiana tu i tu level 2 - to co w level1 + diff
i teraz pytanie, czy tą opcje umieścić w phpui czy tylko w lms.ini, umieszczenie w lms.ini w sekcji [syslog] zabezpieczy nam, swobodne wyłączenie logowania przez pracowników , ja był bym za tym rozwiązaniem, również w lms.ini umieścił bym zmienną która zawierałaby ID użytkowników którzy mogą kasować logi, natomiast ustalenie prawa do przeglądania logów umieścił bym normalnie w karcie użytkownika
To nie jest kwestia takiego wyboru, gdyż od dawien dawna LMS korzysta z ustawień trzymanych w DB, a w drugiej kolejności z lms.ini.
w tym przypadku, moim zdaniem jest ważniejsze zabezpieczenie przed swobodnym wyłączeniem logowania przez jakiegoś pracownika, niż trzymanie wszystkich opcji konfiguracyjnych w miarę łatwo dostępnym miejscu. Domyślnie syslog będzie włączony, jeżeli będziemy chcieli wyłączyć to będzie trzeba umieścić dany wpis do lms.ini dla tego ja jestem za tym, aby możliwość wyłączenia logowania była tylko w lms.ini w sekcji [syslog], bo : 1 - nie będzie to dostępne z poziomu panelu, 2 - żaden pracownik nie wyłączy logowania, zwłaszcza jak ma dostęp do konfiguracji 3 - przez przypadek też tego nie wywalimy 4 - a wejście do lms.ini i zmiana ustawień potwierdzi tylko że jesteśmy świadomi tego co robimy.
a swoją drogą powrócił bym do ustawień w lms.ini jeżeli chodzi o loginy, hasła itp. do różnego rodzaju kont, po grzyb pracownikowi widzieć to i owo, dzisiaj jest jutro go nie ma, a nikt nie będzie pamiętał że dobrze by było zmienić hasło np. na skrzynce nadawczej (@) bo ktoś może to nieładnie wykorzystać. ot takie moje małe rozważanie :D
Chwila. Ale czy odptaszenie "konfiguracja interfejsu użytkownika" w uprawnianiach danego usera nie zalatwia sprawy? Przeciez wtedy nie ma uprawnien do przeladania "konfiguracji" i sprawa zalatwiona. Ja w lms.ini trzymam tylko i wylacznie login, haslo do bazy i chyba jakies tam sciezki do katalogow. Wszystko inne jest w bazie i przy jakichs przenosinach itp martwie sie tylko o baze a nie o plik konfiguracyjny.
pozdrawiam
Dnia 2 listopada 2012 18:45 Andrzej Banach lms@net-komp.net.pl napisał(a):
Chwila. Ale czy odptaszenie "konfiguracja interfejsu użytkownika" w uprawnianiach danego usera nie zalatwia sprawy? Przeciez wtedy nie ma uprawnien do przeladania "konfiguracji" i sprawa zalatwiona. Ja w lms.ini trzymam tylko i wylacznie login, haslo do bazy i chyba jakies tam sciezki do katalogow. Wszystko inne jest w bazie i przy jakichs przenosinach itp martwie sie tylko o baze a nie o plik konfiguracyjny.
pozdrawiam
Dokładnie, pracownik nie powinien mieć dostępu do opcji konfiguracyjnych UI a to idzie wyłączyć jak pisze Andrzej. Jedynie administrator, który ma dostęp zapewne także do lms.ini, więc ryzyko podejrzenia parametrów konfiguracyjnych przez pracownika odpada.
pozdrawiam Tomek
uczestnicy (5)
-
Andrzej Banach -
Daniel Kulesza -
Sylwester Kondracki -
tdabek＠go2.pl -
Tomasz Chiliński