Post
#1
|
|
|
Grupa: Zarejestrowani Postów: 898 Pomógł: 48 Dołączył: 2.11.2005 Skąd: Poznań Ostrzeżenie: (0%)
|
W jednej z aplikacji, w której przetwarza się dane osobowe etc. widziałem dość ciekawy "patent", a mianowicie zamiast standardowych numerycznych ID w tabeli stosowane są losowe ciągi 40 znaków (przypuszczalnie jakieś md5 z randa). Jeśli dobrze rozumiem intencję autora, to chodzi o to, aby w aplikacji współdzielonej dodać dodatkowe zabezpieczenie np. gdy ktoś w swoim profilu edytując rekord, podmieniłby id na inne i zapisał/odczytał czyjeś rekordy. Oczywiście nie jest to jedyne zabezpieczenia, a bardziej przypuszczam takie utrudnienie dla crackerów, aby już na wstępie mili problem w ustaleniu id rekordu, który chcieliby rozpracować.
I teraz pytanie - jak takie id alfanumeryczne ma się do wydajności mysql? Jest duża różnica między id numerycznym a alfanumerycznym np. w zapytaniach typu left join po id, czy np. w wyszukiwaniu rekordów o danych ID itp? Podobny patent chciałbym zastosować również u siebie, bo piszę aplikację, gdzie jest na prawdę spory mix uprawnień i czasami sam się gubię, komu co zablokować w danej akcji. Aplikacja wewnętrzna, więc użytkowników raczej nie podejrzewam o umiejętności hakerskie, ale wiadomo nawet małpa umie podmienić ID w adresie, a tak jak pisałem mix uprawnień jest spory, więc chętnie dodałbym taki dodatkowy element zabezpieczający. |
|
|
|
![]() |
Post
#2
|
|
|
Grupa: Zarejestrowani Postów: 6 476 Pomógł: 1306 Dołączył: 6.08.2006 Skąd: Kraków Ostrzeżenie: (0%)
|
Narzut na dodatkową kolumnę z takim statystycznie unikalnym alfanumerycznym identyfikatorem jest naprawdę niewielki. Zaś klasyczna kolumna numeryczna ma nieco zalet:
1. Wydajność - nie potrzeba wielomilionowych tabel by to odczuć - wystarczy kilka JOIN-ów i już może to być zauważalne. 2. Lepsze wsparcie ze strony wszelakich narzędzi, szczególnie w przypadku gdy mamy do czynienia z kluczami złożonymi. Niestety często słabo radzą one sobie z niestandardowymi rozwiązaniami. 3. Mniejszy rozmiar danych i gwarancja unikalności - o ile drugi punkt w praktyce nie jest żadnym zmartwieniem o tyle pierwszy już przy przesyle nawet relatywnie niewielkich danych może być odczuwalny. 4. Nie masz co się przejmować "duplikowaniem" danych bo użycie alfanumerycznych, długich ciągów będzie miało dużo większy narzut niż takie "powielenie" danych - w cudzysłowie, bo nie jest to dublowanie danych - id i token mają inne przeznaczenia i wykorzystanie. |
|
|
|
athabus Indeks alfanumeryczny a wydajność 27.01.2016, 15:42:46
Pyton_000 A nie prościej zabezpieczyć to od strony aplikacji... 27.01.2016, 15:59:19
athabus Pewnie, że warto, ale wszystkich ewentualności nie... 27.01.2016, 16:18:15
Pyton_000 Tu masz ciekawą dyskusję.
http://stackoverflow.co... 27.01.2016, 16:33:51
athabus O dzięki - chyba wszystko jasne. 27.01.2016, 17:13:41
Crozin Jeżeli chodzi o aspekt zabezpieczeń... jakiś dodat... 27.01.2016, 17:42:17
athabus Ale co za tym przemawia? - wg. informacji z podlin... 27.01.2016, 18:09:56
redeemer Cytat... Takie dodatkowe zabezpieczenie jest o tyl... 27.01.2016, 18:24:56
athabus @reedemer - zgodzę się, że jako jedyny element zab... 27.01.2016, 18:40:01
Pyton_000 Jeśli chodzi o kolizję to polecam zastosowanie UUI... 27.01.2016, 21:10:20
Crozin @Pyton_000: UUID/GUID nigdy nie daje gwarancji uni... 27.01.2016, 21:32:35
Pyton_000 Na tyle małe że można założyć że jest unikalne.
C... 27.01.2016, 21:35:37 ![]() ![]() |
|
Aktualny czas: 29.12.2025 - 16:54 |