Espace membre

Version imprimable

Voir 40 message(s) de cette discussion en une page

07/08/2004, 21h30
Swoög

Citation:

Envoyé par m@

:ccool: pas mal du tout !

:merci:

Citation:

1 -> as-tu eu le temps de faire 2/3 benchs entre crack et ton script ?

non, je suis sûr deux projets en même temps là :?.... désolé, mais je ferai des bench, j'en ai des sûr les include à faire aussi

Citation:

2 -> je rajouterais des mixs avec les nombres

je vois pas trop où... là je test la présence des chaînes dans le pass... si on met des nombres au milieu, comme ça casse, ça renforce le mot de passe...

Citation:

3 -> plutôt que d'essayer les différents mélanges nom/prénom à la main, je ferais plut^tot un ereg sur le nom et le prenom

bonne idée, (ch'uis vraiment stupide parfois... :?)

Citation:

4 -> sub0 >> pour les commentaires, je les mettrais plutôt après les variables, avis perso.

http://sub0.developpez.com/+1.gif

Citation:

5 -> une étude très intéressante sur les pswd : http://www.klein.com/dvk/publications/passwd.pdf

cordialement

voyons ça .....;);)
07/08/2004, 22h03
Sub0

Citation:

Envoyé par m@

pour les commentaires, je les mettrais plutôt après les variables, avis perso.

Citation:

Envoyé par Swoög

http://sub0.developpez.com/+1.gif

J'ai justifié pourquoi je les ai mises avant (pour éviter le décalage). Et vous? Ya-t-il une raison particulière ou c'est juste pour le côté esthétique du code?
07/08/2004, 22h05
Swoög

Perso juste le côté esthétique, et l'habitude que le code soit avant les commentaire.....
07/08/2004, 22h10
Sub0

ok. Dans ce cas, comme nous prevoyons de faire un script d'install au final, on mettra les commentaires après le code.
Je reconnais que j'ai aussi l'habitude d'avoir le code avant... :)
07/08/2004, 22h24
m@

l'habitude aussi
pour l'esthétique, ça rend en effet mieux devant :wink:
07/08/2004, 23h14
Sub0

Merci à tous les deux pour votre aide!
Voici la liste des améliorations à apporter pour la V2. En gris, ce qu'il reste à faire...
http://sub0.developpez.com/html/maj_v2.htm
Si vous voulez participer pour réaliser l'une de ces tâches, contactez-moi! ;)
Très cordialement, sub0
07/08/2004, 23h23
Swoög

Je viens de regarder la liste, je pense pouvoir m'occuper des points :

2/6/9/10/23 et 24

plus également, les 16 et 17 je pense...

Si ça convient, me le dire ;) Merci :D
08/08/2004, 00h22
m@

je ne promets rien, je passerai en dernier s'il reste vraiment des trous à boucher :wink:
09/08/2004, 06h56
Sub0

Salut!

Nous avons "tchatté", Bob, Swoög et moi à propos de la sécurité...
Voici un petit résumé de notre discution:

Pour obtenir une sécurité optimale, il est indispensable de ne pas fournir le mot de passe par mail;
• Le mot de passe sera donné sur le site à l'inscription.
• Un mail permettant d'activer le compte sera envoyé au membre.
• Les mails ne devront jamais contenir d'hyperlien;
Les membres devront se connecter au site et fournir l'identifiant d'activation contenu dans le mail.
• En cas de perte de mot de passe, le membre devra répondre à une question secrète;
Lors de son inscription, le membre devra donc choisir dans une liste une question et y répondre.
• Je suppose qu'il faudra crypter tout ça dans la bdd...

A propos, je suis à la recherche d'une source Delphi d'encryptage/décryptage RSA,
ou bien je vais être obligé de convertir le code du script PHP...

Si vous avez des remarques, des suggestions, des questions, n'hésitez pas! ;)

Cordialement
09/08/2004, 10h13
Koo

salut
je vient de lire unpeu les 2 derniere pages post, et je suis d'accord sur qui a été dis sur les chiffres dans le mot de passe et la lib crack.

Je pense aussi que ca serait pasmal de s'inspirer de windoz server et ca gestion des comptes utilisateurs. Par exemple, conserver l'historique des X derniers mots de passe, imposer une durée de vie etc ...

Un autre point qui n'a pas été évoqué pour l'instant et qui va généralement de paire avec l'authentification, c'est les droits de l'utilisateur.
Deja au sein d'ESPMEM, on pourrai distinguer un admin supreme, des modérateurs qui pourrait pas exemple suspendre des comptes, et les utilisateurs.
Ensuite pour l'application qui utilise ESPMEM, des fonctions toutes pretes pour vérifier les droits, les champs qui vont bien dans la table...
Est-ce que vous pensez que ca serait intéressant de rajouter ca, ou alors ca cadre pas trop avec l'application actuelle ?

Bon c'est con, mais créer un cookie pour conserver le login ou login + mdp (ou pas de cookie, c'est à l'admin de décider)

Un petite option qui pourrait être envisageable aussi, c'est que l'utilisateur puisse spécifier une liste d'IP pour son compte. Si l'ip du client qui tente de se logger est différente de celle spécifiée, l'accès est réfusée. Ca peut etre util par exemple si on est derrière un proxy, ou dans une appli intranet où chaque poste a une IP fixe.

et juste sur l'histoire des commentaires après le code, je trouve ca assez étrange, d'ailleur quand on commente une fonction c'est toujours en entete et jamais a la fin. Ca risque d'en perturber plus d'un :?
09/08/2004, 11h35
Sub0

Salut KoO!

Nous avons une bonne liste de modifs pour la V2! ;)

Effectivement, les options que tu proposes (l'historique des mdp, durée de vie, etc) sont biens!
Faut voir si elles sont vraiment utiles dans notre cas...

En ce qui concerne les droits d'utilisateurs, c'est une excelente idée aussi! Ce sera pour la V3. ;)

Pour la création d'un cookie, nous l'avons éliminé d'office pour des raisons de sécurité, mais c'est à l'admin d'en décider en effet!
A prévoir pour la V3...

Pour une liste d'IP, l'idée est intérressante je trouve! Pour la V3 aussi...

Et pour les commentaires avant ou après, il sagit de commenter l'utilité des paramètres.
J'avais envie de les mettre avant pour éviter le décalage lorsque l'admin définirait ses paramètres:

Code:

$cfg['site_name'] = 'Mon site'; // Nom de votre site

ou bien:

Code:

/* Nom de votre site */ $cfg['site_name'] = 'Mon site';

Merci!
09/08/2004, 11h59
Koo

a ok ct commentaire juste pour les variables, j'avais pas capté. Ue dans ce cas la, plutot

Code:

$cfg['site_name'] = 'Mon site'; // Nom de votre site

:wink:
09/08/2004, 12h06
Sub0

oui, j'ai précisé justement car il me semblait bien que tu avais confondu avec l'en-tête des fonctions... ;)

Au niveau de la gestion des comptes utilisateurs, ya-t-il d'autre comme option intérressante à part l'historique des mdp et la durée de vie d'un mdp...?
09/08/2004, 12h08
Swoög

Si un compte est souvent "attaqué"

on peut peut-être proposé à l'utilisateur de changer de "login'"

désolé pour hier soir : pb de connexion :(
09/08/2004, 12h11
Sub0

Comme l'admin recevra un mail d'alerte au bout d'un certain nombre d'echec d'identification, il pourra prendre des mesures... (blocage de l'IP du pirate, changement de login pour le membre, ...). Je ne pense pas que l'on ait autre chose à ajouter à ce niveau, non? Enventuellement, une blacklist d'IP... et à l'inverse, comme vient de le proposer KoO, une liste d'IP exclusives...

pas de pb! J'ai fais le résumé de notre discution! ;)
11/08/2004, 17h35
wamania

Salut sub0
Désolé de ne pas avoir donner de nouvelle avant.
Je ne pourrais pas tester et te donner les dernieres classes avant fin aout, desolé.
Cependant, tu as ce qu'il faut pour commencer (la classe MySQL fonctionnelle), il suffira juste de mettre les autres dans le repertoire fait pour.
Pour le regroupage des fichiers, il y a un moyen simple, il suffit d'include ou tu veux (dans fonction.php par exemple) la classe que tu veux, c'est à dire qu'au lieu de déclarer $bdtype = 'mysql', puis dans db.php inclure mysql.php, tu peux directement include mysql.php, ou celle que tu veux, et virer db.php.
Voila, je continue à bosser dessus (sur les classes), mais je ne donnerais pas de nouvelles avant fin aout.
Bonne continuation
11/08/2004, 17h54
Faaalllllling

Au pire ya toujours Pear::DB qu'est pas mal ou bien les classes phpBB
14/08/2004, 00h57
Sub0

Salut!

En ce qui concerne l'intégration de différents types de bdd, ce sera prévu pour la V3. Donc, Wamania, tu as le temps de pofiner. En fait, tu le verras dans la V2, j'ai choisi de faire au plus simple: Un fichier PHP par type de base. Chaque fichier contiendra les 6 fonctions dont nous avons besoin actuellement:

• Debug
• OpenBase
• CloseBase
• Query
• Fetch_Array
• Num_Rows

Par exemple, unitbdd1.php pour MySQL, unitbdd2.php pour MSSQL, unitbdd3.php pour PostGreSQL, etc...
Il suffira d'inclure le script correspondant à la base de données souhaitée.
En effet, nous n'avons pas besoin d'utiliser de classe pour la base de données, puisque nous utilisons qu'une seule instance (1 base, 1 table, 1 connexion). Je pense que cela sera plus simple à gérer au final, surtout pour le développement du type de bdd avec fichiers.
Si vous avez des remarques, n'hésitez pas! ;)

Très cordialement
16/08/2004, 14h18
Sub0

Salut!

J'ai pas mal progressé, presque fini:
http://sub0.developpez.com/html/maj_v2.htm

Citation:

N°6 - Lorsque La création du compte échoue, ne pas afficher le mess d'erreur et le lien pour revenir en arrière, mais l'ancien formulaire + le message d'erreur, ça fait une page de moins à télécharger pour l'utilisateur.

Pas bonne idée finalement. On trouvera sans doute une meilleure solution, comme l'affichage des messages dans un div centré par exemple (avec Javascript).

Citation:

N°7 - Ajouter une option pour afficher les erreurs en JS avec alert().

On revient à la même solution que pour la tâche N°6... De plus, la N°12 permet de vérifier la saisie des champs avant l'envoi du formulaire. La fonction alert() est utilisée pour afficher les erreurs, mais j'aimerais plutôt utiliser un div centré là aussi...

Citation:

N°8 - Commenter les champs de la base dans la doc. Et faire une doc des fonctions genre phpdocumentor.

Quelqu'un serait-il intérressé pour faire la N°8?

Citation:

N°17 - Ajouter session_regenerate_id() pour lutter contre les vols de sessions.

idem

Citation:

N°18 - Ajouter une option "grain de sel" (nombre) pour augmenter la dureté du mdp dans le cas d'un mdp choisi par le membre.

Reportée pour la V3

Citation:

N°20 - Ajouter un formulaire permettant de configurer l'application.

idem

Citation:

N°22 - Chiffrer avec JS l'envoi du mot de passe au serveur (md5+permutation).

Arf! Je préfère plutôt insister sur la nécessité d'utiliser SSL, non? Qu'en pensez-vous?

à+
16/08/2004, 14h48
Swoög

Salut !

OK avec toutes les propositions, et surtout la dernière, pour la N°17, je peux essayer de le faire, en fait, il faut ajouter un regenerate_id(); au début de chaque page page utilisant les sessions (après chaque session_start() quoi ?)

C'est bien ça ???

pour la N°20, même si elle est reportée, je pense que pour l'adapter, il sera plus facile de faire "comme phpBB", àa savoir, stocker la configuration dans une table de BDD...

Comme ça ça sera plus simple à modifier, qu'un fichier....

Voir 40 message(s) de cette discussion en une page