Le code en lui-même n'est pas si crade que ça. Ton problème c'est plutôt le raisonnement, et apparemment tu en es bien conscient 
Ce n'est pas un hasard si un serveur s'appelle un serveur. Les navigateurs sont aussi parfois appelées clients web. Fais la comparaison avec un bar : il y a les clients, qui font des « requêtes » (ils commandent quelque chose) et le serveur « répond » avec les boissons demandées.
Le Web c'est pareil : ton navigateur fait des requêtes et le serveur apporte du contenu. Le contenu en l'occurence, c'est l'information dans la bdd qui indique si le client suit ou ne suit pas actuellement. Lors d'une première connexion (le client entre dans le bar), le client n'est pas censé connaître cette information : il doit la demander au serveur. Ensuite, s'il apprend qu'il est en train de suivre, il fait la demande de ne plus suivre ; dans le cas contraire il demande à suivre.
La première connexion correspond à la requête non Ajax que fait ton navigateur pour obtenir la page entière. À ce moment, ton serveur doit envoyer l'information « l'utilisateur suit » ou « l'utilisateur ne suit pas », mais pas les deux. Tu n'as qu'un seul formulaire à générer (au lieu de 6
dans ton code actuel !).
Les requêtes suivantes sont faites en Ajax. En réponse à ces requêtes il est important que le serveur informe le client de sa nouvelle situation : s'il est à présent en train de suivre ou pas. Ainsi le client peut mettre à jour son affichage pour que l'utilisateur (l'humain qui utilise le client) soit informé de la réussite ou de l'échec de la requête, et aussi mettre à jour l'adresse à laquelle envoyer la prochaine requête (scripts/follow.php ou scripts/unfollow.php).
Comme dans un bar, c'est le client qui choisit ce qu'il consomme (quelle requête envoyer), mais c'est le serveur qui manipule les boissons (l'information dans la bdd).
Edit:
Aouch. 
En faisant ça tu t'exposes exactement aux mêmes failles de sécurité qu'avec l'ancienne directive register_globals. Explications ici.
Un exemple utilisant ton code : en supposant que j'ai accès à ton site, je tape cette adresse dans mon navigateur :
unfollow.php?login='%20OR%20TRUE%3B%20--
Le morceau bizarre est la forme URL-encodée de la chaîne "' OR TRUE; --". Avec ton extract, cela va devenir le contenu de ta variable $login. Maintenant regarde ta requête SQL :
"DELETE FROM friends WHERE follower='".$login."' AND friend='".$loginpage."'"
Avec ce que j'ai mis dans $login, la requête devient :
DELETE FROM friends WHERE follower='' OR TRUE; --' AND friend=''
Tu devines ce qui va se passer ? Ce qui suit les tirets -- est considéré comme un commentaire : c'est ignoré. La clause OR TRUE dans le WHERE est vraie tout le temps. Autrement dit, le DELETE va s'exécuter sans condition, la table entière va être vidée !
Comme tu le vois ce n'est pas compliqué de trouver un pattern d'injection SQL. Et encore, moi je ne suis qu'un petit vandale, je ne connais que les astuces pour détruire. Imagine ce qu'un vrai pirate est capable de faire – consulter la config de ton serveur SQL, insérer du contenu piégé, etc.
Tu le sais sans doute, ce genre d'attaque s'appelle un injection SQL. Pour t'en protéger, utilises des requêtes préparées ou échappe tes variables avant des les insérer dans tes requêtes.
Partager