Podlove Contributor-Avatare & Icons im Cache über http statt https ausgeliefert


#1

Hallo Community

Nebst einem anderen https-Problem, ist mir eben folgendes aufgefallen:

Die https Startseite wird nicht mehr als vollständig sicher dargestellt. Geblockt werden Avatarbilder sowie die Social Services Icons.

unsichere Inhalte blockiert

Die Warnmeldung sagt leider lediglich “Diese Seite versucht, Skripts aus nicht authentifizierten Quellen zu laden.” Mehr Infos gibt sie mir nicht.

Update: Es handelt sich aus mixed content. Die Bilddateien im Cache werden über http statt https ausgeliefert.

Lasse ich diese Quellen zu, werden die Icons zwar wieder angezeigt - allerdings streicht mir Chrome 66.0.3359.139 dann auffällig rot das https.

Weiter interessant:
Einzelne Episodenseiten scheinen nicht betroffen zu sein, obwohl diese die gleichen Icons verwenden. Zudem scheint das Problem manchmal wie von Geisterhand zu verschwinden und zurückzukehren. 🤷

Hat jemand von euch eine Idee, was da schief laufen könnte?

Website                    https://GameTalk.FM
PHP Version                7.0.29
WordPress Version          4.9.5
WordPress Theme            Joeys Twenty Fifteen Child v1.0
Active Plugins             
           - Akismet Anti-Spam v4.0.3
           - Limit Login Attempts v1.7.1
           - Podlove Beta Tester v1.1.3
           - Podlove Podcast Publisher v2.8.0.build531
           - Yoast SEO v7.4.2
WordPress Database Charset utf8
WordPress Database Collate 
Publisher Version          2.8.0.build531
Web Player Version         player_v4
Twig Version               1.35.3
open_basedir               ok
curl Version               7.54.0
iconv                      available
simplexml                  ok
max_execution_time         50
upload_max_filesize        100M
memory_limit               256M
disable_classes            
disable_functions          exec, shell_exec, system, dl, passthru, proc_open, proc_close
permalinks                 ok (/%postname%/)
podlove_permalinks         ok
podcast_settings           ok
web_player                 ok
podlove_cache              on
assets                     
  - mp3    audio/mpeg       https://GameTalk.FM/feed/mp3/
  - m4a    audio/mp4        https://GameTalk.FM/feed/m4a/
cron                       ok

0 errors
0 notices
Nice, Everything looks fine!

Update:
Das Problem kann nun scheinbar auch in einer Mischform auftreten:
Blockierte Inhalte Mischform


Update 2:
Das Löschen des Caches in Podlove lässt das Problem temporär verschwinden. Scheinbar sind die Bilddateien also erst dann unsicher, wenn sie aus dem Cache kommen?


#2

sind das alle pungins die du am laufen hast hat der horster einen internen oder sowas. dieses kann pasieren meiner erfarung nach wenn man den chase nicht gelerthat

aber da sist nur ein schluss ins blaune


#3

Plugins laufen:

  • Akismet Anti-Spam
  • Limit Login Attempts
  • Podlove Beta Tester
  • Podlove Podcast Publisher
  • Yoast SEO

Da chacht wohl niemand sonst ausser das Podlove Plugin. Aber den Host selber hatte ich bislang nicht im Visier. :thinking: Guter Tipp. Ich werde den sonst mal anschreiben.


#4

die plugins die du hast machen da weniger stress bis auf das akismet das würde ich nicht verwenden da es nach deuten datenschuts und bals 25.5 sowieso nicht mehr ok ist da kanste besser die antspam bee verwenden aber ohne das die nach hause thelefoniert.


#5

Um vielleicht ganz am Anfang zu beginnen:

Welche “Skripts” könnte Chrome hier überhaupt meinen? Wenn ich wüsste, welche das sind und wo die her kommen, würde das die Lösung des Problems wohl vereinfachen.

Gibt es in Chrome ein Tool, welches mir da mehr verrät als die knappe Meldung? Ein Klick aufs Fragezeichen hilft leider nicht.


#6

Entwickler-Tools, aufrufbar mit F12. Dann dort mal in die Konsole spicken.


#7

Chrome bezieht sich hierbei wohl auf die Bilder (explizite Links mit HTTP).

Irgendwer baut also kaputte Links in die Seite für den Cache.
Könnte passieren wenn der Cache-Build von Anfragen über HTTP getriggert wird.
Solange man absolute Linkangaben verwendet wird die gleiche Seite nie sauber für verschlüsselte und unverschlüsselte Anfragen laufen.

Würde auch dazu passen dass alles gut läuft solange die Seite noch nicht für den Cache gebaut worden ist sondern pro Anfrage neu erstellt wird.


#8

Danke für den Tipp, daran hatte ich nicht gedacht.
In der Tat erhalte ich da mehr Infos. Ein Beispiel:

(index):1 Mixed Content: The page at 'https://gametalk.fm/' was loaded over HTTPS, but requested an insecure image 'http://gametalk.fm/wp-content/cache/podlove/22/eba5b79be65790c4384adde5425191/xbox-live_20x20.png'. This request has been blocked; the content must be served over HTTPS.

Im Cache wird also ein http Pfad gebaut.

Jetzt muss ich nur noch herausfinden, wie ich wen auch immer dazu zwinge, stattdessen einen https Pfad zu bauen.

Wird das von Podlove so gestaltet oder von meinem Host oder gar von mir selbst?