Ioan CHIRIAC

@dimasmagadan Hi,

The short answer for not using urlencode is yes, I know about it and I don't want to use it.

For more explanations, the reason is that I need to build a unique URLs index and I don't care about retrieving the original title from the URL, but with these function I can filter all url variations and be sure that urls are not the same :

• case sensitive
• ignore any accents
• removing tags
• remove special chars
• (optionnaly) only alpha numerics

great tip, thanks

really great :)

Hi,

Unfortunately that's not true - you're not using threads but forks ...

Take a look at :
http://www.geekride.com/fork-forking-vs-threading-thread-linux-kernel/

When you speak about large amounts of shared data you're right, threads could help but forks don't coz the memory is duplicated between the father and the child ...

You can findout this experimental project that's do real threading (but remains limited in comparison to java or c#) :
https://github.com/alecgorge/php_threading

Hi,

Unfortunately there is no way to trust headers from a proxy - but there is some work around :

• save all ips (even if it's faked)
  If you do a blacklist based on IP, do the check it from all ips - if the userfake the headers, the REMOTE_ADDR is always not faked (it comes from the socket connection)

• try to detect if the headers are faked
  If you realy want to know if the IP is faked, try to connect to common proxy ports (80, 8080, 1024 ...etc...) but this will be costly on a common page, you could only do that over a connection form for example, with a very low connection TTL (like 100ms) - but this also could be faked if the user open a listen socket on a proxy port (keep in mind that is just for warning/logging a bad result - if the result is OK you're not sure anyway)

• have a list of trusted proxy IPs :
  Check the current REMOTE_ADDR over a list of trusted IP (like a list of reverse-proxy from your own network. This does not work over the web

And don't forged the anonymized proxys - they don't send you headers with the user IP - there is no way to know who is behind. The workaround here is to just scan ports, find out that is a proxy, and disable his access from its remote_addr.

For sure, the problem can't be solved in a function ^^, but my advice is that you want to secure an access (back-office) trust only REMOTE_ADDR, if you want to ban someone, yes you could use this function, it will just work great.

The problem with that function is that enables the user to fake his IP without passing by a proxy and adding a HTTPXFORWARDED_FOR header for example.

Use this with caution and only if your website is behind a reverse proxy like vernish ... and if not don't trust only headers :)