[zajeli-wszystkie-loginy]

Hej Wypoki,
chciałbym żebyście ocenili i ewentualnie poprawili moje rozumowanie w poniższej kwestii.
#programowanie #webdev #php #bezpieczenstwo #security #webdevhelp #pomocy

Tworzę pewien system sieciowy. Jest serwer na którym siedzi cały silnik aplikacji (apache/php). Zasada działania opiera się głownie na wykonywaniu operacji na bazie danych. Jest też frontend bezpośrednio zintegrowany z silnikiem (dla admina/userów). No i tak sobie myślę żeby napisać do tego aplikacje (na Win/Lin). W silniku są klasy przez które przechodzi "ruch" (żądania i odpowiedzi na db) i o ile przez przeglądarkę jest łatwo (ssl/cookies są w automacie) to napisać klienta http (c/pascal) to już trochę dla mnie za dużo roboty, dlatego korzystam z gotowych komponentów. Mam możliwość komunikacji z serwerem przy pomocy GETów. Wymyśliłem żeby napisać jakieś api w php za pomocą którego będzie można napisać w przyszłości wiele innych klientów (na różne systemy w tym tel). Jedyne co mi przychodzi do głowy to takie coś: api.php?token={}&process={}&data={}, gdzie token to jakiś wynik weryfikacji użytkownika, a process i data to wiadomo, przesył danych i co z nimi zrobić. Dane za base64owane w formacie JSON.
Macie jakieś wskazówki?

[pitu-pr]

@zajeli-wszystkie-loginy: Google rest api :)

[f.....u]

@zajeli-wszystkie-loginy: Jeśli klient będzie w javie to pamiętaj o zaciemnieniu kodu odpowiedzialnego za przesyłanie np umieszczając każdy znak urla w tablicy - o dekompilację i o ew. szkodnika nie trudno.

Co do tokena, wydaje mi się że lepszym sposobem będzie przesyłanie id/loginu i jakiegoś fragmentu hasła w hashu np 10 ostatnich znaków. No i postaraj się o httpsa.

[ownadi]

@filipsiu: wut? jeżeli api jest dobrze zaprojektowane to nie ma po co zaciemniać kodu. zresztą komunikację i tak można podsłuchać np. wiresharkiem. pomysł z tokenem również kiepski, powinno to być losowo generowane uuid trzymane w osobnej kolumnie.

[J.....n]

Mam możliwość komunikacji z serwerem przy pomocy GETów.

@zajeli-wszystkie-loginy:
jakbyś miał też POSTy to możesz to oprzeć o REST

[f.....u]

@ownadi: mimo wszystko, osobiście nie lubię wykładać wszystkich kart na stół więc jeśli komuś zależy na zobaczeniu "jak to działa" to wolę by się namęczył i sobie darował niż na łatwiznę wszystko miał jak na tacy

[Jurigag]

@filipsiu: XD a to w innych językach to już nie trzeba ? XD @zajeli-wszystkie-loginy: zrób api i tyle, najlepiej przepisz sobie całą aplikacje na api + frontend(jakiś angular czy inny syf) to sobie wygenerujesz appkę na wszystkie platformy mobilne i peceta kilkoma komendami i tyle

[f.....u]

@Jurigag: javę najłatwiej zdekompilować ( ͡° ͜ʖ ͡°)

[Jurigag]

@filipsiu: c# też bardzo prosto

[Nicarim]

@filipsiu: a wireshark ma w dupie twoją dekompilacje.

[ownadi]

@filipsiu: w większości wypadków api powinno być dobrze udokumentowane, a nie ukrywane, aby ktoś mógł dopisać np. integracje naszej usługi z inną. wszelkie limity powinny być tylko po stronie back-endu.

[Jurigag]

@filipsiu: XD przecież api to api, wpierw wymaga ona zalogowania na serwerze i tyle, a w celu żeby ktoś z takim tokenem jak gdzieś zdobędzie sobie nie wysłał czegokolwiek chce dodajesz dodatkowo sprawdzanie ip i tyle, jakieś zaciemnianie kodu, zabezpieczanie przed jakimiś snifferami i innymi gównami to akurat sztuka dla sztuki bo takie zabezpieczenia i tak są do obejścia