Vaya, dos maneras diferentes... Me gustaría probar las dos para ver que tal, pero tengo algunas dudas:

1º ¿Donde tengo que poner este codigo? Perdonar mi ignorancia

    if(isset($_SERVER['PATH_INFO']))
    $rutaInfo = trim((string)$_SERVER['PATH_INFO'], '/');
 
    elseif(isset($_SERVER['ORIG_PATH_INFO']))
    $rutaInfo = trim((string)$_SERVER['ORIG_PATH_INFO'], '/');

2º El metodo redirigiendo a entry.php,  que pasa en el caso de usar un archivo.php que existe para usar un link? Por ejemplo, si test.php existe y escribo test.php/site/login: daria error, no?

Porque cualquier cosa que escribas se redirige a entry.php y se compara con la lista? O solo se compara lo que hay despues de ?, o de esta manera se compara todo lo que escribas despues de la url? awww.site.com/'---> a partir de aqui se compara todo?

Volvemos a lo de antes, que pasa con las variables como login.php?error=1?? se seguirian ejecutando? site.com/site/login&error=1?

Gracias!

¿Por que no funciona esto?

	preg_match('/^([\w\/]+)=?(\w+)?&?/', $_SERVER['REQUEST_URI'], $matches);
	$matches[1] = isset($matches[1]) ? $matches[1] : null;

Es más complicado de lo que parece porque index.php es lo que llama la estructura y esta llama los views. Si se cambia de pagina ya no funcionaria...

Lo intento de ese modo porque me gustaría tener el tipo de links -> site.com/site/login&error=1 y que funcionara.

Lo siento fallo mio, si que funcionaba, se me olvido el .htaccess

Lo unico es que en lugar de entry.php uso index.php.

function showContent() {
	$views						= 'views/';
	$site						= $views . 'site/';
	$user						= $views . 'user/';
 
	if($_SERVER['REQUEST_URI'] == '/')
		$_SERVER['REQUEST_URI'] = '/home';
 
	$includes = array(
		'/home'					=> $views . 'home.php',
		'/login'				=> $site . 'login.php',
		'/logout'				=> $site . 'logout.php',
		'/contact'				=> $site . 'contact.php',
		'/about'				=> $site . 'about.php',
		'/register'				=> $user . 'register.php',
		'/referral'				=> $user . 'referral.php',
		'/friend'				=> $user . 'friend.php',
		'/register_success'			=> $user . 'register_success.php'
	);
 
	preg_match('/^([\w\/]+)=?(\w+)?&?/', $_SERVER['REQUEST_URI'], $matches);
	$matches[1] = isset($matches[1]) ? $matches[1] : null;
 
	if(array_key_exists($matches[1], $includes)){
		$content = include($includes[$matches[1]]); 
	} else $content = "Error 404";
	return $content;
}
 

Y efectivamente los links son: site.com/login?error=1

Al final de la manera mas simple posible, directamente el nombre del archivo, sin carpeta.

¿Podrías decirme alguna manera de comprobar si es vulnerable? Como por ejemplo lo de poner una larga cadena de caracteres y crear agujeros de esos. ¿O no se puede si hay una whitelist?

¿Te refieres a que funcionen los links con el index.php? Si es eso, es justo lo que no queria, usar nombres completos, el objetivo era este, con un simple nombre sin extension llamar la pagina.

Asi tal cual lo tengo funciona perfectamente.

Permitir solo de la A a la Z mas - y _ no es irse por lo que debería ser, de hecho te contradices en parte ya que con ese filtro te estás saliendo de norma, que tal si una carpeta se llama por ejemplo admin.mensajes ? según tu modelo dejará de funcionar. Tanto en los sistemas Unix como Linux y Windows tienen diferentes estándares en cuanto a que carácter es permitido como nombre de carpeta y nombre de archivo, por lo cual si tu haces un desarrollo no estandarizado omitiendo caracteres que si están permitidos por el sistema entonces dejará de ser una aplicación escalable ya que otros desarrolladores o el mismo administrador del sistema no podrá utilizar el sistema de archivos común del mismo sistema operativo. Recuerda que un directorio o archivo puede incluir incluso caracteres como acentos, espacios en blanco, puntos, signos especiales, paréntesis, arrobas, etc.

Bajo este contexto mi modelo es el mas eficiente porque cumple con todos los estándares de posibles reales carpetas y archivos bajo una lista blanca como únicos permitidos y sin la necesidad de tener que modificar el código si agregas secciones nuevas, tampoco usa expresiones regulares, o sea, usa menos memoria, menos cpu, menos lineas de código, no es vulnerable, o sea tal como dijiste tu, irse por lo que debería ser en ves de estar evitando lo que no es, no se porque aun le dan tantas vueltas al tema buscando opciones menos inseguras, mas pesadas y con problemas de seguridad.