System płatności on-line

[Mion]

Błędy bezpieczeństwa... ale jaką masz funkcjonalność ?

Klient musiał by ręcznie zalogować się do swojego banku ręcznie zdefiniować przelew na Twoje konto wypełniając wszystkie pola a Ty musiał byś non stop sprawdzać stan wszystkich kont bankowych jakie obsługuje Twój system płatniczy a po pojawieniu się płatności informować sklep, że płatność miała miejsce. Bez API bankowego tak by to musiało wyglądać.

I podejrzewam, że przy takim dużym ruchu serwer bankowy by banował IP klienta który wykonuje tylle zadań HTTPS.

[MMP]

> jedyne dodatkowe błędy jeśli chodzi o bezpieczeństwo mogą wynikać z niedoskonałości parsera.

Czyli to o czym pisałem, ale jest to błąd programisty który może wyniknąć przy każdej koncepcji.

Wszystko można zrobić, takie uroki tech(nologi/niki).

---

Klient musiał by ręcznie zalogować się do swojego banku ręcznie zdefiniować przelew na Twoje konto wypełniając wszystkie pola a Ty musiał byś non stop sprawdzać stan wszystkich kont bankowych jakie obsługuje Twój system płatniczy a po pojawieniu się płatności informować sklep, że płatność miała miejsce. Bez API bankowego tak by to musiało wyglądać.

Za każdym razem jak dokonuję płatności przez allpay.pl muszę to zrobić, więc?

---

> Jeśli korzystasz z XML - to niestety - właśnie nie może, jeśli będzie jakikolwiek błąd - parser wychwyci go na etapie przetwarzania dokumentu.

W wypadku XML może, ale to chyba nie jedyny obowiązujący standard podczas projektowania API?

> Ty na prawdę nie wiesz o czym mówisz. Chyba myślisz że parser HTML pisze się w stylu "weź mi numer transakcji" i działa smile.gif

Może się przyda znajomość ... TIDY lub regexpów do analizy poprawności potrzebnej części dokumentu.

> Niektóre banki były chętne nawet do NAPISANIA takiego api jeśli dostaną specyfikację!

Ale co z tego?

[kawa]

Czyli to o czym pisałem, ale jest to błąd programisty który może wyniknąć przy każdej koncepcji.

Tak ale jak już tutaj wiele razy pisano takie rozwiązanie jest bardzo zawodne. Tutaj właśnie wychodzi modny popsuty "XHTML" który tak na prawdę jest HTML-em z dodanym nagłówkiem. Ludzie nie widzą różnicy między stroną HTML a dokumentem XHTML i XML, który własnie jest odpowiednim formatem dla implementacji takich systemów.

Wszystko można zrobić, takie uroki tech(nologi/niki).

To żeby przybliżyć ci, co tak na prawdę chcesz zrobić to pomyśl że taki system implementujesz w ten sposób:

codziennie dostajesz wyciągi z banku, puszczasz to na OCR-a w wordzie a skrypt w Visual Basic uaktualnia dane w bazie

[Mion]

Za każdym razem jak dokonuję płatności przez allpay.pl muszę to zrobić, więc?

No fakt np. w mBanku musisz się logować, ale na stronie bankowej masz już zdefiniowaną płatność nie musisz sam jej definiować gdzie o błędy łatwo np. jak chodzi o tytuł wpłaty. To robi własnie system pośredniczący...

[MMP]

Tutaj właśnie wychodzi modny popsuty "XHTML" który tak na prawdę jest HTML-em z dodanym nagłówkiem. Ludzie nie widzą różnicy między stroną HTML a dokumentem XHTML i XML, który własnie jest odpowiednim formatem dla implementacji takich systemów.

Akurat znam różnicę pomiędzy XHTML a HTML, ale to i tak nie zmienia sytuacji że można automatycznie wykryć niepoprawną składnię dokumentu i zaalarmować administratora.

To żeby przybliżyć ci, co tak na prawdę chcesz zrobić to pomyśl że taki system implementujesz w ten sposób:

codziennie dostajesz wyciągi z banku, puszczasz to na OCR-a w wordzie a skrypt w Visual Basic uaktualnia dane w bazie biggrin.gif

Tak tylko tutaj wszystko się dzieje automatycznie, pudło

----

ale na stronie bankowej masz już zdefiniowaną płatność nie musisz sam jej definiować gdzie o błędy łatwo np. jak chodzi o tytuł wpłaty. To robi własnie system pośredniczący...

W PKO BP muszę wszystko uzupełnić, a wiem że samo PKO BP udostępnia podobny mechanizm co mBank. Tylko skoro AllPay go nie zaimplementowało to może nie jest idealny.

[kawa]

Akurat znam różnicę pomiędzy XHTML a HTML, ale to i tak nie zmienia sytuacji że można automatycznie wykryć niepoprawną składnię dokumentu i zaalarmować administratora.

Jakiego administratora. OMG, myślisz, że za stronę banku odpowiada jakiś "administrator", który sobie zmienia co mu się akurat ubzdura. Bank nie będzie zmieniał strony która dobrze działa po to, żeby kod lepiej wyglądał bo to jest cała procedura, testy, możliwe że czasowa przerwa w działaniu, etc. Żaden system w którym jest odpowiednio dużo użytkowników nie da się zmienić / poprawiać "od tak sobie".

Tak tylko tutaj wszystko się dzieje automatycznie, pudło

Taaa... strasznie automatycznie. Nawet strony banków musisz ręcznie sprawdzać, żeby ci regexy pasowały

W erze webservisów, SOAP'ów, zapytań REST na prawdę nie można wpaść na nic głupszego niż pisanie systemu rozproszonego opierającego się na parsowaniu HTMLa. Z resztą co ci będę mówił. Jak kiedyś napiszesz to może zrozumiesz

[kawa]

W wypadku XML może, ale to chyba nie jedyny obowiązujący standard podczas projektowania API?

XML który uwzględnia wymagania SOAP to obowiązujący format danych, reprezentacja danych tylko na Unicode. Przy projektowaniu webserwisów nie ma zamienników, dla tego, żeby każdy system mógł z tym współpracować. Tak samo jak w XHTML pomimo tego że wszyscy robią inaczej nie można stosować innej strony kodowej niż unicode. W wielu dziedzinach dąży się do tego, że jest jeden obowiązujący standard którego należy używać.

Może się przyda znajomość ... TIDY lub regexpów do analizy poprawności potrzebnej części dokumentu.

Nie rozumiem po co ci to. Kod staje się nagle niepoprawny... i co z tego, że masz taką wiadomość? Zamykasz kanał płatności dopóki nie napiszesz i nie przetestujesz nowego parsera? Stosowanie TIDY to już w ogóle pomysł z kosmosu.

Poza tym trzeba analizować cały dokument. Jeśli początek będzie uszkodzony to nie wiesz gdzie jest "potrzebna część".

Ale co z tego?

Ano to z tego, że można to zrobić dużo szybciej i tak, żeby działało zawsze a nie w parzyste dni nieparzystego miesiąca.

[MMP]

Jakiego administratora. OMG, myślisz, że za stronę banku odpowiada jakiś "administrator", który sobie zmienia co mu się akurat ubzdura. Bank nie będzie zmieniał strony która dobrze działa po to, żeby kod lepiej wyglądał bo to jest cała procedura, testy, możliwe że czasowa przerwa w działaniu, etc. Żaden system w którym jest odpowiednio dużo użytkowników nie da się zmienić / poprawiać "od tak sobie".

Z łaski swojej przeczytaj jeszcze raz moje zdanie które zacytowałeś, bo to co napisałeś ma się nijak do mojego stwierdzenia.

> Taaa... strasznie automatycznie. Nawet strony banków musisz ręcznie sprawdzać, żeby ci regexy pasowały

A w przypadku API muszę zajrzeć do dokumentacji i zobaczyć przykładowe odpowiedzi serwerów. Dalej pudło.

W erze webservisów, SOAP'ów, zapytań REST na prawdę nie można wpaść na nic głupszego niż pisanie systemu rozproszonego opierającego się na parsowaniu HTMLa.

W erze dostępu do energii słonecznej, wiatrowej dalej 90% jej pochodzi z minerałów kopalnianych.

W wielu dziedzinach dąży się do tego, że jest jeden obowiązujący standard którego należy używać.

Co z tego że się dąży, skoro standardów jest wiele i można ich używać.

> Zamykasz kanał płatności dopóki nie napiszesz i nie przetestujesz nowego parsera

Jeżeli taka zmiana nie będzie zachodzić co 5 sekund, to tak. W czym problem, zmiany nie są nagłe i radykalne zazwyczaj jest to zmiana malutkiej części kodu lub całego wyglądu. Tyle że o pełnej zmianie wyglądu jesteśmy powiadamiani przez banki dużo wcześniej.

> Stosowanie TIDY to już w ogóle pomysł z kosmosu.

Możliwość poruszania się nawet po niepoprawnym, błędnym dokumencie html to pomysł z kosmosu?

> Poza tym trzeba analizować cały dokument. Jeśli początek będzie uszkodzony to nie wiesz gdzie jest "potrzebna część".

Bzdura.

Ano to z tego, że można to zrobić dużo szybciej i tak, żeby działało zawsze a nie w parzyste dni nieparzystego miesiąca.

Ahh, bank przygotuje APi w ciągu jednego dnia, przecież to nie możliwe, w banku są procedury o których wspomniałeś wcześniej(choć bez nawiązania do cytatu)

[kawa]

W ogóle nie rozumiesz o co w tym chodzi.