Încărcarea style.css și jQuery folosind HTTPS

2 iul. 2013, 03:55:18
Vizualizări: 25K
Voturi: 4

Avem mai multe medii de dezvoltare și tocmai am început să folosim WordPress (Dev, QA, Pre-prod, prod etc...). Nu avem HTTPS activat în mediile inferioare și totul funcționează fără probleme. În mediile noastre de producție, site-ul redirecționează tot traficul către HTTPS.

Prima problemă pare să fie doar cu Chrome. Chrome refuză să încarce orice element de pe pagină care nu este HTTPS. Nu știu cum să configurez WordPress să încarce jQuery sau styles.css (din tema mea) peste HTTPS (mai multe informații mai jos).

A doua problemă, tot legată de HTTPS, este că nu ne putem autentifica în WordPress în mediile care folosesc HTTPS. Când se încarcă ecranul de autentificare (sitename.com/wp-admin) ești redirecționat către wp-login așa cum este de așteptat, dar după introducerea numelui de utilizator/parolei, pagina doar se reîmprospătează. Nu apar erori (am verificat consola/firebug și httpfox și nu am găsit nicio eroare).

Știu că facem ceva greșit cu HTTPS în general pentru că avem multe probleme în mediile care îl suportă. Am făcut multe căutări și surprinzător nu am găsit prea multe informații despre utilizarea HTTPS cu WordPress. În afară de răspunsurile la întrebările despre cum să încarc jQuery prin HTTPS și cum ne putem autentifica în instanțele WordPress cu HTTPS, există vreo resursă bună despre cum să lucrezi cu HTTPS în WordPress. Aproape tot ce am găsit face referire la utilizarea plugin-ului WordPress HTTPS și o să încercăm asta, dar nu sunt sigur dacă va rezolva toate problemele noastre.

Notă* În functions.php folosesc Enqueue pentru a încărca fișierele JS și CSS în mod corect, și folosesc căi relative pentru aceste încărcări //sitename.com/bla/bla care funcționează bine. Încarc jQuery folosind header.php iar styles.css este încărcat automat ca parte a încărcării temei, așa că nu știu cum să configurez oricare dintre acestea să se încarce prin HTTPS sau dacă aceasta este abordarea corectă pentru rezolvarea acestor probleme. (jQuery se încarcă din sistemul nostru local, nu dintr-un CDN). Orice ajutor ar fi apreciat. Mulțumesc anticipat.

3
Comentarii

Site-ul tău de producție este în spatele unui proxy invers / load balancer? Acest lucru va împiedica WordPress să detecteze SSL, iar niciun script nu se va încărca prin SSL. Dacă nu ești sigur, instalează SSL Insecure Content Fixer și rulează testul is_ssl() din pagina de plugin-uri.

webaware webaware
3 iul. 2013 03:24:26

Site-ul nostru este cu siguranță în spatele unui load balancer. Am lucrat anterior la un site WordPress în spatele unui load balancer cu HTTPS activat și nu am avut aceste probleme (dar am avut niște persoane de la rețea care au fost excelente și care probabil au rezolvat aceste probleme pentru mine). Deci, ce putem face pentru ca WordPress să detecteze SSL în spatele load balancer-ului?

RAC RAC
3 iul. 2013 20:56:08

De asemenea, nu pot încărca plugin-uri în aceste medii problematice pentru că NU POT SĂ MĂ AUTENTIFIC ÎN WORDPRESS. Așadar, din păcate, toate remediile care implică încărcarea unui plugin nu vor ajuta.

RAC RAC
3 iul. 2013 21:03:13
Toate răspunsurile la întrebare 4
2

Deoarece sunteți în spatele unui load balancer (confirmat în comentariile de mai sus), instalarea WordPress nu va putea detecta SSL folosind funcția is_ssl() și nu va servi niciun script sau fișier de stil încărcat cu URI-uri de protocol https:.

Dacă sunteți în spatele unui load balancer care suportă variabila de server HTTP_X_FORWARDED_PROTO, puteți remedia problema adăugând acest fragment în fișierul wp-config.php:

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

Dacă aveți ghinionul să fiți găzduit la Network Solutions, mai întâi loviți-vă capul de birou, apoi încercați să integrați acest gist într-un plugin deja activat (deoarece nu puteți activa plugin-uri noi pentru că nu vă puteți autentifica în admin): https://gist.github.com/webaware/4688802

De fapt, ar trebui să puteți forța admin-ul să nu folosească SSL, să vă autentificați, să instalați plugin-urile necesare și apoi să testați instalarea peste SSL pentru a verifica dacă totul funcționează, înainte de a forța utilizarea SSL. Adăugați acest cod în fișierul wp-config.php, modificând WP_SITEURL și WP_HOME pentru a se potrivi cu serverul real.

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

Mulțumesc pentru asta! Sunt puțin surprins că nu este disponibil implicit.

Noz Noz
23 nov. 2015 20:41:31

Mulțumesc pentru răspuns! Actualizarea wp-config.php funcționează bine când configurez HTTPS folosind AWS ELB.

Leon Leon
10 aug. 2018 08:09:02
5

Majoritatea problemelor legate de SSL sunt cauzate de plugin-uri/teme care folosesc cod incorect pentru încărcarea CSS/JS.

  • În setările generale WordPress, schimbați adresa WordPress (URL) și adresa site-ului (URL) de la HTTP la HTTPS. Dacă nu aveți acces la panoul de administrare, puteți face această modificare prin fișierul wp-config.php http://codex.wordpress.org/Editing_wp-config.php

  • Utilizați căile URL corecte pentru temele și plugin-urile dumneavoastră: http://codex.wordpress.org/Determining_Plugin_and_Content_Directories. De exemplu, folosirea directă a constantei WP_PLUGIN_URL nu va funcționa, spre deosebire de funcția plugin_dir_url. Funcțiile sunt în general prietenoase cu SSL deoarece au timp să verifice dacă site-ul are SSL activat, pe când constantele nu sunt.

  • Pentru panoul de administrare/pagină de autentificare, puteți forța SSL prin fișierul wp-config.php:

    Autentificare: define('FORCE_SSL_LOGIN', true);

    Administrare: define('FORCE_SSL_ADMIN', true);

Bineînțeles, orice resurse hardcodate vor fi o problemă, la fel și plugin-urile/temele care încarcă resursele incorect.

De asemenea, puteți actualiza temele și plugin-urile prin SSL dacă serverul dumneavoastră are libssh2 activat. Puteți defini și numărul portului și cheile de autentificare. Dacă această funcționalitate este activată, nu trebuie să definiți nimic, va apărea automat în setările de administrare.

2 iul. 2013 04:15:16
Comentarii

Mulțumesc pentru răspuns. Am construit pluginurile pe care le folosim și toate încarcă CSS și JS în mod corect. Totuși, prima mea întrebare rămâne fără răspuns. WordPress încarcă jQuery și styles.css pe pagina mea principală și o face prin HTTP. Chrome blochează ambele încărcări esențiale. Există vreo modalitate de a forța WordPress să încarce resursele prin HTTPS?

RAC RAC
2 iul. 2013 19:39:57

De asemenea, ai menționat libssh2. Unde este configurat acesta? Am căutat în httpd.conf al Apache fără rezultate. Este un modul PHP?

RAC RAC
2 iul. 2013 19:58:44

libssh2 este o bibliotecă SSH pentru sistemul de operare, deci ar trebui instalată la nivel de sistem, după care PHP o poate folosi prin ceva precum http://pecl.php.net/package/ssh2 care este o extensie PHP. Ai făcut pasul #1? Dacă da, atunci nici o resursă nu ar trebui încărcată prin HTTP, decât dacă o temă sau un plugin o face greșit.

Wyck Wyck
2 iul. 2013 21:14:20

Nu pot face primul pas pentru că nu mă pot autentifica în WordPress.

RAC RAC
3 iul. 2013 00:52:21

Puteți defini această setare în fișierul wp-config.php, http://codex.wordpress.org/Editing_wp-config.php#WordPress_address_.28URL.29

Wyck Wyck
3 iul. 2013 03:00:59
1

Ok! Mi s-a întâmplat și mie la fel înainte. Asigură-te că încarci fișierul jQuery corect și apoi verifică din nou fișierul JavaScript al pluginului de care depinde. WordPress are mai multe modalități de a încărca fișiere JavaScript. Verifică din nou să nu încarci fișierul implicit jQuery al WordPress și fișierul tău personalizat cu versiunea jQuery. Pentru problema ta cu HTTP, te rog să citești html5boilerplate.com - ei folosesc metode mai inteligente pentru HTTP. Nu modifica prea mult fișierele de nucleu :)

2 iul. 2013 21:27:18
Comentarii

Am încercat deja să dezactivez toate plugin-urile prin baza de date (deoarece nu mă pot conecta la panoul de administrare WordPress, nu pot edita decât lucruri din sistemul de fișiere sau din baza de date, nimic din interfața WordPress).

RAC RAC
3 iul. 2013 00:54:36
1

Am găsit o soluție și se pare că era pur și simplu o problemă de mediu, legată de configurarea mediilor noastre. În cazul nostru, serverul MySQL și serverul principal nu erau pe aceeași mașină, iar WordPress trebuie să cunoască explicit diferența dintre cererile direcționate către serverul MySQL și cele către serverul care conține codul real. Așadar, soluția a constat în identificarea intrărilor din baza de date care trebuiau direcționate către serverul SQL și a celor care trebuiau direcționate către serverul web.

După ce am reușit să configurăm mediile astfel încât să mă pot conecta, am activat pluginul HTTPS și am putut încărca site-ul normal, rezolvând astfel problema din Chrome cu cererile non-HTTP blocate.

9 iul. 2013 03:36:06
Comentarii

Firele de discuție nu se închid pe aici, ar trebui doar să alegi un răspuns.

Wyck Wyck
9 iul. 2013 03:47:05