Come debuggare Ubercart e Paypal restando in localhost?

9 contenuti / 0 new
Ultimo contenuto
Come debuggare Ubercart e Paypal restando in localhost?

Sono alle prime armi con Drupal 6.14/Ubercart2.0 e Paypal, o meglio non il primo e l'ultimo ma sicuramete il secondo. Mi accorgo (oggi non era giornata) che smanettando felicemente in localhost, posso passare i miei ordini al sito sandbox Paypal, ma ovviamente da li non si torna, perchè l'URL del mio sito non è conosciuto al di fuori dal mio file di hosts.
E chiaro che posso spostare tutto su un server, ma cosi perdo la possibilità di debugging. C'è un alternativo? E' possibile usare (anche temporaneamente) l'IP del mio connessione al Internet, cioè il risultato di http://www.whatsmyip.org/ per esempio? O c'è qualcos'altro che mi permette di continuare debuggare ma anche ricevere quei IPN da Paypal?

TIA

John

P.S. Non era deciso a creare un forum per Ubercart?

Di nuovo a parlare con me stesso...
Sembra che la risposta è si: http://stackoverflow.com/questions/822902/access-xampp-localhost-from-in...
Non è per Linux. Spero di riuscire lo stesso. Domani faccio una prova, ma devo ricordare il password del mio router...
Questo sito http://downforeveryoneorjustme.com/ dovrebe aiutare controllare se tutto funziona.

Qualcuno l'ha già fatto questo incantesimo per Linux (Ubuntu in particolare)?

John

Più imparo, più dubito.

alla fine dovrebbe poter bastare spiegare al tuo PC quale è il tuo dominio usando i VirtualHost e modificando il file hosts. Alla fine a PayPal (per la sandbox) non interessa il dominio, basta che la tua macchina lo risolva correttamente.

Ciao
Marco
--
My blog
Working at @agavee

In realtà, la mia domanda è molto più generico di solo Ubercart o Paypal...

Scrivo qui una lunga risposta, non per essere pedantico, ma solo per chiarirmi le idee.

mavimo wrote:
alla fine dovrebbe poter bastare spiegare al tuo PC quale è il tuo dominio usando i VirtualHost e modificando il file hosts.

Si, ma non c'entra il dominio per se. Chiamiamolo 'dev.drupalitalia.org', questo si può impostare tramite /etc/hosts e un file di configurazione Apache contenente il VirtualHost
Esempio:
/etc/hosts:
127.0.0.1 dev.drupalitalia.org

Apache:

<VirtualHost *:80>
    ServerName dev.drupalitalia.org
    # ...
</VirtualHost>

A questo punto http://localhost (127.0.0.1) sarà anche http://dev.drupalitalia.org
Ma in realtà per questo particolare discorso, va bene anche http://127.0.0.1 per quanto reguarda il debugging sul mio computer.

mavimo wrote:
Alla fine a PayPal (per la sandbox) non interessa il dominio, basta che la tua macchina lo risolva correttamente.

Non proprio. Finchè lavoro in localhost non ho problemi, o almeno i problemi sono squisitamente miei...

Con Paypal (o un qualsiasi servizio asincrono esterno), il ciclo di sviluppo si estende al mondo esterno in entrambi i sensi (outbound, inbound).

In outbound non ci sono problemi, ma quando Paypal (o uno dei tanti API) vuole rispondere (inbound), allora deve sapere il 'nome' del mio server, che non sarà di sicuro http://localhost. Quindi e lui (Paypal, o un qualunque altro servizio asincrono) che deve risolvere la mia macchina, non l'inverso.

Per essere preciso, hai ragione fino ad un certo punto. Se io contato il servizio, il pacchetto (o pacchetti) di dati vengono mandati con il mio IP esterno, fornito dal mio ISP. Il servizio userà questo IP per mandare una risposta sincrono. Ma se invece il servizio risponderà in modo asyncrono, cioè più tardi, magari minuti o giorni più tardi, allora di solito il servizio richiede un URL alla quale mandare la risposta. Ed è questo il caso di Paypal, che manda un IPN ad un URL, quando (e se) l'utente paga per il prodotto, secondi, minuti o ore dopo che io (cioè il mio programma) ha fatto la richiesta a Paypal.

In questo caso, perchè la risposta arriva alla mia macchina (cioè al mio server Apache, poi a Drupal) dev'essere possibile convertire il dominio di quel URL in un IP, che corrisponde al mio router, che poi passa il pacchetto dati al mio server Apache.

Io credevo che per una macchina con IP dinamico (cioè quello del mio router IP esterno) non era possibile associare un nome di dominio, che ci vuoleva un IP statico. Ma (fortunatamente) non è cosi. La sequenza di cosa da fare (come l'ho capito io) sono le seguente (dal interno al esterno):

  1. Rendere statico l'IP locale della mia macchina, perchè:
  2. Bisogna settare il router a fare port forwarding (porta 80, ma forse anche 443) a questo IP statico inbound
  3. Bisogna convertire l'IP esterno del router (fornito dal ISP) in un nome di dominio, per due motivi; prima perchè quel IP cambia col tempo (è dinamico) e secondo perchè non mi ricordo neanche il mio numero di cellulare...

Esempio:
Se ho un IP statico interno di 192.168.0.123, allora posso vedere il mio server Apache con http://127.0.0.1 o http://192.168.0.123 indifferentemente sulla mia macchina, o con http://192.168.0.123 da un'altra macchina sulla stessa rete (magari un Virtual Machine).
Se supponiamo che il mio IP esterno è (in questo preciso momento) 82.52.184.9 e ho fatto il port forwarding a 192.168.0.123:80, potrei usare l'URL http://82.52.184.9/risposta-IPN da dare a Paypal. Oggi funzionerà, ma magari domani, quando riaccendo il PC e/o il router, avrò un IP esterno diverso, quindi non funzionerà più.

Quindi devo usare un servizio tipo DynaDNS o No-IP per associare un nome di dominio ad un IP che cambia. A questo punto il rischio di non trovare la mia macchina si è ridotto notevolmente, perchè il servizio DNS viene informato del cambio di IP ogni tot minuti (da un daemone sul mio computer). Il rischio non è zero, ma molto, molto ridotto.

Un altro vantaggio è che uno dei miei progetti sarà sempre disponibile 'dal'esterno' quindi posso accendere il mio netbook sotto Windows per testare con IE6/7/8 per esempio.

Tutto quello che devo fare adesso e invocare l'incantesimo corretto per Ubuntu. La mia ricerca mi ha dato i seguenti frutti:
http://www.howtogeek.com/howto/ubuntu/change-ubuntu-server-from-dhcp-to-...
http://davidwinter.me.uk/articles/2007/01/27/switch-to-static-ip-on-ubun...
https://help.ubuntu.com/community/DynamicDNS

E per curiosità:
http://www.opendns.com/

Adesso che ho finito di scrivere questo papiro, meterò tutto alla prova...

John

Più imparo, più dubito.

Bene, ho chiamato un po di rinforzi per questo problema:
http://linuxludus.it/incantesimo-ubuntu-dns-dinamico-cercasi
http://groups.google.com/group/jugtaa/browse_thread/thread/6b013db1f9203...

Ed il risultato è che ... funziona. Non ho avuto il tempo di provare anche debuggare, quello deve aspettare la settimana prossima...

1. Settato /etc/host:

127.0.0.1 xxxxx.kick-ass.com

2. Settato Apache:

<VirtualHost *:80>
  ServerName dev.sandbox
  ServerAlias xxxxx.kick-ass.com
  #...
</VirtualHost>

Il resto ho sistemato usando esclusivamente il router:
Services:     aggiunto apache_http TCP start 80 end 80
LAN IP setup: aggiunto Address Reservation 192.168.0.2 to Big Red eth0 (usando ifconfig per l'indirizzo MAC)
Dynamic DNS:  Check Use a Dynamic DNS service
              Service Provider: www.DynDNS.org              Host name: xxxxx.kick-ass.com
              User name: si c'è
              Password: pure questo c'è

E ho visto nel database il primo risultato da un IPN spedito (wow)

Poi stacco il cavo, e il server non c'è più (tengo delle forbici a
portata di mano per ulteriore sicurezza).

Grazie a tutti.

John

Più imparo, più dubito.

Anche oggi il mio serverino funziona, ma...
Dopo aver eliminato la voce xxxxx.kick-ass.com in hosts, e anche se PHPEclipse funziona in debug pagina per pagina, cioè

  • Pagina prodotto
  • Pagina Cart (carello)
  • Pagina Paypal sandbox
  • Pagina carello completato

Si rifiuta di fare breakpoint sui IPN ricevuti asincronamente. Il breakpoint è in uc_paypal.pages.inc nella funzione function uc_paypal_ipn($order_id = 0) che è il posto giusto perchè vedo i messaggi di watchdog nel db.
Credo che questo è un problema del debugger PHPEclipse, che usa qualche parametro GET (che ovviamente Paypal sandbox non manda) del tipo ?XDEBUG_SESSION_START=ECLIPSE_DBGP&KEY=12583806815313, quindi chiedo se qualcuno è riuscito usando qualche altro IDE...

TIA

John

Più imparo, più dubito.

Il messagio in GET (lXDEBUG_SESSION_START) è di XDebug, che viene inserito all'interno del tuo server apache e serve appunto per il debugging. Puoi anhce evitarlo modificando le impostazioni di XDebug (a condizione che non ci siano più sessioni di debug attive in contemporanea), in questo modo anche se PayPal non invia il parametro il server di debug continua a funzionare.

In alternativa puoi mettere il parametro di GET direttamente nella pagina che deve chiamare paypal quando invia la comunicazione al tuo server, ma attenzione, il session_id di XDebug viene rigenerato ogni volta, quindi ogni volta dovresti andare a modificare la pagina che deve essere richiamata dalla sandbox di paypal.

Per vedere come configurare XDebug senza usare le sessioni dai un occhio a:

In ogni caso non uso eclipse e quindi non saprei aiutarti nella configurazione del tuo IDE.

Ciao
Marco
--
My blog
Working at @agavee

Thank you for that...

mavimo wrote:
Il messagio in GET (lXDEBUG_SESSION_START) è di XDebug, che viene inserito all'interno del tuo server apache e serve appunto per il debugging. Puoi anhce evitarlo modificando le impostazioni di XDebug (a condizione che non ci siano più sessioni di debug attive in contemporanea), in questo modo anche se PayPal non invia il parametro il server di debug continua a funzionare.

Infatti, avrò dovuto dire che PHPEclipse fa cliente al servizio xdebug.

mavimo wrote:
In alternativa puoi mettere il parametro di GET direttamente nella pagina che deve chiamare paypal quando invia la comunicazione al tuo server, ma attenzione, il session_id di XDebug viene rigenerato ogni volta, quindi ogni volta dovresti andare a modificare la pagina che deve essere richiamata dalla sandbox di paypal.

Si, hai ragione - è un pò macchinoso.

mavimo wrote:
Per vedere come configurare XDebug senza usare le sessioni dai un occhio a:

In ogni caso non uso eclipse e quindi non saprei aiutarti nella configurazione del tuo IDE.


Grazie per quello. Ho smanettato un pò, provando xdebug.remote_autostart=1 e aggiungendo xdebug_break() qui e là, ma niente da fare. Comunque sono convinto che è un problema "fra la sedia e la tastiera".

Per il momento continuo con watchdog e print_r(oggetto, TRUE), che funziona abbastanza bene come 'piano B'.

A buon rendere

John

Più imparo, più dubito.

Ti consiglio di usare il modulo devel e quindi la funzione dpm() per debuggare il codice drupal, decisamente più comodo.. se puoi vui cerca in rete "Firebug for Drupal" e vedi se quello che ti esce ti può interessare.

Ciao
Marco
--
My blog
Working at @agavee