14 komentarzy

1. 

   Tadesz on 2015-05-01 at 14:23

   Podobnie jest z wtyczką do płatności PayU. Wyłaczenie HTTPS w Cloudflare rozwiązuje błędy.

   Reply
   • 

     Patryk on 2015-05-01 at 14:33

     Dzięki za informacje – pewnie przyda się komuś… Choć by być bardziej precyzyjnym – nie namawiam(y) nikogo do rezygnacji z HTTPS, czy Cloudflare na stronie, a tylko zwracam(y) uwagę na ten jeden drobny element konfiguracji, który może przysporzyć ew problemów… :-)

2. 

   jurasjo on 2017-01-07 at 18:51

   Używam Wp + Woocommerece + Woocommerce Tpay i CF.

   Płatności idą bez problemu jednak występuje problem z „Niepoprawną odpowiedzią serwera”.

   Otrzymujesz tą automatyczną wiadomość ponieważ Twój serwer pod adresem: http://xyz/?wc-api=WC_Gateway_Transferuj
   nie daje poprawnej odpowiedzi na wysyłane przez system Transferuj.pl powiadomienia dla transakcji ’.XXXXXX’.
   Poprawna odpowiedź to: TRUE
   Natomiast odpowiedź Państwa serwera to:

   Jakieś pomysły jak to poprawić?

   W CF używam SSL (strict) i wyłączyłem „Automatic HTTPS Rewrites”

   Reply
   • 

     Patryk on 2017-01-08 at 08:13

     Tak „na sucho” (bez bezpośrednio dostępu do sklepu/serwera) to nie bardzo – w takich sytuacjach warto spojrzeć w logi (ew. wcześniej włączyć logowanie), i przetestować różne ustawienia (z CF, bez CF, itp.).

3. 

   jurasjo on 2017-01-08 at 09:17

   W dokumentacji tpay znalazłem info, że nie wspierają przekierowań 301 i 302. Z tego co widzę to CF robi właśnie takie przekierowanie.

   Tylko, że strona może być dostępna po http:// i https://(301) a zwrot nie idzie ani na to ani na to. Zobaczę co napiszą z CF i tpay i ewentualnie dam znać.

   Reply
   • 

     Patryk on 2017-01-08 at 10:14

     Nie wiem jaką masz konfiguracje, ja zazwyczaj robię tak, że sklep działa po SSL/HTTPS (kiedyś tylko niektóre strony, teraz zazwyczaj całość), do tego w CF mam „strict” i to działa (jest po stronie serwera wymuszone ew. przekierowanie ruchu z HTTP na HTTPS, oraz z http://www.domena na samą domenę, ale to tylko jakby ktoś się uparł na wejście przez „www” lub po HTTP).

     Ale testowałem tpay w konfiguracji sklep po HTTP i tylko „strony z danymi wrażliwymi” po HTTPS, i było OK.

     Tak jak napisałem wcześniej – trochę ciężko mi coś konkretnego doradzić, bo to takie… teoretyzowanie, jednak jak ma się fizyczny dostęp „do problemu”, to jest trochę łatwiej – może nie tyle łatwiej, że mniejszy problem, ale łatwiej szukać rozwiązania :-)

4. 

   jurasjo on 2017-01-08 at 11:21

   Dzięki za dodatkowe wskazówki. Czy po stronie tpay(w panelu na ich stronie) trzeba ewentualnie na coś zwrócić uwagę?

   Reply
   • 

     Patryk on 2017-01-08 at 11:28

     Wiesz co, nie wiem… ale chyba nie, bo ostatnio np. tylko aktywowałem bramkę, a ustawienia w tpay robił już klient, i wierz mi, mało techniczny, a wszystko działa, więc raczej nie ma tu nic nietypowego (oczywiście poz ustawieniem autoryzacji). Jedyny problem jaki miałem, to właśnie opisany powyżej (wpis).

     W każdym razie, jakby okazało się, że jest to jakaś kwestia konfiguracji „czegoś”, to fajnie, jakbyś dał znać, bo może komuś też się jeszcze przyda :-)

5. 

   miłko on 2017-01-13 at 17:28

   Mam ten sam problem! Płatność przechodzi, ale dostaje wiadomość zwrotną o niepoprawnej odpowiedzi serwera. Na pewno wina w konfiguracji cloudflare, bo tylko to ostatnio zmieniałem :) Page rules /zamowienie* mam wszystko powyłączane, w tym https rewrites. Jakieś pomysły?

   Reply
   • 

     Patryk on 2017-01-13 at 18:45

     Wyłącz „HTTPS Protocol Rewriting” dla całej domeny/całego adresu – bo nie pamiętam teraz jaki tam adres jest zwrotny, i sprawdź czy to będzie działać (zalecam zrobić to z poziomu wtyczki Cloudflare do WordPressa, lub w ustawieniach – globalnie dla domeny). U mnie konfiguracja opisana we wpisie działa, tzn. błąd przestał występować.

   • 

     miłko on 2017-01-23 at 15:46

     Próbowałem na wszystkie sposoby, nic nie działało. Zdaje się, że dopiero zainstalowanie wtyczki cloudflare na WP i tam ponowne wyłączenie „Automatic HTTPS Rewrites” podziałało, pomimo, że na koncie cloudflare wszystko powyłączane. Może komuś się przyda taka podpowiedź :)
     Dzięki za artykuł!

   • 

     Patryk on 2017-01-27 at 06:57

     Niby wtyczka pozwala tylko na modyfikację ustawień w usłudze Cloudflare (na ich serwerach), to ja właśnie nie tylko z powodu wygody (np. szybka aktywacja trybu dewelopera) ją instaluje na każdej stronie na WordPressie schowanej za tą usługą.

6. 

   Wojciech on 2017-01-31 at 12:46

   Miałem ten sam problem, coś jest nie tak ze sprawdzeniem adresu IP serwera wysyłającego odpowiedź w funkcji gateway_communication() co jakiś czas ulega zmianie, o czym nie ma wzmianki w dokumentacji.
   Ja wywaliłem sprawdzenie IP, resztę parametrów sprawdza kolejna funkcja verify_payment_response() (numer zamówienia, checksum, itd ) więc wielkiego zagrożenia bezpieczeństwa to nie powoduje

   function gateway_communication() {
   if ( !empty($_POST) ) {
          $this->verify_payment_response();
   } else if (isset($_GET['order_id'])) {
          $this->send_payment_data($_GET['order_id']);
   }
   exit;
   }

   Reply
   • 

     Patryk on 2017-01-31 at 13:56

     Dzięki za dość techniczny i zarazem konkretny komentarz. Zgłaszałeś może to do Transferuj.pl/tpay.com, by mogli się temu przyjrzeć i skorygować (ewentualny) błąd? Bo w tej chwili wyłączenie „HTTPS Protocol Rewriting” w ustawieniach wtyczki Cloudflare wydaje się lepszym rozwiązaniem (zwłaszcza, jak cały sklep działa po HTTPS) niż bezpośrednia edycja plików wtyczki, bo te zostaną przywrócone po aktualizacji i problem prawdopodobnie pojawi się znowu.