HTTPS le immagini non vengono visualizzate.

[clickepaciughi]

Ciao,
ho 3 siti in altervista per i quali ho effettuato la migrazione in HTTPS da circa 3 settimane,e dal pannello risultano abiltati HTTPS. Però 2 continuano ad uscire con la dicitura "non sicuro" e visualizzazione perfetta, il 3° risulta sicuro ma non si vedono le immagini.( non sempre, adesso pare si vedano ma va a tratti)
Ho cercato nel forum e ho trovato una vecchia discussione in cui si dice di usare il percorso assoluto, ho provato correggendo anche le immagini richiamate nel css ma non funziona. Ho messo nell'.htaccess anche la forzatura di apertura in HTTPS, anche se non era quello il problema,ma niente da fare e ho riportato tutto com'era prima. Insomma sto provando un po' di tutto andando per tentativi, ormai sono fuori da qualche anno nella preparazione dei siti e sono arrugginita e non più aggiornata.
I miei siti non sono fatti con cms ma col codice scritto da me.
Il sito dove non si vedono le immagini è https://www.webpam.altervista.org.
Ringrazio chi mi potrà aiutare.

[GraphOGLRisorse]

Salve,
se vuole mantenere il sito che sia accessibile sia da http che https, come è attulmente, deve converitire i link interni al sito da assoluti a relativi.

Se entra nel sito da http può verificare che le immagini vengono caricate. E' https che blocca i percorsi in http, che è del tutto normale.

Altrimenti, se non le interessa di mantere l'accesso da http, può effettuare il redirect(riscrittura) nell'.htaccess:

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule .* https://NomeSito.altervista.org%{REQUEST_URI} [L,R=301]

Inoltre, vedo che nel sito appaiono dei banner che fanno riferimento a ad.jalbum.net. Da regolamento(6.1.5), non è consentito usare banner/servizi remunerati esterini ai circuiti forniti da AlterVista.

Cordiali saluti.

[clickepaciughi]

Parto dal fondo:
i banner che compaiono sono inseriti da Jalbum in automatico, io non ricevo compensi per questi banner.
Per l'aggiunta codice all'htaccess l'avevo già fatto ma non funzionava e l'ho tolto, proverò ancora a rimetterlo.
Per convertire i link da assoluti a relativi(pensavo il contrario) si intende solo quelli delle immagini? Inizialmente erano tutti relativi, li ho corretti perchè avevo capito male.
Per ora ringrazio e riprovo a modificare come mi ha detto.
Ho rimesso il codice nell'ht.access ma evidentemente c'è qualcosa che è in conflitto con quello che già avevo, per me è arabo e non so dove mettere mano.

[GraphOGLRisorse]

Per convertire i link da assoluti a relativi(pensavo il contrario) si intende solo quelli delle immagini? Inizialmente erano tutti relativi, li ho corretti perchè avevo capito male.

Vannno resi relativi oltre quelli delle immagini, anche quelli di file come css e js, anche se con la riscrittura se ne può fare a meno volendo.

Ad ogni modo, ora visualizzo le vimmagini anche da https,forse perchè ha ripristinato i link relativi. Pero la riscrittura nell'htaccess mi risulta non avere effetto. Magri attenda un po', le modifiche nell'htaccess non hanno effetto immediato.

Eventualmente può riportare qui il codice dell'.htacces, per vedere se ci sono degli errori.

Cordiali saluti.

[clickepaciughi]

Vannno resi relativi oltre quelli delle immagini, anche quelli di file come css e js, anche se con la riscrittura se ne può fare a meno volendo.

Ad ogni modo, ora visualizzo le vimmagini anche da https,forse perchè ha ripristinato i link relativi. Pero la riscrittura nell'htaccess mi risulta non avere effetto. Magri attenda un po', le modifiche nell'htaccess non hanno effetto immediato.

Eventualmente può riportare qui il codice dell'.htacces, per vedere se ci sono degli errori.

Cordiali saluti.

Innanzi tutto la ringrazio per l'attenzione.
Riporto qui il vecchio codice dell'htaccess con il quale le immagini si vedono ( per ora)

# av:AntiHotlink
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_URI} \.(gif|jpe?g|png)$ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://([a-z0-9\-\.]*)webpam\.altervista\.org
RewriteCond %{REQUEST_URI} !^\/_altervista_ht\/
RewriteCond %{HTTP_REFERER} !^http://([a-z0-9\-\.]+)google\.
RewriteRule .*$ http://hl.altervista.org/split.php?http://%{HTTP_HOST}%{REQUEST_URI} [R,L]
# AntiHotlink
# # av:Toolbar
SetEnv AV_TOOLBAR 0

Aggiungendo le ultime righe in fondo le immagini scompaiono come può vedere dal sito in rete ora.
# av:AntiHotlink
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_URI} \.(gif|jpe?g|png)$ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://([a-z0-9\-\.]*)webpam\.altervista\.org
RewriteCond %{REQUEST_URI} !^\/_altervista_ht\/
RewriteCond %{HTTP_REFERER} !^http://([a-z0-9\-\.]+)google\.
RewriteRule .*$ http://hl.altervista.org/split.php?http://%{HTTP_HOST}%{REQUEST_URI} [R,L]
# AntiHotlink
# # av:Toolbar
SetEnv AV_TOOLBAR 0

RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule .*https://webpam.altervista.org%{REQUEST_URI} [L,R=301]

Sicuramente sbaglio qualcosa ma non so metterci mano.

[GraphOGLRisorse]

Deve fare attenzione agli spazi nelle istruzini delle regole. Ometterli o aggiungerli può compromettere il corretto funzionamento.

Ad esempio qui, tra .* https manca lo spazio:

RewriteRule .*https://webpam.altervista.org%{REQUEST_URI} [L,R=301]

Inoltre, suggerirei anche di spostare il blocco della riscrittura appena aggiunto (tutto il blocco) all'inizio, sotto a RewriteBase / .

Il resto mi sembra che sia a posto.

Un consiglio per fare meno confusione, in particolare se ha poca esperienza, tra un blocco e l'altro delle varie regole, lasci una riga vuota, così da rendere più immediata l'identificazione.

PS. Quando riporta dei codici nel forum, usi anche i tag bb appropiati per i codici, così da rendere migliore la lettura. In questo caso, va usato il tag generico [code] e [/ code] (la chiusura del tag va senza lo spazio).

Cordiali saluti.

[clickepaciughi]

ho provato a fare le correzioni ma ora non si vedono le immagini,
riproverò domani perchè sono in tilt.
grazie e buona serata.

[GraphOGLRisorse]

Ora la riscrittura finziona.

Il motivo per il quale le immagini non vengono caricate nella versioned el sito in https, penso che sia dovuto al fatto che varia parte dell'url tra http e https.

Ad sempio:
https://www.webpam.altervista.org/al...s/IMG_5568.JPG
http://www.webpam.altervista.org/alb...s/IMG_5568.JPG

Per https è /album/slides/IMG_5568.JPG menttre per http è /album/thumbs/IMG_5568.JPG

Cordiali saluti.

[clickepaciughi]

E' una vera tragedia! Non posso correggere tutti i link di tutti gli album,pensavo fosse solo un problema delle immagini home.
Io ci rinuncio, cosa devo fare per tornare in HTTP? Iniziando dalle impostazioni su Altervista, grazie.
Questo vale anche per gli altri due siti per i quali finora ho solo effettuato la migrazione su HTTPS e non vorrei succedesse un pasticcio come questo.Tra l'altro non capisco perchè vengano segnalati come siti non sicuri quando è attivo HTTPS.

[GraphOGLRisorse]

Non credo che si tratti di doverli corregere tutti a mano.

Se in http il percorso risulta corretto e in https no, ciò mi fa pensare che ci sia qualche codice che esegue la modifica del percorso quando l'url viene caricato in https.

Tale comportamento non è correlato all'attivazione di https.

Il sito lo ha fatto lei, quindi solo lei può sapere/verificare se è presente un quanche codice che modifica il percoroso degli url quando sono in https.

Altra possibilità, se lei non ha codici del genere, è che dipenda dall'antifurto banda attivo, il blocco che è compreso tra i commenti con AntiHotlink. In tal caso, visto che il codice sembra essere obsoleto, quindi non aggiornato.

Io ci rinuncio, cosa devo fare per tornare in HTTP?

In goni caso, https una volta abilitato resta.

Può semplicemente elimnare il blocco della riscrittura e tornerà visisibile sia in http che https. Ciò però non risolverà il problema del percorso errato da https. Quindi accederà da https non vedrò comunque le immagini.

Tra l'altro non capisco perchè vengano segnalati come siti non sicuri quando è attivo HTTPS.

Probabilmente perchè ci sono degli url di risorse che non sono relativi, quindi restano in http anche quando il sito è erogato in https. I browser moderni (da programmazione), fanno i pignoli e se rilevano il tentativo del caricamento di risorse in http da un sito erogato in https, le bloccano e te lo considerano come non sicuro.

E' ciò che più semplicemente viene defito contenuto misto in riferimento a https e http.

Cordiali saluti.

[darbula]

Quando opera con nuovi servizi (aggiunge, attiva) di altervista deve disabilitare i vecchi e riattivare. Cioè l'antifurto banda va disattivato e riattivato così crea il nuovo codice in .htaccess e per protocollo http o https.
Il codice più o meno facsimile che giustamente prima valuta se diverso da https.

# av:AntiHotlink
RewriteEngine on
RewriteBase /
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule .* https://webpam.altervista.org%{REQUEST_URI} [L,R=301]
RewriteCond %{REQUEST_URI} \.(gif|jpe?g|png)$ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://([a-z0-9\-\.]*)webpam\.altervista\.org
RewriteCond %{REQUEST_URI} !^\/_altervista_ht\/
RewriteCond %{HTTP_REFERER} !^https?://([a-z0-9\-\.]+)google\.
RewriteRule .*$ https://hl.altervista.org/split.php?https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
# AntiHotlink
# # av:Toolbar
SetEnv AV_TOOLBAR 0

Poi il problema secondario è stilare la preferenza del Main Domain (Dominio Principale) se non è un dominio di secondo livello e cioè un dominio di terzo livello user.altervista.org non usare il sottodominio www (significa non https://www.user.altervista.org) sia nella barra degli indirizzi del browser che come markup del codice sorgente html.

[clickepaciughi]

La ringrazio del tempo che mi ha dedicato, ho ripristinato il sito com'era prima quando funzionava tutto,
questo sito si compone di una sola index e codici strani non ce ne sono, per quanto riguarda gli album vengono creati col programma free di Jalbum e tutto viene messo in rete come elaborato in automatico per cui non saprei nemmeno dove andare a cercare cose che fanno conflitto.
Per il momento lascio tutto com'è sperando che le cose funzionino in caso contrario cercherò una soluzione diversa magari con un cms pronto, anche se avrei preferito evitare di imbarcarmi in una nuova avventura web.
Buona giornata

[darbula]

Abbia fiducia il primo conflitto è l'antifurto banda poiché è impossibile prevedere il futuro (il codice cambierà a seconda di alcune circostanze).