You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I run a VPS with multiple vHosts, and some of them have completely separate Piwik installations (with dedicated databases), and few others are not tracked, just websites.
To make this simple, here is the setup model:
vHost A + Piwik A with separate db (btw. this is the first, and thus, default vHost)
vHost B + Piwik B with separate db
vHost C (no Piwik)
vHost D (no Piwik)
and so on.
Now, today I have noticed something very strange in my Piwik A (vHost A) visitors log: it showed me that a visitor has visited a page from my vHost B (Piwik B) and it was logged as a valid perfectly normal visit. Needless to say that this domain is NOT a domain of vHost A, so that should never happen, right? I mean, it should be reported in Piwik B.
Then I accessed my server log, to see what this user was trying to access. And here it is:
As you can see, it was trying to pass a real, existing page from my vHost B website and some referrer spoofing or whatever.
Now, this probably got returned to my vHost A (as it is the default one, when you access the VPS server via IP Address), so it got recorded by Piwik A (instead of Piwik B).
Server returned HTTP 204 [NO CONTENT]
This was a single request (no other components were requested - like css, js etc.) so it was clearly a bot or some tool used there, seeking specifically for some results from Piwik.
The IP belongs to Japan Network Information Center (whoever they are).
My question: while this might be actually a very interesting anomaly that may put some suspicion to the careful admin (I have noticed this only because my vHost A website has very low traffic, otherwise, it would probably be noticed only on page reports, where a page from other vHost website would be reported) - should we somehow prevent this from happening?
Thanks
update:
I have done some server configuration modifications to prevent vHost A from being default, now this mix-up should never happen again. Still, would be nice to hear some opinions about this.
The text was updated successfully, but these errors were encountered:
Needless to say that this domain is NOT a domain of vHost A, so that should never happen, right? ...
... - should we somehow prevent this from happening?
Hi, I run a VPS with multiple vHosts, and some of them have completely separate Piwik installations (with dedicated databases), and few others are not tracked, just websites.
To make this simple, here is the setup model:
Now, today I have noticed something very strange in my Piwik A (vHost A) visitors log: it showed me that a visitor has visited a page from my vHost B (Piwik B) and it was logged as a valid perfectly normal visit. Needless to say that this domain is NOT a domain of vHost A, so that should never happen, right? I mean, it should be reported in Piwik B.
Then I accessed my server log, to see what this user was trying to access. And here it is:
As you can see, it was trying to pass a real, existing page from my vHost B website and some referrer spoofing or whatever.
Now, this probably got returned to my vHost A (as it is the default one, when you access the VPS server via IP Address), so it got recorded by Piwik A (instead of Piwik B).
Server returned HTTP 204 [NO CONTENT]
This was a single request (no other components were requested - like css, js etc.) so it was clearly a bot or some tool used there, seeking specifically for some results from Piwik.
The IP belongs to Japan Network Information Center (whoever they are).
My question: while this might be actually a very interesting anomaly that may put some suspicion to the careful admin (I have noticed this only because my vHost A website has very low traffic, otherwise, it would probably be noticed only on page reports, where a page from other vHost website would be reported) - should we somehow prevent this from happening?
Thanks
update:
I have done some server configuration modifications to prevent vHost A from being default, now this mix-up should never happen again. Still, would be nice to hear some opinions about this.
The text was updated successfully, but these errors were encountered: