Non hai ancora un account? Ne puoi creare uno gratuitamente, basta cliccare qui.
come utente registrato avrai vantaggi come downloads gratuiti, possibilità di commentare articoli e intervenire sul forum, in base alle opzioni ed alla configurazione di questo sito.
Sei un webmaster ? Gestisci siti per i tuoi clienti ? Ti servono servizi affidabili per te ed i tuoi clienti ? Stiamo preparando una serie di servizi pensati proprio per gente come te, contatta contatta MAXsos per maggiori informazioni www.maxsos.com
Oggetto: prblemi con pnAPI.php riguardo alla fase di login
Salve,
Sto usando da tempo la vecchia versione 1.0.76... recentemente ho deciso di migrare il tutto (comprensivo di un certo numero di moduli e blocchi custom) alla nuova 1.0.821.
Il pacchetto disponibile in download (as is - senza alcuna modifica), appena installato su una macchina linux con una vecchia redhat (fedora 5) e con apache2, php 5.1.4 e mysql 5.0.22 riporta in automatico all'index ad ogni tentativo di login (compreso il primo). Effettuo i test in genere con Mozilla Firefox (attualmente alla v3.0.3).
La procedura di installazione non fallisce ed il tutto sembra funzionare (anche php/apache non riportano errori nei log). Nelle schermate di installazione non ottengo errori riguardanti permessi, impostazioni in php.ini e altro.
Commentando nella pnVarCleanFromInput le righe che effettuano preg_repace prima della do..while (428-443) il tutto inizia a funzionare senza problemi.
La cosa sembra tra l'altro in linea alle discussioni che ho rintracciato sul forum inglese (http://www.maxdev.com/MDForum-viewtopic-t-7890.phtml), riguardante problemi con la pnSecAuthKey e id di sessione che non matchano, e/o variabili $modules che arrivano nulle dalla pnVarCleanFromInput. A quanto vedo l'effetto è esattamente lo stesso descritto in quel topic, in cui però non ho trovato riposte certe (quella di far tornare true alla pnSecAuthKey mi pare un rimedio peggiore del male).
Visto e considerato che non è mia intenzione omettere le righe in questione in produzione (non è proprio il caso), mi chiedo a cosa possa essere dovuto questo comportamento, in modo da trovare una soluzione asap... probabilmente, visto che vedo dozzine di utenti del forum il cui ultimo problema è la fase di login, si tratta di qualche impostazione nel php.ini e/o nel sistema in uso, ma lo stesso ho potuto osservare effettuando qualche test preliminare su una macchina locale con winXP SP3.
Registrato: 01 Gen 1970
Messaggi: 3425
Località: ValdOrcia
Status: Offline
Inviato:
03 Ott 2008 - 01:23
ciao,
se hai fatto un upgrade del sistema e hai hai un backup del database allora prova a disattivare il modulo MDUsers, elimina e poi dopo aver rigenenrat oil modulo, attivalo.
Ciao
Grazie per la risposta, ma come dicevo il problema si verifica con un installazione ex-novo... database pulito e generato dall'installer.
L'importazione dei dati dal vecchio sistema avverrà solo in seguito, e comunque per maggiore sicurezza preferisco evitare un upgrade ed importare direttamente i contenuti via sql ed operazioni più "manuali".
Non potendo effettuare alcun login, inoltre, a meno di non commentare gli spezzoni che ho indicato nel post precedente, non ho modo di accedere al pannello di amministrazione e attivare/disattivare blocchi e moduli.
In sostanza, non ho fatto un upgrade... ho semplicemente installato da zero, anche per valutare da vicino il carico di lavoro necessario a trasformare i moduli ed i blocchi customizzati, oltre al tema ovviamente, in qualcosa di digeribile dal nuovo sistema.
Cerco di approfondire la questione, grazie in ogni caso per la risposta e per l'interessamento. Spero di riuscire a risolvere in tempi brevi, la cosa è sicuramente una stupidaggine legata al sistema in uso, però non mi è chiaro quale aspetto del sistema (browser compreso - ma per sicurezza ho disabilitato firebug, adblock, greasemonkey, noscript e quante più estensioni "da sviluppatore" possibili) potrebbe influire su una preg_replace, sempre che il problema non sia a monte...
Dovrei aver risolto l'arcano... sulla macchina è presente una versione bundled PCRE piuttosto vecchia (5.0.13 del 2004), probabilmente non compilata con il supporto per UTF-8 e le preg_replace in pnAPI.php invece assumono che questo supporto sia sempre presente.
Spulciando in rete ho trovato diverse menzioni (es:http://framework.zend.com/issues/browse/ZF-1641 dallo Zend framework) sul fatto che in mancanza di tale supporto, la preg_replace ritorna una stringa vuota se nell'espressione regolare si tenta di usare l'unicode (sia con il terminatore u, che con l'utilizzo di \Xnnnn, \p, \P).
Togliendo (temporaneamente per adesso) il terminatore u per l'unicode, tutto riprende a funzionare (la login a sinistra mi manda alla MDUsers_getlogin invece che effettuare correttamente il login - ma questo è un altro problema, probabilmente legato alla sessione più che alle regexp).
Provvederò, eventualmente, ad aggiornare il pcre, ad ogni modo forse è meglio sottolineare questa necessità nei file di installazione (non credo che esistano hoster che non danno supporto utf8, ma per installazioni su server propri, magari in cui webserver e php sono presenti da tempo, forse l'informazione può tornare utile).
MAXs.o.s. è alla ricerca di sviluppatori PHP/MySql esperti MDPro
Vuoi aggiornare e/o mantenere aggiornato il tuo sito e non hai il tempo e/o le competenze per farlo ?
Contattaci, potrai avere servizi professionali fatti su misura per te, numero verde 800 032 883
Sei un webmaster o un rivenditore ? stiamo preparando nuovi prodotti e servizi proprio per te, contatta MAX s.o.s.
MAX s.o.s. Fantasia e dinamicità Italiane, qualità e servizi Canadesi Web Services, hosting ed housing professionali
Realizzazione siti web, portali dinamici, E-commerce, moduli ed addons per portali.
Supporto tecnico 24/24 7/7 - Contratti assistenza e manutenzione -
Galleria con migliaia di temi grafici disponibile.
Volentieri... domani quando posso accedere alla macchina in questione posto la struttura.
Ad ogni modo l'installazione, come ho detto, è avvenuta ex-novo.
Il db non esisteva (è stato creato dall'installer) e il pacchetto è l'ultimo disponibile in download, la struttura di md_session dovrebbe essere quella che si può rintracciare facilmente nei file di installazione del pacchetto in questione.
Per i problemi di redirect alla getlogin (separati come dicevo dal problema delle regexp), la causa è il firebug attivo sotto firefox (credo dipenda dal fatto che se l'analizzatore di rete dell'estensione è attivo, raddoppia le richieste al server e l'effetto è quello di ottenere degli authid già scaduti per la transazione successiva).
Chiedo scusa se non ho aggiunto l'informazione al post, ma una volta risolto mi sono dedicato a tutte le altre cose necessarie alla migrazione e non ho più pensato alla cosa.
Re: Tema: G-Orange.zip
FAQ Forum
Cerca
Gruppi utenti
Profilo
Options forum
Discussioni controllate
Le ultime dal forum
Messaggi privati
Login
