Caricamento di style.css e jQuery utilizzando HTTPS

2 lug 2013, 03:55:18
Visualizzazioni: 25K
Voti: 4

Abbiamo diversi ambienti e abbiamo appena iniziato a utilizzare WordPress (Dev, QA, Pre-prod, prod ecc...). Non abbiamo HTTPS abilitato negli ambienti di sviluppo inferiori e tutto funziona senza problemi. Nei nostri ambienti di produzione il sito reindirizza tutto il traffico su HTTPS.

Il primo problema sembra verificarsi solo con Chrome. Chrome si rifiuta di caricare qualsiasi elemento della pagina che non sia in HTTPS. Non sono sicuro di come far caricare a WordPress jQuery o styles.css (dal mio tema) tramite HTTPS (maggiori informazioni di seguito).

Il secondo problema, sempre con HTTPS, è che non riusciamo ad accedere a WordPress negli ambienti che utilizzano HTTPS. Quando viene caricata la schermata di login (sitename.com/wp-admin) si viene reindirizzati a wp-login come previsto, ma dopo aver inserito username/password la pagina si ricarica semplicemente. Nessun errore (ho controllato console/firebug e httpfox e non ho trovato errori).

So che stiamo facendo qualcosa di sbagliato con HTTPS in generale perché stiamo avendo molti problemi negli ambienti che lo supportano. Ho fatto diverse ricerche e sorprendentemente non ho trovato molto sull'uso di HTTPS con WordPress. Oltre alle risposte alle domande su come caricare jQuery via HTTPS e come accedere alle istanze WordPress HTTPS, ci sono dei buoni link su come lavorare con HTTPS in WordPress. Quasi tutto quello che ho trovato fa riferimento all'utilizzo del plugin WordPress HTTPS e lo proveremo, ma non sono sicuro se risolverà tutti i nostri problemi.

Nota* Nel mio functions.php sto usando Enqueue per caricare i file JS e CSS nel modo corretto, e sto usando percorsi relativi per quei caricamenti //sitename.com/bla/bla che funzionano bene. Sto caricando jQuery nel mio header.php e styles.css viene caricato automaticamente come parte del caricamento del tema, quindi non so come configurare entrambi per caricarli via HTTPS o se questo sia l'approccio corretto per risolvere questi problemi. (jQuery viene caricato dal nostro file system locale non da una CDN). Qualsiasi aiuto sarà molto apprezzato. Grazie in anticipo.

3
Commenti

Il tuo sito di produzione è dietro un proxy inverso / bilanciatore di carico? Questo impedirà a WordPress di rilevare SSL e nessuno script verrà caricato via SSL. Se non sei sicuro, installa SSL Insecure Content Fixer ed esegui il test is_ssl() dalla pagina dei plugin.

webaware webaware
3 lug 2013 03:24:26

Il nostro sito è sicuramente dietro un bilanciatore di carico. In precedenza ho lavorato su un sito WP dietro un bilanciatore di carico con HTTPS abilitato e non ho avuto questi problemi (ma avevo alcune persone di rete eccellenti che probabilmente hanno gestito questi problemi per me). Quindi cosa possiamo fare per far sì che WordPress rilevi SSL dietro il bilanciatore di carico.

RAC RAC
3 lug 2013 20:56:08

Non riesco nemmeno a caricare plugin in questi ambienti problematici perché NON POSSO ACCEDERE A WORDPRESS. Quindi purtroppo tutte le soluzioni che implicano il caricamento di un plugin non saranno d'aiuto.

RAC RAC
3 lug 2013 21:03:13
Tutte le risposte alla domanda 4
2

Dato che sei dietro a un load balancer (come confermato nei tuoi commenti sopra), la tua installazione di WordPress non sarà in grado di rilevare SSL usando la funzione is_ssl(), e non servirà alcuno script o foglio di stile caricato con URI in protocollo https:.

Se sei dietro a un load balancer che supporta la variabile di server HTTP_X_FORWARDED_PROTO, puoi risolvere il problema aggiungendo questo snippet al tuo file wp-config.php:

// Amazon AWS Elastic Load Balancer, CloudFlare e altri
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
    $_SERVER['HTTPS']='on';

Se sei così sfortunato da essere ospitato su Network Solutions, prima picchia la testa contro la scrivania, poi prova a incorporare questo gist in un plugin già attivato (dato che non puoi attivare nuovi plugin perché non riesci ad accedere all'admin): https://gist.github.com/webaware/4688802

In realtà, dovresti essere in grado di forzare il tuo admin a non usare SSL, accedere, installare i plugin che ti servono e poi testare la tua installazione su SSL per vedere se tutto funziona, prima di forzare l'uso di SSL. Aggiungi questo al tuo file wp-config.php, cambiando WP_SITEURL e WP_HOME per corrispondere al tuo server reale.

define('FORCE_SSL_LOGIN', false);
define('FORCE_SSL_ADMIN', false);
define('WP_SITEURL', 'http://example.com/');
define('WP_HOME', 'http://example.com/');
4 lug 2013 02:20:29
Commenti

Grazie per questo! Sono un po' sorpreso che non sia integrato di default.

Noz Noz
23 nov 2015 20:41:31

Grazie per questa risposta! L'aggiornamento di wp-config.php funziona bene quando configuro HTTPS usando AWS ELB.

Leon Leon
10 ago 2018 08:09:02
5

La maggior parte dei problemi SSL sono causati da plugin/temi che utilizzano il codice errato per caricare CSS/JS.

  • Nelle impostazioni generali di WordPress, cambia l'Indirizzo WordPress (URL) e l'Indirizzo del sito (URL) da HTTP a HTTPS. Se non hai accesso all'area di amministrazione, puoi modificare questo tramite il tuo file wp-config.php http://codex.wordpress.org/Editing_wp-config.php

  • Utilizza i percorsi URL corretti per i tuoi temi e plugin: http://codex.wordpress.org/Determining_Plugin_and_Content_Directories Ad esempio, hardcodare WP_PLUGIN_URL non funzionerà rispetto a plugin_dir_url. Le funzioni sono generalmente compatibili con SSL perché hanno il tempo di verificare se il sito è abilitato per SSL, mentre le costanti no.

  • Per l'area di amministrazione/login puoi forzare SSL tramite il file wp-config.php:

    Login: define('FORCE_SSL_LOGIN', true);

    Amministrazione: define('FORCE_SSL_ADMIN', true);

Ovviamente, qualsiasi asset hardcodato sarà un problema, così come i plugin/temi che caricano gli asset in modo errato.

Puoi anche aggiornare i tuoi temi e plugin via SSL se il tuo server ha libssh2, puoi anche definire il numero di porta e le chiavi di autenticazione. Se questa opzione è abilitata, non devi definire nulla: apparirà magicamente nelle impostazioni di amministrazione.

2 lug 2013 04:15:16
Commenti

Grazie per la risposta. Ho costruito i plugin che utilizziamo e tutti caricano CSS e JS nel modo corretto. La mia prima domanda rimane però senza risposta. WordPress sta caricando jQuery e styles.css nella mia homepage e lo sta facendo via HTTP. Chrome sta bloccando entrambi questi caricamenti essenziali. C'è un modo per forzare WordPress a caricare gli asset in HTTPS?

RAC RAC
2 lug 2013 19:39:57

Inoltre hai menzionato libssh2. Dove è configurato. Ho cercato nel file httpd.conf di Apache senza risultati. È un modulo PHP?

RAC RAC
2 lug 2013 19:58:44

libssh2 è una libreria SSH per il tuo sistema operativo, quindi dovresti installarla a livello del sistema operativo, poi PHP può utilizzarla con qualcosa come http://pecl.php.net/package/ssh2 che è un'estensione PHP. Hai fatto il passo #1? Se sì, allora nessun asset dovrebbe caricarsi via HTTP a meno che non sia un tema o un plugin che lo fa in modo errato.

Wyck Wyck
2 lug 2013 21:14:20

Non posso fare il primo passo perché non riesco ad accedere a WordPress.

RAC RAC
3 lug 2013 00:52:21

Puoi definire questa impostazione nel tuo file wp-config.php, http://codex.wordpress.org/Editing_wp-config.php#WordPress_address_.28URL.29

Wyck Wyck
3 lug 2013 03:00:59
1

Ok! Mi è successo anche in passato. Assicurati di caricare correttamente il tuo file jQuery e poi ricontrolla il file javascript da cui dipendono i plugin. WordPress offre diversi modi per caricare i file js. Verifica inoltre di non caricare il file jQuery predefinito di WordPress insieme alla tua versione personalizzata di jQuery. Per il tuo problema HTTP, ti consiglio di consultare html5boilerplate.com che utilizza metodi più intelligenti per gestire HTTP. Evita di modificare eccessivamente i file core :)

2 lug 2013 21:27:18
Commenti

Ho già provato a disabilitare tutti i plugin tramite il database (dato che non riesco ad accedere al pannello di amministrazione di WordPress, non posso modificare nulla tranne le cose del file system o del database, niente nell'interfaccia utente di WordPress).

RAC RAC
3 lug 2013 00:54:36
1

Abbiamo trovato una soluzione e sembra essere puramente ambientale, ovvero un problema nella configurazione dei nostri ambienti. A quanto pare, il nostro server MySQL e il server effettivo non erano sulla stessa macchina e WordPress ha bisogno di conoscere esplicitamente la differenza tra le richieste indirizzate alla macchina MySQL e quella contenente il codice effettivo. Quindi la soluzione consisteva nel capire quali voci del database puntare al server SQL e quali al server web.

Una volta capito come configurare gli ambienti in modo da poter effettuare l'accesso, ho abilitato il plugin HTTPS e siamo riusciti a caricare il sito normalmente, risolvendo il problema di Chrome relativo al blocco delle richieste non HTTP.

9 lug 2013 03:36:06
Commenti

Qui i thread non vengono chiusi, dovresti semplicemente scegliere una risposta.

Wyck Wyck
9 lug 2013 03:47:05