Fil wrote:
serait-il possible que l'authentification par cookie soit considérée
comme au moins aussi "sûre" que l'auth actuelle si on avait la situation
suivante:
Oui, et même largement plus sûr en le couplant avec un MD5 calculé en Javascript.
Le seul truc chiant, c'est que ça rend les cookies obligatoires.
Oui, et même largement plus sûr en le couplant avec un MD5 calculé
en Javascript.
Le seul truc chiant, c'est que ça rend les cookies obligatoires.
Et si on passait par une session, avec identifiant en Cookie si
possible et URL sinon ???
-Nicolas
Et si on passait par une session, avec identifiant en Cookie si
possible et URL sinon ???
Pour ça, il faudrait généraliser l'utilisation de la classe Link
pour passer l'identifiant de session automatiquement. Le problème,
c'est que c'est un gros boulot qui ne se fait pas tout seul 
@ Antoine Pitrou <antoine@rezo.net> :
Pour ça, il faudrait généraliser l'utilisation de la classe Link
pour passer l'identifiant de session automatiquement. Le problème,
c'est que c'est un gros boulot qui ne se fait pas tout seul
D'autre part, ça ne marchera pas dans l'espace public (le ccokie, oui, mais
la variable de session... hum)
-- Fil
@ Antoine Pitrou <antoine@rezo.net> :
Pour ça, il faudrait généraliser l'utilisation de la classe Link pour
passer l'identifiant de session automatiquement. Le problème, c'est
que c'est un gros boulot qui ne se fait pas tout seulD'autre part, ça ne marchera pas dans l'espace public (le ccokie, oui,
mais la variable de session... hum)
Avec la méthode actuelle, ça ne marche pas non plus dans l'espace public.
@ Antoine Pitrou <antoine@rezo.net> :
Avec la méthode actuelle, ça ne marche pas non plus dans l'espace public.
Avec la méthode définie dans inc_auth_cookie_1.4, le cookie est posé
directement par inc_auth ; évidemment, il faudrait envoyer le cookie à poser
à spip-cookie.php3 pouir qu'il le pose depuis la partie publique, mais ça
n'est (presque) rien à ajouter. inc_auth_cookie_1.4 reste pour l'instant un
hack, pas un développement complet.
-- Fil
Et si on passait par une session, avec identifiant en Cookie si
possible et URL sinon ???Pour ça, il faudrait généraliser l'utilisation de la classe Link
pour passer l'identifiant de session automatiquement. Le problème,
c'est que c'est un gros boulot qui ne se fait pas tout seul
Donc il faut s'y mettre à plusieurs, une fois qu'on aura une gestion
de session, on pourra améliorer plein de trucs ...
Tu as fait une ch'tite doc sur cette classe ???
-Nicolas
Donc il faut s'y mettre à plusieurs, une fois qu'on aura une gestion de
session, on pourra améliorer plein de trucs ...Tu as fait une ch'tite doc sur cette classe ???
Heu, non, mais le code est relativement commenté (dans inc_version).
En gros :
- deux possibilités de constructeur :
-> $link = new Link(url) pour pointer vers une URL donnée
-> $link = new Link() pour pointer vers la page courante (en récupérant
toutes les variables CGI (GET ou POST))
- ajouter une variable :
-> addVar(nom, valeur) : une variable normale (recopiée dans une
autre URL seulement si on appelle le constructeur sans paramètre)
-> addSessionVar(nom, valeur) : une variable de session (toujours
recopiée d'une URL à l'autre)
-> addTmpVar(nom, valeur) : une variable temporaire (recopiée d'une
URL à l'autre dans la limite de cinq variables temporaires
(utilisé pour l'affichage par tranches, peut servir pour des
onglets, etc.))
- récupérer le lien final :
-> getUrl() : retourne l'URL
-> getHref() : idem avec un href=".." autour
-> getForm() : retourne le début de formulaire correspondant
(i.e. ouverture du <form> et création des entrées de type hidden)
a+
Antoine.
Hello,
Donc il faut s'y mettre à plusieurs, une fois qu'on aura une
gestion de session, on pourra améliorer plein de trucs ...
Avant de se lancer dans ce (gros) chantier avec la classe Link, ne
serait-il pas temps de lancer une 1.4 stable ???
-Nicolas
@ Nicolas Hoizey <nhoizey@phpheaven.net> :
Avant de se lancer dans ce (gros) chantier avec la classe Link, ne
serait-il pas temps de lancer une 1.4 stable ???
Bah, il faudrait qu'elle soit terminée, c'est loin d'être le cas :
- interface docs attachés un peu pourrie
- pas de documentation
- restent des trucs dans la TODO
- il paraît qu'il y a un bug avec les rédacteurs (leurs articles seraient
direct à la poubelle) ???
- et j'en oublie
-- Fil
Avant de se lancer dans ce (gros) chantier avec la classe Link, ne
serait-il pas temps de lancer une 1.4 stable ???Bah, il faudrait qu'elle soit terminée, c'est loin d'être le cas
Oui, mais justement, même si le passage aux sessions est un point qui
m'intéresse tout particulièrement, comme des abstractions de BDD et
Auth, je pense qu'il faut mieux arrêter là les modifs fonctionnelles
et finir ce qui est en cours plutôt que se lancer dans un nouveau
chantier qui risque de tout bouleverser.
-Nicolas
Fil wrote:
Bah, il faudrait qu'elle soit terminée, c'est loin d'être le cas :
- interface docs attachés un peu pourrie
A propos, un nouveau site qui utilise les docs attachés de la beta :
> serait-il possible que l'authentification par cookie soit considérée
> comme au moins aussi "sûre" que l'auth actuelle si on avait la
> situation suivante:Oui, et même largement plus sûr en le couplant avec un MD5 calculé en
Javascript.
Autre idée, loufoque peut-être, mais garantie quasi absolue de sécurité :
une des images de ecrire/ est donnée par un fichier php dans la racine, qui
pose un nouveau cookie à chaque fois (et change le numéro de session dans la
base).
Ainsi même si on se fait piquer *son cookie* et *son numéro IP* *alors qu'on
est logé* (trois grosses conditions quand même !), il suffit d'un clic dans
ecrire/ pour zapper la session du pirate.
Je ne sais pas si vous voulez franchir le pas de l'auth_cookie pour la 1.4
ou plus tard, moi ça m'est égal en tous cas...
Le seul truc chiant, c'est que ça rend les cookies obligatoires.
Je ne vois pas en quoi ça pose un problème.
-- Fil
Fil wrote:
Autre idée, loufoque peut-être, mais garantie quasi absolue de sécurité :
une des images de ecrire/ est donnée par un fichier php dans la racine, qui
pose un nouveau cookie à chaque fois (et change le numéro de session dans la
base).
Non, à cause du cache du navigateur.
Autre idée loufoque : on peut peut-être stocker ce cookie, avec l'id_auteur
et l'heure de dernière connexion dans une table temporaire mysql?
Oui.
Le seul truc chiant, c'est que ça rend les cookies obligatoires.
Je ne vois pas en quoi ça pose un problème.
Bah.
>une des images de ecrire/ est donnée par un fichier php dans la racine,
>qui pose un nouveau cookie à chaque fois (et change le numéro de session
>dans la base).Non, à cause du cache du navigateur.
Bah ! toi même... Tu appelles /spip_session.php3?session=$session et il te
pose un nouveau cookie, donc un nouveau $session au prochain tour.
-- Fil
Fil wrote:
Bah ! toi même... Tu appelles /spip_session.php3?session=$session et il te
pose un nouveau cookie, donc un nouveau $session au prochain tour.
Et si j'ai deux fenêtres ouvertes et qu'elles ne sont plus synchrones ?
(je vais y arriver..... héhé )
Le seul truc chiant, c'est que ça rend les cookies obligatoires.
Je ne vois pas en quoi ça pose un problème.
Comment font les pauvres utilisateurs non informaticiens qui ont
installé IE6, qui refuse par défaut la plupart des cookies ?
Le mieux, je le répète et je l'affirme, c'est d'utiliser des sessions,
que ce soit par cookie ou URL ...
-Nicolas
Et si j'ai deux fenêtres ouvertes et qu'elles ne sont plus synchrones ?
(je vais y arriver..... héhé )
t'as gagné ! Bon, je committe une correction du méga bug qui interdisait
aux simples rédacteurs de créer un article à partir d'une rubrique (pourqoi
était-il revenu celui-ci ??) et un nettoyage de la TODO, et (à mon avis) la
1.4 est prête. Même si je ne suis pas très content de l'interface documents
(qui pourrait reprendre des choses genre "bouton Retour" au lieu du menu du
brouteur et/ou du lien "documents de l'article machin", etc. - mais mes
compétences en interface sont proches de zéro)
-- Fil
Fil wrote:
t'as gagné ! Bon, je committe une correction du méga bug qui interdisait
aux simples rédacteurs de créer un article à partir d'une rubrique (pourqoi
était-il revenu celui-ci ??)
Heu.... ça doit être le naturel....
> et un nettoyage de la TODO, et (à mon avis) la
1.4 est prête.
Reste le paramétrage des types de documents dans la config.
> Même si je ne suis pas très content de l'interface documents
(qui pourrait reprendre des choses genre "bouton Retour" au lieu du menu du
brouteur et/ou du lien "documents de l'article machin", etc. - mais mes
compétences en interface sont proches de zéro)
Il faudrait un lien pour visualiser le doc, mais je ne sais pas où le caser.
Reste le paramétrage des types de documents dans la config.
Euh, ça peut attendre... car à ce moment-là il faudra avoir aussi des
"templates" pour les différents documents, en particulier le flash, ça a
l'air assez coton.
Il faudrait un lien pour visualiser le doc, mais je ne sais pas où le caser.
à côté de la case de changement de titre, àmha
-- Fil