Ho appena trascorso una serata divertente apportando alcune modifiche a uno dei nostri server Windows, l'aggiornamento prevedeva l'aggiunta di alcune nuove fantastiche funzionalità al nostro pannello di controllo (DotNetPanel) e anche per assicurarsi che il server fosse completamente aggiornato.

L'aggiornamento è partito alla grande, installa il software e il riavvio obbligatorio che MS ti fa fare (sempre un momento emozionante). La macchina è tornata e inizialmente sembrava tutto a posto. Sono andato a testare alcuni dei siti sul server e tutto sembrava a posto finché non ho provato il mio blog e mi sono reso conto che per qualche motivo i permalink non funzionavano correttamente! un rapido controllo di alcuni altri blog e lo stesso accordo, i permalink basati su PATHINFO (collegamenti che includono un percorso /index.php/ in) sono stati FUBARed solo restituendo un errore 404. :(

Il primo controllo è stato il permesso dei file in quanto questa può essere una causa comune di errori PHP, niente di ciò che ho provato ha fatto la differenza, il prossimo è stato il controllo della configurazione di PHP.ini, no non aiuta, il prossimo è stato IIS, niente di sbagliato lì, quindi era il mio browser , forse qualcosa non va con i cookie o la cache…. no. Ero perplesso ... .. molti controlli e ricontrolli in seguito e ancora non riuscivo a capire perché i permalink non funzionassero ... Alcune ore dopo e ho quasi rinunciato, un rapporto di un sito Magento che aveva problemi ad accedere all'amministratore (Sì, hai sentito che Magento funziona correttamente sul nostro server Windows: 0), o almeno era stato aggiornato fino a poche ore fa ).

È andato a controllare perché e ha notato una somiglianza con il problema di WordPress, l'amministratore di Magento utilizza anche URL con /index.php/ e sebbene fossero stati reindirizzati alla home page piuttosto che mostrare un 404, era ancora una coincidenza ...

Ora, questi siti erano in processi e percorsi IIS completamente separati, quindi le autorizzazioni e IIS sembravano un vicolo cieco, quindi non ero ancora più saggio se non sapendo che si trattava di un problema a livello di server non localizzato in un percorso specifico.

Dopo più ore di grattacapi ho deciso di controllare le nuove funzionalità che avevo installato per vedere se qualcosa lì poteva aver causato un problema così strano, con l'aggiornamento abbiamo ottenuto alcuni nuovi strumenti di sicurezza, uno di questi è il nuovo strumento URLSCAN di Microsoft che ha numerosi vantaggi in termini di sicurezza, mi è venuto in mente che forse questo aveva qualcosa a che fare con il problema, in genere ti aspetteresti che queste cose vengano installate disabilitate finché non sei pronto per abilitarle.

Bene, per tagliare una lunga esperienza faticosa breve URLSCAN è stato abilitato e ha una bella impostazione abilitata (o meglio impostata per disabilitare) di default chiamata "AllowDotInPath"…. Il nome dice tutto davvero e ha lo scopo di bloccare qualsiasi URL che ha un punto nel percorso dell'URL, l'ho impostato su 1 "AllowDotInPath = 1" e ho salvato l'INI e improvvisamente tutti i siti WordPress e Magento sono tornati a vita. Grazie per quella SM….

Quindi, dopo tutto, era una soluzione così semplice anche se meno ovvia.

Ad ogni modo, sto scrivendo questo per aiutare altri amministratori poiché sono sicuro che questo influenzerà molte altre persone che utilizzano questo tipo di tecniche di riscrittura degli URL basate su PHP PATHINFO su IIS.



Mercoledì, Luglio 7, 2010

« Indietro