[michalkortas]

Zamiast stosować przewidywalne, inkrementowane identyfikatory w tabelach bazy danych zaleca się często, ze względów bezpieczeństwa, używanie tzw. #uuid, czyli unikalnych identyfikatorów tekstowych. Taki klucz w tabeli maksymalnie niweluje skuteczność ataków ☠️ polegających na kolejnym odpytywaniu URL, zwiększając jedynie parametr ID o jeden.

Na przykładzie #php i #laravel zademonstruję sposób na użycie UUID.

A czy Ty używasz UUID w swoim projekcie?

⛔️ Widzisz jakieś wady?
✅ A może same zalety?

https://webroad.pl/php/7905-uuid-zamiast-auto-increment-id-w-laravelu
#webroad #bazydanych

[michalkortas]

Link do wpisu na blogu: https://webroad.pl/php/7905-uuid-zamiast-auto-increment-id-w-laravelu

[Hipodups]

@michalkortas: u mnie w aktualnym projekcie to snadars, obiekty mają id i hashe. Wszystko co wypluwane poza system jest po hashu. wewnatrz po id , bo tak czasem łatwiej. Takie podejście tez jest wygodne

[michalkortas]

@Hipodups: dobra opcja z tym lokalnym id.

[Serghio]

@michalkortas: Właściwie nie wydaje Wam się, nie macie wrażenia, że to tylko obejście pewnego problemu inną niekoniecznie słuszną drogą?

To tak jakby każda szafka w szatni na basenie była innego koloru i zamiast numeracji od 1 do 100, miały różne dziwne symbole. Natomiast Wy posiadajcie tylko jeden klucz do różowej szafki. Możecie otworzyć tylko jedną, ale próbujecie również pozostałe.

Rozumiem, że efektem stosowania UUID może być sytuacja, gdy zamiast URL:

https://sklepinternetowy.pl/order/view/1001

[szczesc_borze]

@michalkortas: Fajnie, że zapominasz wspomnieć, dlaczego nikt normalny tego nie używa jako klucza głównego.
Jest z tym więcej problemów niż pożytku. Używam jedynie do jakiegoś API i tylko tam, gdzie istnieje ryzyko takiego ataku o jakim mówisz. Serio wkurza mnie bezmyślne wdrażanie każdego pomysłu jaki przyjdzie do głowy googlowi, czy facebookowi, bo zdaje się, że większość dzisiejszego oprogramowania czerpie bezrefleksyjnie pełnymi garsciami własnie od nich.
Więc pakujcie kochani UUID wszędzie gdzie

[Jurigag]

@Serghio: zyskujesz jeszcze jedną rzecz - czysto biznesową - nie mówisz użytkownikom twojej strony ile masz zrealizowanych zamówień

[Jurigag]

@michalkortas: wcześniej w ogóle nie korzystałem, active record, model sam się robił i nie przejmowałem sie własnoręcznie generowanym id, w obecnej firmie tylko uuid wszędzie(poza drobnymi wyjątkami)

[Serghio]

@Jurigag tylko przy odpowiednim zabezpieczeniu ACL, czy RBAC, przy odpowiedzi na żądanie np. przy URL "order/128" lub "order/4368" lub "order/9999999" powinna być zawsze taka sama odpowiedź nie potwierdzająca, że dane zamówienie istnieje, natomiast dla konkretnego użytkownika, który dostał i ma prawa do zamówienia np. o ID 4587, nadal nie będzie wiedział odkąd zaczyna się inkrementacja, a także czy ewentualnie kolejny numer ma oznaczać zrealizowane zamówienie, czy tylko np. koszyk, czy jeszcze coś

[Jurigag]

@Serghio: pytanie właśnie co będziesz zwracać, bo zgodnie z zasadami rest jakieś 403 albo 401 co wtedy wskazuje na istnienie danego resourcea, a 404 nie będzie do końca poprawne

[szczesc_borze]

@Jurigag: Mając ACL rzucasz access denied niezależnie od tego, czy resource istnieje i pytający nie ma uprawnień, czy po prostu resource nie istnieje. UUID to niskopoziomowe rozwiązanie problemu wysokopoziomowego okupione problemami.

[G.....r]

@Serghio: @Serghio: Mam doświadczenie w projekcie gdzie poprzednik zaczął stosować uuid oraz id (id był podstawowy)

uuid wypływało zawsze na zewnątrz, do jakiegoś get itd.
obowiązywała jednocześnie zasada aby id nigdy nie było widoczne nigdzie na froncie, id używaliśmy tylko do komunikacji pomiędzy wywołaniami na backendzie.

[Serghio]

@Jurigag: myślałem bardziej o sytuacji, gdy wyświetlamy po prostu informację na stronie, w przypadku API, to zwracałbym zawsze 403

@Govr: i to właśnie wydaje mi się bardziej słuszne podejście

[lolen]

@michalkortas: robiąc trait do modelu warto skorzystać z bootNazwaTrait oraz initializeNazwaTrait, dzięki temu łatwiej możesz rozszerzać czy nadpisywać. przykład tutaj

[lolen]

@Serghio: @szczesc_borze: ostatnio mi wystarczyła informacja ile zamówień tygodniowo posiada pewna firma gdzie numer zamówienia jest autoincrement, wystarczyło złożyć dwa zamówienia w przeciągu tygodnia i wiedziałem

ps. to może ulid? nie rozwala tak bazy przy insercie