Międzynarodowy Bank Pollinu: API

[Benjamin]

Ostatnia wiadomość z poprzedniej strony wątku

Prawie jak BLIK, jednak brak tu potwierdzenia kwoty, jaka jest ściągana z naszego konta.
Nie wiemy czy aplikacja na pewno ściągnie nam zadeklarowana kwotę, która może być różna od tej w kodzie.

Nie do końca rozumiem, ale z tego co już zdążyłem przetestować - zwracany JSON kwota jest podawana w walucie docelowej. (Przelew wykonałem z rachunku edelwajskiego na rachunek leocki w walucie mikro, json zwrócił waluta LCP oraz odpowiednia kwota). Dodatkowo, userowi możemy wyświetlic potwierdzenie przelewu:

Kod: Zaznacz cały

https://bank.leocja.org/potwierdzenie/$json['dane']['operacja']

[Helwetyk Romański]

Prawie jak BLIK, jednak brak tu potwierdzenia kwoty, jaka jest ściągana z naszego konta. Nie wiemy czy aplikacja na pewno ściągnie nam zadeklarowana kwotę, która może być różna od tej w kodzie.

Tak. To taki BLIK, tyle że gorszy. Jak jeszcze moduł potwierdzania płatności po stronie banku mógłbym (bardzo niechętnie) ogarnąć, to niespecjalnie wysoko oceniam szanse tego, że twórcy aplikacji będą dorabiali moduły sprawdzania, czy transakcje faktycznie przeszły.

Obecny mechanizm autoryzacji w Księstwie Sarmacji — również niewymagający potwierdzania kwoty — funkcjonuje od bodajże 2013 roku i jestem w stanie przywołać tylko jeden sporny przypadek. Na szczęście, nie projektujemy tutaj systemu dla milionów użytkowników i dziesiątek milionów transakcji. Właściciel klucza API jest znany, wszystkie operacje są jawne i odwracalne.

Dlatego na tu i teraz przyjąłem założenie, że w razie potrzeby spory będzie się załatwiać drogą administracyjną.

Nie do końca rozumiem, ale z tego co już zdążyłem przetestować — zwracany JSON kwota jest podawana w walucie docelowej.

Tak jest. Czy istnieje potrzeba, aby zwracało także kwotę i walutę źródłową?

Dodatkowo, userowi możemy wyświetlic potwierdzenie przelewu […]

No, możemy — ale przecież nie po stronie API? Po to zwraca identyfikator operacji, żeby zintegrowany system wyświetlił odsyłacz lub obrazek, jeżeli twórca uzna to za słuszne.

[Sheldon Anszlus Lovelace]

Czyli wszystko oparte na wzajemnym zaufaniu, ale ma Namiestnik rację, szkoda czasu na coś, co nie jest potrzebne.
Nikt nie będzie sobie niszczył reputacji, próbując oszukać kogoś na jednorazowej transakcji.

[Helwetyk Romański]

Czyli wszystko oparte na wzajemnym zaufaniu, ale ma Namiestnik rację, szkoda czasu na coś, co nie jest potrzebne.
Nikt nie będzie sobie niszczył reputacji, próbując oszukać kogoś na jednorazowej transakcji.

Jeżeli pojawi się potrzeba to, oczywiście, będzie trzeba przykręcić śrubę. Intuicja mi jednak podpowiada, że „uczciwe” pomyłki w kodzie, które twórcy sami naprawią, są o rząd, jeżeli nie o dwa rzędy, wielkości bardziej prawdopodobne od świadomych prób oszustwa.

[Ignats ik Ruth]

Nikt nie będzie sobie niszczył reputacji, próbując oszukać kogoś na jednorazowej transakcji.

Czy nikt, to bym się nie założył, ale też nie spodziewałbym się, że zdarzy się to częściej niż raz czy może dwa na dekadę. ;p

[Benjamin]

Dałoby radę zrobić tak, żeby kod MYK nie był równy 123 (czy nawet 111, 222, 333...)? Testowałem sobie, a później sam taki kod uzyskałem, więc komuś mogłem piniążki zabrać przez przypadek...

[Helwetyk Romański]

O ile się nigdzie nie pomyliłem w kodzie (ważne zastrzeżenie), to nie da się ani wygenerować już istniejącego i ważnego kodu, ani użyć ponownie wykorzystanego kodu — jest usuwany po użyciu, ani użyć kodu, którego ważność wygasła. To nie jest tak, że obecnie w banku ktoś gdzieś ma 111, 123 etc. Szanse są takie same, jak przy każdej innej kombinacji cyfr.

Nie wykluczam jednak zwiększenia długości kodu na wszelki wypadek. Dam wtedy znać na okoliczność konieczności zmiany inputów oraz ich walidacji.

[Anastasia Windsachen]

A można było 6 cyfr...

[Helwetyk Romański]

A można było 6 cyfr...

Będzie (choć to głównie security theatre). A myślałem, że to ja tu mam nerwicę…

[Anastasia Windsachen]

A można było 6 cyfr...

Będzie (choć to głównie security theatre). A myślałem, że to ja tu mam nerwicę…

Ale widzicie - z 3 osoby powiedziały, że muszą być lepsze zabezpieczenia. Nie znam się na matmie (zdałam na jakieś 32%), ale wiem, że 6 cyfr zapewnia o wiele więcej kombinacji niż 3...

[Helwetyk Romański]

Nie znam się na matmie (zdałam na jakieś 32%), ale wiem, że 6 cyfr zapewnia o wiele więcej kombinacji niż 3...

To, oczywiście, prawda. Rzecz w tym, że przez 99,99% czasu liczba ważnych kodów wynosi zero i wzrasta do jednego w momencie, gdy dany użytkownik sobie odpali stronę generowania MYK-a dla konkretnego rachunku. To nie jest system dla milionów ani nawet tysięcy jednoczesnych użytkowników (niestety…).