2012-03-03 1 views
0

J'ai posé cette question avant here mais l'utilisateur CheekySoft fait remarquer que je « demande comment mettre en œuvre ma solution proposée » où au lieu que je devrais juste « exposer mon problème et demander des idées de solution » . Alors voilà.Besoin d'aide pour la mise en œuvre des sessions PHP dans suPHP

Sur le serveur linux je les fichiers mis en place comme si

/home 
├── user1 
│   ├── [-rwx------] index.html 
│   └── [-rwx------] index.php 
└── user2 
    ├── [-rwx------] index.html 
    └── [-rwx------] index.php 

Si j'ai des hôtes virtuels Apache mis en place à

<Directory /home/user1>` 
<Directory /home/user2> 

Alors, [tout] utilisateur peut aller à www.example.com/user1/index.html ou www.example.com/user2/index.html . Toutefois, les autorisations sur ces fichiers sont 0700, par conséquent, ils sont inaccessibles sur le Web. C'est pour cette raison que j'utilise suPHP.

Pour les besoins du raisonnement, laisse dire index.php a seulement ce qui suit dans ce

index.php:

<?php 
echo file_get_contents('index.html'); 
exit(); 
?> 

Maintenant, avec suPHP mis en place, user1 peut aller à www.example.com/user1/index.php pour voir index.html. De même, utilisateur2 peut aller à www.example.com/user2/index.php pour afficher index.html. Cependant, user1 peut également aller à www.example.com/user2/index.php pour afficher la page index.html de user2, et vice versa pour user2.

La manière naturelle de faire face à cela est à travers PHP sessions. Toutes les demandes à une page sont redirigées vers une page principale (par exemple www.facebook.com), l'utilisateur est validé par rapport à la base de données, puis redirigé vers la bonne page (voir l'image ci-dessous).

User Interaction diagram

Les utilisateurs iriez à une page (ie. www.example.com/page1.html), puis il y aurait une partie de la page 1 codée en dur pour assurer une session valide existe. S'il existe, la page est chargée. S'il n'existe pas, l'utilisateur est redirigé vers, dans ce cas, index.html. Après leur connexion et une session valide est établie, ils sont redirigés vers la page d'origine. Nous pouvons modifier index.php pour réaliser ceci:

indexValidate.php:

<?php 
//this is purely pseudo code, I can't guarantee it will work 
session_start(); 
require_once 'Session_Validator.php'; 
$sv = new Session_Validator(); 
$sv->validate($un, $pwd); 

echo file_get_contents('index.html'); 
exit(); 
?> 

Cependant, Dans ma conception, ces pages (page1.html, page2.html ...) sont dans les utilisateurs propre répertoire (index.html , index.php), par conséquent, le serveur ne peut pas exiger que cette section codée en dur vérifie une section valide. L'utilisateur peut simplement modifier le fichier pour supprimer cette section. Bien sûr, ce serait stupide de la part de l'utilisateur, mais je ne veux pas que l'utilisateur doive modifier chacun de ses fichiers pour avoir une section de vérification de session en haut. Je veux que ce soit transparent.

Quelques notes:

  1. Je peux utiliser Apache pour rediriger toutes requêtes à un seul script validateUser.php qui valide l'utilisateur puis, si elle est valide, appelle le script original demandé. Cependant, cela a pour effet secondaire que suPHP a déjà commuté à un utilisateur, très probablement var-www
  2. Je ne veux pas utiliser Apache web login authentication

Quelqu'un peut-il apporter une solution à mon problème?

+0

Je suis assez confiant ma question n'a pas de solution http://stackoverflow.com/a/9561335/654789 – puk

Répondre

1

Comment sur la création d'une règle de réécriture apache pour tous les utilisateurs et créer un seul emballage PHP pour toutes les HTML pages

Le RewriteRule pourrait être quelque chose comme:

RewriteCond %{REQUEST_URI} !^/auth 
RewriteRule ^(.*) /auth/wrapper.php?uri=$1 

Et wrapper.php:

  1. Vérifiez si l'utilisateur est validé. Sinon, rediriger vers /auth/validate.php?redirect=<where-I-came-from>
  2. Si elle est validée, chargez le fichier mentionné dans uri=<...>

    echo file_get_contents('<...>');

EDIT: Vous pouvez créer des liens symboliques vers la wrapper.php puis définissez les autorisations sur le lien symbolique à l'utilisateur. vous pouvez le faire dans le dossier auth:

ln -s wrapper.php username1.php 
chown -h username1:username1 username1.php 

Ensuite, vous wil obtenir un dossier comme celui-ci:

-r--r--r--. 1 var-www var-www 15 march 3 12:45 wrapper.php 
lrwxrwxrwx. 1 username1 username1 17 march 3 12:47 username1.php -> wrapper.php 
lrwxrwxrwx. 1 username2 username2 17 march 3 12:52 username2.php -> wrapper.php 
lrwxrwxrwx. 1 username3 username3 17 march 3 12:52 username3.php -> wrapper.php 

S'il vous plaît noter: L'utilisateur doit être capable de lire le répertoire auth Pour le rendre encore plus sécurisé, vous pouvez placer wrapper.php dans un répertoire séparé.

+0

J'ai essayé cela avant. Le problème est de savoir à qui appartient 'wrapper.php'? Si le propriétaire est apache alors 'wrapper.php' est exécuté en tant qu'utilisateur apache (je pense que c'est' www-data'), et * je pense * quand ce script essaie d'accéder, par exemple '/ home/user1/index. php', ce fichier a des permissions '0700' et un autre propriétaire, donc il ne peut pas l'exécuter (impossible de lire'/home/user1/index.html' pour la même raison). – puk

+0

Maintenant, je pourrais créer une classe wrapper pour chaque utilisateur, appartenant à l'utilisateur, ainsi quand suprise par l'utilisateur, suPHP exécute le script ** comme ** cet utilisateur. Mais alors comment puis-je empêcher l'utilisateur de modifier ce fichier (il est extrêmement sensible après tout)? Puis-je en quelque sorte mettre tous ces fichiers 'utilisateur' dans un répertoire séparé où l'utilisateur ne peut pas accéder, mais Apache peut? Vous pourriez être sur quelque chose. Un fichier peut-il appartenir à un utilisateur autre que le propriétaire du répertoire parent (répertoires collants exclus)? – puk

+0

Mais suPHP utiliserait-il le propriétaire du lien symbolique, ou le fichier réel? J'ai utilisé quelque chose comme ça: '/ etc/validator (var-www 0700)', '/ etc/validateur/user1 (var-www 0700)' et '/etc/validator/user1/validate.php (user1 0700)' . De cette façon, le fichier appartient à user1, mais parce que user1 n'a pas accès à 'validator /', ou 'user /', alors ils ne peuvent pas éditer le fichier =) – puk