Stefan Kalscheuer

Ich habe es zwischenzeitlich auf einer Testsite und einer realen Site getestet. Öfentliche Subnetze (sowohl IPv4, als auch IPv6) in die Filter eingetragen, Live-Filter aktiviert und los.
Statify selbst mit aktiviertem JavaScript und WP Super Cache.
Eine Funktioniert tadellos. Entsprechend müssen wir das Problem ein wenig eingrenzen.

—-

die gesamte Live-Statify Filterung scheint bei mir nicht zu funktionieren.

Kannst du einmal das Statify Filter Plugin deaktieren und testen, ob eingeloggte Benutzer weiterhin mit erfasst werden?

Und hast du irgendwelche weiteren Anpassungen, z.B. einen eigenen Filter-Hook für statify__skip_tracking, der zufällig true zurückgibt? (Statify Blacklist 1.3.0 hatte das Problem – ich nehme aber bisher an, dass eine aktuelle 1.6 zum Einsatz kommt)

Und (verzeihe mir die möglicher Weise blöde Frage, aber schonmal übersieht man die einfachsten Dinge), die Häkchen bei “Live-Filter aktivieren” hast du schon gesetzt, oder?

Hat dann vermutlich etwas mit meinen Cahing/Minifying Einstellungen zu tun?

Unwahrscheinlich.

Minifizierung mit absoluter Sicherheit nicht, da das ja nur Frontend-Ressourcen betrifft (und das JavaScript zum Tracken wunderbar funktioniert – die Filter werden aber auf dem Server ausgewertet). Caching nicht unmöglich, aber sehr unwahrscheinlich.

• This reply was modified 5 years, 3 months ago by Stefan Kalscheuer.

Hallo,

das ist so technisch nicht möglich.

Eine MAC-Adresse (Layer 2 des OSI Modells) wird grob gesagt zur Identifikation von Geräten innerhalb eines physischen Mediums verwendet (so weiß z.B. ein Switch, an welchen Port ein Paket geschickt werden soll). Die Webanwendung (Layer 5-7) sieht nur noch IP Adressen (Layer 3), welche netter Weise in HTTP Headern verkapselt sind. Die originale MAC Adresse des Absenders wird so weit nicht durchtransportiert. Der vorgeschaltete Webserver sieht diese schon nicht mehr. Eine Rückwärts-Auflösung wäre auch nur dann möglich, wenn sich der Client im selben lokalen Netzwerk befindet.

Dass eine MAC Adresse ein Gerät global eindeutig definiert, ist an dieser Stelle auch ein Trugschluss. Zwar gibt es Herstellerspezifische Blöcke, die theoretisch eindeutig sind, aber spätestens wenn man über virtuelle Maschinen oder Privatsphäreeinstellungen sprechen (zufällige MAC generiere, um in fremden Netzen nicht direkt identifizerbar zu sein), sind die Dinger genauso aussagekräftig wie 192.168-Adressen im Internet-Kontext.

Gruß,
Stefan

You are absolutely right. Ran into the same issue yesterday when writing unit tests.

In fact the “broken“ logic is quite old (v1.3.10 code), wondering why it was never reported until now… Lower chance because fewer files were scanned before and likely the generous implicit string conversion in older PHP versions did the rest for most cases (value can be of an type).

No idea what the actual intention behind the iteration on the option value was, but nevertheless we will fix it.

Cheers,
Stefan

Update:
Version 1.4.1 has just been released. It fixes the issues described above, s.t. now all theme files are scanned and the manual scan is working again.

With Divi you will likely notice quite a lot of alerts across the files, many of them in the /includes/builder/ subdirectory. Various classes do use signatures that AntiVirus detects as risky code (output buffer handling, opening files, …). You can dismiss them as before. With 1.3 they have just not been scanned, because parent themes were ignored and hierarchy was limited to 1.

There is a way to exclude the files from scanning, leveraging the theme_scandir_exclusions hook that defaults to array( 'CVS', 'node_modules', 'vendor', 'bower_components' ). One could add 'builder' to this list, that eliminates 90% of the warnings. Did not check for negative side effects though.

Cheers,
Stefan

Thanks for your input and the possible solution!

Sounds like a reasonable change, so I’ll try to integrate with an upcoming release (https://github.com/stklcode/wp-liveticker/issues/14).

Cheers,
Stefan

Hi,

I hadn’t planned a dedicated update, because 1.5.1 seems to work fine with WP 5.5. Apparently I forgot about raising the compatibility tag, sorry for that.

Nevertheless, I’ve released v1.5.2 a few seconds ago with some minor internal corrections and explicit 5.5 compatibility.

The wording – starting from the plugin’s name “Statify Blacklist” – is not perfect, as the term “blacklist” is more or less replaced by more descriptive phrases in 5.5, but I’ll take care of that in near future. Functionality is given.

Cheers,
Stefan