jak usunac konto z forum

[bsk 3]

jak w temacie

[Lestaf 450]

Musisz poprosić o to moderatora. A czemu chcesz kasować profil?

[Robson01 3]

Może pogniewał się na zegarki

[Lestaf 450]

A może źle go zrozumieliśmy, może chce usunąć konto komuś innemu

[Krystian 1921]

Może chce poszerzyć informatyczną wiedzę?

 

Tak na poważnie, to po tylu latach na forum powinieneś wiedzieć, że wystarczy napisać PW do admina.

[Taktic 43]

Ja stawiam na to że ma dwa konta, i teraz chce jedno z nich usunąć, bo mu wyrzuty sumienia nie dają spać po nocach

[bsk 3]

Musisz poprosić o to moderatora. A czemu chcesz kasować profil?

dzieki za informacje

[gniewko 126]

Generalnie nie powinno sie kasowac kont na forach, podobnie jak w Active Directory itp. Bo moze to byc przyczyna problemow w przyszlosci.

Mozna samemu wykasowac wszystkie swoje dane osobowe i poprosic admina o bana

[Gość McIntosh]

Generalnie nie powinno sie kasowac kont na forach, podobnie jak w Active Directory itp. Bo moze to byc przyczyna problemow w przyszlosci.

Mozna samemu wykasowac wszystkie swoje dane osobowe i poprosic admina o bana

 

A co tu Active Directory ma do rzeczy ?. To nie serwer firmowy tylko Forum zrzeszające miłośników zegarków na zasadach dobrowolnych.

[gniewko 126]

A co tu Active Directory ma do rzeczy ?. To nie serwer firmowy tylko Forum zrzeszające miłośników zegarków na zasadach dobrowolnych.

 

To, ze jedno i drugie jest oparte na bazie danych gdzie kazdy user posiada swoj SID i nie jest zalecane kasowanie tylko blokowanie konta.

[whb 9]

To, ze jedno i drugie jest oparte na bazie danych gdzie kazdy user posiada swoj SID i nie jest zalecane kasowanie tylko blokowanie konta.

 

Popatrz, a Microsoft o tym nie wie

[gniewko 126]

Popatrz, a Microsoft o tym nie wie

 

Pisze o tym co mowil gosc na szkoleniu z AD (praktyczne doswiadczenie trenera jest dla mnie cenniejsze niz belkot MS). Podobnie jest z kontami w systemach Linux/UNIX. Generalnie liczba objektow jakie mozemy zestawic jest tak duza, ze niema potrzeby kasowania userow gdyz w przyszlosci moga pojawic sie konflikty gdy nowy user zostanie powiazany z SIDem usera ktory kiedys istnial.

Co jak co ale nie bral bym za wyrocznie slowa pisanego przez MS

[bEEf 3]

Popatrz, a Microsoft o tym nie wie

Ale to akurat prawda jest. Wszystko się da, ale zobacz, jak wyglądają wpisy osób, których konto zostało usunięte. Jakiś "guest_cośtam", nie można sprawdzić historii, profilu użytkownika itd. Moim zdaniem konta nie powinno się dać usunąć i na większości forum się nie da. Zawsze za to można poprosić o zablokowanie konta.

[Gość art3c]

Pisze o tym co mowil gosc na szkoleniu z AD (praktyczne doswiadczenie trenera jest dla mnie cenniejsze niz belkot MS). Podobnie jest z kontami w systemach Linux/UNIX. Generalnie liczba objektow jakie mozemy zestawic jest tak duza, ze niema potrzeby kasowania userow gdyz w przyszlosci moga pojawic sie konflikty gdy nowy user zostanie powiazany z SIDem usera ktory kiedys istnial.

Co jak co ale nie bral bym za wyrocznie slowa pisanego przez MS

 

Według mnie bzdura. Powinno się kasować dane, bo później są tylko problemy z ich ochroną, składowaniem itp. W każdej bazie tego typu przydziela się nowe, unikalne identyfikatory rekordów (czy tam użytkowników) i nie ma potrzeby trzymać do tego całych historycznych danych. Wystarczy zapisywać ostatnie ID. Zgodzę się, że liczba obiektów może być oszołamiająca, ale nie widzę potrzeby trzymania ich w całości.

 

Co do Linuxa nie widzę tu też problemu. Jak wywalam usera z systemu, to mój daemon kasuje całą jego zawartość, także nie ma problemu z ponownym użyciem starych danych.

[gniewko 126]

Według mnie bzdura. Powinno się kasować dane, bo później są tylko problemy z ich ochroną, składowaniem itp. W każdej bazie tego typu przydziela się nowe, unikalne identyfikatory rekordów (czy tam użytkowników) i nie ma potrzeby trzymać do tego całych historycznych danych. Wystarczy zapisywać ostatnie ID. Zgodzę się, że liczba obiektów może być oszołamiająca, ale nie widzę potrzeby trzymania ich w całości.

 

Co do Linuxa nie widzę tu też problemu. Jak wywalam usera z systemu, to mój daemon kasuje całą jego zawartość, także nie ma problemu z ponownym użyciem starych danych.

 

Wedlug mnie tez

[shadow 12]

Praktyka nie kasowania kont wynika z faktu, ze nie wszystkie programy sa wolne od bledow a i ludzie sie myla. I w ten sposob, ktos moze bezwiednie "odziedziczyc" uprawnienia i uzyskac dostep do nie swoich danych poprzez wybranie (przydzielenie) tej samej nazwy uzytkownika. Pomijam juz, ze nie wszystkie "programy" pracuja na identyfikatorach w postaci id A nawet jezeli pracuja to nie raz w historii widziano przypadki przekrecania licznikow albo problemow w przypadku np. sklejania dwoch baz danych. W Linuxie tez tak kiedys bywalo, że liczniki sie przekrecaly i szczesliwy czlowiek nagle stawal sie rootem Tak na marginesie - id z bazy widzi czesto jedynie administrator, wiec uzytkownicy moga pasc ofiara celowej lub przypadkowej "kradziezy tozsamosci"... Praktyka nie kasowania wynikac moze jeszcze z innych aspektow np. kwestii zapewnienia rozliczalnosci przez jakis czas po odejsciu uzytkownika, albo mozliwosci dania "szansy na powrot" itd. Co do istotnosci takich dzialan na forum sie nie wypowiadam bo nie znam tego oprogramowania - ale pewne idee sa uniwersalne.

Aspekty kasowania/nie kasowania kont mozna rowniez rozpatrywac nie tylko na tle informatycznym, ale i prawnym - typu ustawa o ochronie danych osobowych...

 

Uff ale sie rozpisalem!

[Gość art3c]

Pomijam juz, ze nie wszystkie "programy" pracuja na identyfikatorach w postaci id A nawet jezeli pracuja to nie raz w historii widziano przypadki przekrecania licznikow albo problemow w przypadku np. sklejania dwoch baz danych. W Linuxie tez tak kiedys bywalo, że liczniki sie przekrecaly i szczesliwy czlowiek nagle stawal sie rootem

 

Mógłbyś podać link do jakiejś informacji o tym przekręcaniu? Pracuje w tym zawodzie 5 lat a jeszcze z tym się nie spotkałem

 

Tak na marginesie - id z bazy widzi czesto jedynie administrator, wiec uzytkownicy moga pasc ofiara celowej lub przypadkowej "kradziezy tozsamosci"...

 

Mogę się założyć, że ID user jest w bazie z atrybutami AUTO_INCREMENT, co oznacza, że żaden użytkownik nie będzie miał tego samego ID. Nawet jeśli usuniemy go z bazy - wtedy oprogramowanie nie zapełnia luk, tylko konsekwentnie przydziela nowe identyfikatory.

 

Praktyka nie kasowania wynikac moze jeszcze z innych aspektow np. kwestii zapewnienia rozliczalnosci przez jakis czas po odejsciu uzytkownika, albo mozliwosci dania "szansy na powrot" itd. Co do istotnosci takich dzialan na forum sie nie wypowiadam bo nie znam tego oprogramowania - ale pewne idee sa uniwersalne.

Aspekty kasowania/nie kasowania kont mozna rowniez rozpatrywac nie tylko na tle informatycznym, ale i prawnym - typu ustawa o ochronie danych osobowych...

 

To powinien regulować regulamin. W tym skrypcie forum ładnie to rozwiązano: skasowani użytkownicy mają prefix gość_ przez co nie zaburza to ciągłości wątków.

[shadow 12]

Mógłbyś podać link do jakiejś informacji o tym przekręcaniu? Pracuje w tym zawodzie 5 lat a jeszcze z tym się nie spotkałem

 

 

 

Mogę się założyć, że ID user jest w bazie z atrybutami AUTO_INCREMENT, co oznacza, że żaden użytkownik nie będzie miał tego samego ID. Nawet jeśli usuniemy go z bazy - wtedy oprogramowanie nie zapełnia luk, tylko konsekwentnie przydziela nowe identyfikatory.

 

 

 

To powinien regulować regulamin. W tym skrypcie forum ładnie to rozwiązano: skasowani użytkownicy mają prefix gość_ przez co nie zaburza to ciągłości wątków.

 

Hmm trudne zadanie mi wynalazles - znalezc informacje sprzed tylu lat... o przekrecaniu UIDów - http://lwn.net/1999/...a/32bitUID.html - tu sa jakies pozostalosci. A tu masz pare podatnosci opartych o przekrecaniu innych licznikow 16 bitowych w linuxie i nie tylko - http://insecure.org/sploits_linux.html... To byly lata 90 (koniec). Jak widzisz wtedy bugi z licznikami byly popularne (ze nie wspomne juz o szale y2k )

 

 

5 lat mowisz.... A tak z ciekawosci np. z rozszerzonymi atrybutami filesystemu ext3 (w ext2 chyba tez byly) typu immutable sie spotkales?

 

Co do auto inkrementacji - w teorii wszystko dziala dobrze Byc moze jest jak piszesz (podobnie bym zakladal). Co nie zmienia faktu, ze rzeczywistosc lubi zaskakiwac - ja podalem ogolne przyklady. A tworcy aplikacji czesto pisza jak chca.

 

Co do regulaminu - powinno - ale nie wiem bo uczciwie mowiac nie czytalem :]

[gniewko 126]

Mogę się założyć, że ID user jest w bazie z atrybutami AUTO_INCREMENT, co oznacza, że żaden użytkownik nie będzie miał tego samego ID. Nawet jeśli usuniemy go z bazy - wtedy oprogramowanie nie zapełnia luk, tylko konsekwentnie przydziela nowe identyfikatory.

 

To tylko ladna teoria. Zapraszam na szkolenie z AD na Windows 2003 Server i zapytaj sie instruktora czy rekomenduje kasowanie userow czy ich blokowanie.

Tylko nie pisz prosze ze MS nie wpadl na pomysl atrybutow AUTO_INCREMENT w swoim AD

Powiem wiecej w mojej firmie sa raczej dosc duze (od 20G do 10 TB) bazy danych OLTP i nikt nawet nie mysli o kasowaniu userow - baza MS SQL 2008R2.

Niestety ale nawet najlepsze aplikacje potrafia czasami niemile zaskoczyc dlatego takie sa rekomendacje ludzi ktorzy praktycznie znaja takie systemy a nie tych co sie naczytali teori na MSDN.

 

Dla mnie to tyle w tym temacie. Sa na tym forum admini i to do nich nalezy decyzja.

[Gość art3c]

Hmm trudne zadanie mi wynalazles - znalezc informacje sprzed tylu lat...

 

Wtedy to dopiero zaczynałem z Linuksem, także nie byłem świadom Ale dzięki za linki, zawsze to ciekawostka

 

5 lat mowisz.... A tak z ciekawosci np. z rozszerzonymi atrybutami filesystemu ext3 (w ext2 chyba tez byly) typu immutable sie spotkales?

 

Spotkałem się i było w ext2 już zaimplementowane.

 

Co do auto inkrementacji - w teorii wszystko dziala dobrze Byc moze jest jak piszesz (podobnie bym zakladal). Co nie zmienia faktu, ze rzeczywistosc lubi zaskakiwac - ja podalem ogolne przyklady. A tworcy aplikacji czesto pisza jak chca.

 

W sumie to w każdym aspekcie tak jest Nawet jak kod działa inaczej, niż pisałem w poprzednim poście to i tak jest narażony na tysiące błędów

[Gość art3c]

To tylko ladna teoria. Zapraszam na szkolenie z AD na Windows 2003 Server i zapytaj sie instruktora czy rekomenduje kasowanie userow czy ich blokowanie.

 

Nie muszę chodzić na szkolenie, żeby wiedzieć, że nie wierzy się nigdy na słowo. Zatem jak ten instruktor uzasadniał takie zalecenie? Bo "oprogramowanie może czasem nawalić" brzmi dosyć ogólnikowo.

 

Tylko nie pisz prosze ze MS nie wpadl na pomysl atrybutow AUTO_INCREMENT w swoim AD

Powiem wiecej w mojej firmie sa raczej dosc duze (od 20G do 10 TB) bazy danych OLTP i nikt nawet nie mysli o kasowaniu userow - baza MS SQL 2008R2.

Niestety ale nawet najlepsze aplikacje potrafia czasami niemile zaskoczyc dlatego takie sa rekomendacje ludzi ktorzy praktycznie znaja takie systemy a nie tych co sie naczytali teori na MSDN.

 

Nie używam produktów MS, ponieważ uważam, że nie mają mnie do zaoferowania nic, prócz dobrego wsparcia technicznego. Dlatego też nie wgłębiam się, dlaczego implementują coś tak a nie inaczej. Skoro taka jest ich polityka to ok. Ale wszystko zależy od zastosowań - przecież np. jak banki kasują konto, to dane historyczne muszą pozostać nietknięte. Na forum IMO nie ma takiej potrzeby. Bo jak dla mnie konta nieaktywnych użytkowników są zwykłymi śmieciami w DB.

[gniewko 126]

Nie muszę chodzić na szkolenie, żeby wiedzieć, że nie wierzy się nigdy na słowo. Zatem jak ten instruktor uzasadniał takie zalecenie? Bo "oprogramowanie może czasem nawalić" brzmi dosyć ogólnikowo.

 

 

 

Nie używam produktów MS, ponieważ uważam, że nie mają mnie do zaoferowania nic, prócz dobrego wsparcia technicznego. Dlatego też nie wgłębiam się, dlaczego implementują coś tak a nie inaczej. Skoro taka jest ich polityka to ok. Ale wszystko zależy od zastosowań - przecież np. jak banki kasują konto, to dane historyczne muszą pozostać nietknięte. Na forum IMO nie ma takiej potrzeby. Bo jak dla mnie konta nieaktywnych użytkowników są zwykłymi śmieciami w DB.

 

Generalnie twierdzil, ze niema sensu kasowania userow poniewaz za jakis czas zechca wrocic do pracy w firmie i zaczna sie problemy - bo kiedys istanial user a.kowalski admin wykasowal go z AD zostaly jakies smieci w aplikacji teraz wraca znowu trzeba nadac mu identyfikator a.kowalski i AD odmawia posluszenstwa bo "widzi" jakies obiekty tego usera z przeszlosci.

A tak jak admin go tylko wylaczy to pozniej jednym kliknieciem ma wszystko zrobione.

Chce jeszcze raz zaznaczyc, ze samo wykasowanie z bazy nie jest problemem i powinno wykasowac calkowicie usera, jednak systemy w tym takie forum to nie tylko baza ale i jakas aplikacja, ktora z niej kozysta i w niej tez sa pozapisywane identyfikatory dla usera (wszelkiego rodzaju xml itp.) i to wlasnie takie martwe stare wpisy sa najwiekszym problemem.

[Lestaf 450]

Nieśmiało chciałbym zauważyć, że najwyraźniej swoją dyskusją skutecznie zniechęciliście kolegę bsk do usunięcia konta. Brawo!

[gniewko 126]

Nieśmiało chciałbym zauważyć, że najwyraźniej swoją dyskusją skutecznie zniechęciliście kolegę bsk do usunięcia konta. Brawo!

 

Bo taki byl cel tej rozmowy

[Gość art3c]

Generalnie twierdzil, ze niema sensu kasowania userow poniewaz za jakis czas zechca wrocic do pracy w firmie i zaczna sie problemy - bo kiedys istanial user a.kowalski admin wykasowal go z AD zostaly jakies smieci w aplikacji teraz wraca znowu trzeba nadac mu identyfikator a.kowalski i AD odmawia posluszenstwa bo "widzi" jakies obiekty tego usera z przeszlosci.

 

Takie wytłumaczenie ma sens, ale nie zawsze ma zastosowanie Ja projektuje systemy hostingowe i tam trzymanie danych nie jest wskazane, ponieważ:

 

a) Blokuje to loginy (często atrakcyjnych, które są powiązane z subdomeną)

Problem z przechowywaniem danych (miejsce na dysku jest cenne, bo się je sprzedaje)

c) Problem z bezpieczeństwem - zawsze istnieje ryzyko, że ktoś uzyska dostęp do nieaktywnego konta i wtedy wrażliwe dane (np. bazy danych sklepów z nr. kart kredytowych) mogą zostać skradzione.

 

Zwykle polityka jest taka, że konto po okresie rozliczeniowym się faktycznie blokuje (aby dać użytkownikowi możliwość skopiowania danych) ale po jakimś czasie się je całkowicie usuwa. Nie jest to proste, bo trzeba usunąć wszelkie ślady działalności w systemie (zwykle jest daemon, który się tym zajmuje). Wyjątkiem są dane kontaktowe oraz logi (zostają dłużej, na wypadek nielegalnych działalności użytkownika ) - ale one są trzymane na zewnętrznej maszynie.