Custom 404 Page by Siropu 1.2.0

[Siropu]

I have an issue with it showing me TAGS in the logs (thousands of them), and when I click on them, it takes me to the TAG page and not a 404.

Add-on logs all 404 when they occur so that's strange.

is there a way to set up the 404 redirects's using a wildcard url to capture all possible combo's

There is an admin option for regex redirects.

 

[Will Franco]

404 errors don't occur if there's a "?" string appended to the URL.

 

[briansol]

is this compatible with 2.3?

 

[Siropu]

is this compatible with 2.3?

Not yet. The Javascript based features won't work.

 

[Siropu]

Siropu updated Custom 404 Page by Siropu with a new update entry:

Update for XenForo 2.3

This version is compatible with XenForo 2.3

Read the rest of this update entry...

 

[CedricV]

Thank you for this amazing add on and offering it for free. My page went from



to this

 

[clientworkbd]

My regex redirect solution:

Find: @(\w+)://([\w\-\.]+)/(\w+)/([\w\-\.]+)/(\d+)([\w\-\.]+)@
Replace: $1://$2/$3/threads/$5

It's worked for me, but media not redirected.

 

[dutchbb]

Can the page_not _found table be converted to innodb?

 

[Siropu]

It can be converted if you want. Don't remember why I used MyISAM for it.

 

[JoyFreak]

Hello. I just noticed that when you create a redirect i.e. https://www.example.com/news/ to https://www.example.com/new/... the redirect will only work if the URL has the trailing slash at the end. If it doesn't, then it won't work. For example https://www.example.com/news will throw a 404 not found. Could this be fixed please?

 

[smallwheels]

Sorry if this has been asked before: I installed this add on recently and am wondering why in most of the cases no source IP is in the log (while sometimes there is one - but only in maybe 1% of the cases if at all)?

 

[bzcomputers]

Sorry if this has been asked before: I installed this add on recently and am wondering why in most of the cases no source IP is in the log (while sometimes there is one - but only in maybe 1% of the cases if at all)?

Are the entries with IPs, for logged in members? That would be my guess.

 

[smallwheels]

Are the entries with IPs, for logged in members?

No.

 

[Siropu]

Could this be fixed please?

Have you tried adding it without / or both?

wondering why in most of the cases no source IP is in the log

It could be a bot/proxy that doesn't send any IP information.

 

[smallwheels]

It could be a bot/proxy that doesn't send any IP information.

How could that be? I'd have assumed that it is unavoidable to send the source IP given how TCP/IP works and apart from that: The IPs are logged in the server's web.log when you grep it with the URL that is noted in the log of the 404-add on. So they are there.

 

[JoyFreak]

Have you tried adding it without / or both?


It could be a bot/proxy that doesn't send any IP information.

You can only add one redirect per 404. Adding it without the / will only account for the 404 without the /.

 

[Siropu]

How could that be?

Bots can manipulate the headers used to get the user IP so they are not reliable.

The IPs are logged in the server's web.log when you grep it with the URL that is noted in the log of the 404-add on. So they are there.

I'm using XF's getIp() method with $allowProxied set to true to get the IP so unless convertIpStringToBinary fails, which is used to get the value stored for the IP, what you see is what you get in the 404 logs.

You can only add one redirect per 404.

You can use the regex redirect admin option: #^https?://www\.example\.com/news/?$#

 

[JoyFreak]

Bots can manipulate the headers used to get the user IP so they are not reliable.


I'm using XF's getIp() method with $allowProxied set to true to get the IP so unless convertIpStringToBinary fails, which is used to get the value stored for the IP, what you see is what you get in the 404 logs.


You can use the regex redirect admin option: #^https?://www\.example\.com/news/?$#

Will I have to do this for every URL? I have a few and it would be tedious.

 

[Siropu]

Will I have to do this for every URL?

For the /route/ part, yes.

 

[smallwheels]

I'm using XF's getIp() method with $allowProxied set to true to get the IP so unless convertIpStringToBinary fails, which is used to get the value stored for the IP, what you see is what you get in the 404 logs.

This goes beyond my knowledge and experience. I can only assume that the difference possibly might come from different layers: XF lives somewhat on the application layer wheras the webserver gets it information probably directly from the network layer. Spoofing a sender IP in TCP/IP does only make sense if you do not want to receive an answer, so mainly for DOS-attacks. The requests I am after are clearly eager for an answer: They call lists of potentially existing URLs in the hope to find something, they scan for things like /backups, /dev, /wp-includes/html-api/index.php, files under /wp-install etc.. So they do want an answer, however, it might make sense for them to garbadge the headers somwhat for the exact reason to poison logs on the application layer (if that's possible) in an attempt to hide themselves.
These fraudulent requests are however not the kind of requests your add on aims at, so clearly no failure on your side.

On a sidenote: Most of them come from Microsofts network range, so possibly these are azure accounts that could be cut off quickly by Microsoft in case attacks and frauds come from them and Microsoft gets notified. So it would make sense for the crackers to hide their IPs as good as possible to slow down the rate in which they have to switch their azure accounts and the (probably fake or stolen) identities and credit card details to open fresh ones and to rebuild their infrastructure.
Another big part of those requests currently comes from networks located in Africa (or rather network blocks that belong to Afrinic administration). ATM mainly from the network of a company with the trustworthy name "cheapy.host" - who do not seem to have a working homepage (any more) but still a (somewhat dead) facebook page.