Un utente ha chiesto
Categoria: Localhost Installs di WordPress
Domanda: WP ignora .htaccess ErrorDocument 401

Ho creato una directory protetta utilizzando cPanel. La posizione è / files / members
cPanel ha creato /files/members/.htaccess come segue:

# ——————————————————————- cp: ppd
# Sezione gestita da cPanel: Directory protette da password -cp: ppd
# – Non modificare questa sezione del file htaccess! -cp: ppd
# ———————————————————————- cp: ppd
AuthType Basic
AuthName “Solo membri”
AuthUserFile “/home/cnr/.htpasswds/public_html/files/members/passwd”
Richiedi un utente valido
# ———————————————————————- cp: ppd
# Fine sezione gestita da cPanel: Directory protette da password -cp: ppd
# —————————————————————- cp: ppd

Piastra caldaia possibile. Per quelli con esperienza qui, sai che l’accesso a questa directory tramite l’URL diretto (mywebsite.com/files/members, dove WordPress 5.6.2 è installato alla radice) si traduce in un confuso errore 404 -page not found (anche se l’errore è 401 – autorizzazione richiesta), invece del popup delle credenziali di accesso alla directory desiderato.

La soluzione standard consiste nell’aggiungere “ErrorDocument 401 /401.html” e facoltativamente “ErrorDocument 403 /401.html” nel file root WP .htaccess PRIMA della sezione “# BEGIN WordPress”. Quello che ho fatto, oltre a creare il file 401.html, posizionandolo alla radice.

Indovina un po? WP IGNORA questo e continua a restituire 404. No, non ho abilitato il caching. Le modifiche a .htaccess vengono applicate immediatamente quando la pagina si aggiorna (ho provato con altre opzioni / comandi / regole per confermare).

La sintassi .htaccess è cambiata negli ultimi 2 anni rendendo il metodo ErrorDocument sopra non valido o WP ha aggiunto qualcosa che devo gestire nei parametri che vengono trascurati?

Secondo tutti i risultati di ricerca di Google, l’aggiunta di ErrorDocument alla radice .htaccess ha corretto i 404 di TUTTI gli altri su directory protette, ma NON IO !! Qualsiasi informazione / aiuto possibile è gentilmente apprezzato.

Ho anche aggiunto “Opzioni + Indice” in “# END WordPress” per consentire la visualizzazione di un indice di file per qualsiasi directory che non contiene un file di intercettazione index.php di protezione. Non vedo come questo possa far sì che WP “ignori” ErrorDocument.

Grazie.

  • (@gappiah)

    TL; DR: Non ha nulla a che fare con WordPress, ma le stranezze di cPanel insieme al tuo file di errore e al percorso del documento. Soluzione semplice: assicurati di avere un file 401.shtml file nella tua cartella public_html, anche uno vuoto andrà bene. Nota l’estensione del file: .shtml, non .html. Non è nemmeno necessario aggiungere la direttiva errorDocument personalizzata, ma se ne aggiungi una, è meglio che sia corretto: usa l’estensione file corretta e il percorso completo del file del server.

    E ora la mia lunga spiegazione originale (sentiti libero di saltare 😀)

    Spesso le nostre supposizioni non verificate possono portarci nella direzione sbagliata.

    WordPress non è un server web e non può elaborare alcuna regola .htaccess. Il tuo server web Apache lo fa. WordPress aggiunge solo le proprie regole nei file .htaccess affinché il server Web Apache possa elaborarle.

    Se le tue regole .htacess personalizzate vengono ignorate, il tuo server web Apache le ignora, non WordPress. Perché, ancora una volta, non c’è nulla che WordPress possa fare con queste regole … perché sono regole del server web Apache.

    E il tuo server web ignorerebbe la direttiva per una buona ragione: è sbagliata.

    Per quelli con esperienza qui, sai che l’accesso a questa directory tramite l’URL diretto (mywebsite.com/files/members, dove WordPress 5.6.2 è installato alla radice) si traduce in un confuso errore 404 -page not found (anche se l’errore è 401 – autorizzazione richiesta), invece del popup delle credenziali di accesso alla directory desiderato.

    Ho appena distribuito un nuovo server WHM / cPanel solo per testare cosa sta succedendo qui.

    Dal mio test veloce, sembra che quello che sta succedendo qui abbia senso, come spiegato di seguito:

    Dopo l’ispezione dei log del server, sembra che Apache invii inizialmente il codice di risposta 401 previsto. Ma in qualche modo (e non ho davvero capito perché questo sta accadendo) il server non è in grado di visualizzare la pagina del documento di errore 401 a livello di server, il che si traduce nella restituzione di un codice di risposta 404 … che WordPress supporta e visualizza la sua pagina 404.

    Quindi WordPress visualizza la pagina di errore 404 del tuo tema perché il server (Apache) restituisce una risposta HTTP 404. Anche in questo caso, WordPress stesso non può elaborare il .htaccess direttive in alcun modo.

    Nel mio caso, la soluzione era semplicemente creare uno spazio vuoto 401.shtml file nell’account cPanel public_html cartella. Notare che l’estensione del file è .shtml.html non funziona. Puoi creare questo file manualmente o, preferibilmente, utilizzare la funzione “PAGINE DI ERRORE” di cPanel per generare il file automaticamente.

    Questo sembra essere un problema specifico di cPanel / WHM … poiché ho testato le directory protette su un VPS personalizzato correttamente configurato (nessun pannello di controllo) … e il server ha restituito il codice di risposta 401, l’URL ha mostrato il pop-up di autenticazione HTTP nel browser e, quando viene annullato, viene visualizzata la pagina del documento di errore 401 configurato.

    In bocca al lupo!

    (@crusione)

    Grazie per la spiegazione. Ho capito che WP non si occupa di .htaccess. Sono stato impreciso nel dire che ha ignorato le direttive sull’errore. Ho apportato le modifiche che hai detto (cambiato 401.html in / public_html in 401.shtml e cancellato ErrorDocument 401 e 403 da root .htaccess). Apache invia sempre un 404 per l’URL diretto alla cartella protetta.

    Ecco il .htaccess completo:

    Opzioni + indice
    RewriteOptions inherit

    # AVVIA WordPress
    # Le direttive (righe) tra “BEGIN WordPress” e “END WordPress” sono
    # generato dinamicamente e dovrebbe essere modificato solo tramite i filtri di WordPress.
    # Qualsiasi modifica delle direttive tra questi marcatori verrà sovrascritta.

    RewriteEngine On
    RewriteRule. * – [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

    RewriteBase /
    RewriteRule ^ index .php $ – [L]

    RewriteCond% {REQUEST_FILENAME}! -F
    RewriteCond% {REQUEST_FILENAME}! -D
    RewriteRule. /index.php [L]

    # FINE WordPress

    # INIZIA le direttive PHP ini generate da cPanel, non modificare
    # La modifica manuale di questo file potrebbe causare un comportamento imprevisto.
    # Per apportare modifiche a questo file, usa l’editor cPanel MultiPHP INI (Home >> Software >> MultiPHP INI Editor)
    # Per ulteriori informazioni, leggi la nostra documentazione (https://go.cpanel.net/EA4ModifyINI)

    php_value date.timezone “Stati Uniti / Oriente”
    php_flag display_errors disabilitato
    php_value max_execution_time 30
    php_value max_input_time 60
    php_value max_input_vars 1000
    php_value memory_limit 64M
    php_value post_max_size 505M
    php_value session.gc_maxlifetime 1440
    php_value session.save_path “/ var / cpanel / php / sessions / ea-php74”
    php_value upload_max_filesize 500M
    php_flag zlib.output_compression Disabilitato

    php_value date.timezone “Stati Uniti / Oriente”
    php_flag display_errors disabilitato
    php_value max_execution_time 30
    php_value max_input_time 60
    php_value max_input_vars 1000
    php_value memory_limit 64M
    php_value post_max_size 505M
    php_value session.gc_maxlifetime 1440
    php_value session.save_path “/ var / cpanel / php / sessions / ea-php74”
    php_value upload_max_filesize 500M
    php_flag zlib.output_compression Disabilitato

    # END PHP ini direttive generate da cPanel, non modificare

    # php – AVVIA il gestore generato da cPanel, non modificare
    # Imposta il pacchetto “ea-php74” come linguaggio di programmazione “PHP” predefinito.

    Applicazione AddHandler / x-httpd-ea-php74 .php .php7 .phtml

    # php – FINE del manager generato da cPanel, non modificare

    C’è qualcosa che dovrei controllare in WHM? Questo è un account VPS con Liquidweb.

    (@diondesigns)

    Poiché il tuo problema è chiaramente correlato a cPanel, ti consiglio caldamente di andare a https://forums.cpanel.net e posta lì la tua domanda.

    Per quello che vale, dato che hai un VPS che utilizza cPanel, il posto migliore per il tuo ErrorDocument direttive è in a <Directory> blocco in a pre_virtualhost_global.conf deporre. Se non sai cosa sia questo file, dai un’occhiata alla pagina principale httpd.conf file … è documentato lì. Sarà necessario riavviare Apache per attivare le modifiche alla configurazione del sistema. (Se hai un VPS gestito su LiquidWeb, fallo fare per te.)

    (@crusione)

    Il supporto di Liquidweb non ha riscontrato problemi di configurazione di Apache o cPanel. Hanno cancellato la mia directory cPanel protetta (cancellato .htaccess nella directory protetta) e ne hanno creato uno nuovo tramite cPanel. Stessi comandi / formato esatti di quello creato da cPanel per me. TRANNE, hanno aggiunto “ErrorDocument 401 /401.html” come prima riga (NON SHTML come hai indicato era l’estensione file richiesta). Hanno anche creato un nuovo utente e una nuova password. Non hanno raggiunto la radice .htaccess, che ha ancora la vecchia direttiva “ErrorDocument 401 /401.shtml” che ho aggiunto nella risposta sopra.

    Per qualche ragione QUESTA “soluzione” ha funzionato (non più di 404 per WP da gestire).

    Stranamente, ho fatto la stessa identica cosa (aggiungendo “ErrorDocument 401 /401.html” al file .htaccess nella directory protetta, PRIMA di postare qui. Perché ha funzionato per loro e non per me … ).

    (@diondesigns)

    Posso quasi garantire che LiquidWeb ha cambiato la tua configurazione globale di Apache senza dirtelo. Questo è il motivo per cui le cose hanno funzionato “come per magia” quando hanno apportato le stesse modifiche che hai fatto tu. (Questa è la procedura operativa standard in molte / la maggior parte delle società di hosting VPS gestite.)

Hai risolto il tuo problema?

0 / 0

Lascia un commento 0

Il tuo indirizzo email non sarà pubblicato. Required fields are marked *