Bonjour,
Je constate que les redacteurs ont beaucoup de mal avec le terme
'mots cles' qu'ils associent systematiquement aux moteurs de
recherches, et dont ils ne percoivent pas l'utilisation en
navigation.
Idee : remplacer 'mots cles' par 'domaines' ou 'criteres' ou
'drapeaux' (flags) ou ...
A bientôt,
Philippe
Philippe Gouillou a écrit:
Bonjour,
Je constate que les redacteurs ont beaucoup de mal avec le terme
'mots cles' qu'ils associent systematiquement aux moteurs de
recherches, et dont ils ne percoivent pas l'utilisation en
navigation.Idee : remplacer 'mots cles' par 'domaines' ou 'criteres' ou
'drapeaux' (flags) ou ...
c'est vrai ! remplacer par ... thèmes ?
c'est vrai ! remplacer par ... thèmes ?
Le problème c'est que les mots-clés sont utilisés pour des trucs
un peu bizarres des fois, et que "thèmes" ne correspond pas du
tout (encore moins les autres termes proposés).
Salut,
J'ai remis la configuration de l'affichage des articles modifiés.
Comme ça ceux qui en ont besoin peuvent l'activer, et ça ne
pourrit pas l'interface pour les autres sites. C'est beaucoup
plus propre comme ça.
D'autre part, comme les avertissements "de sécurité" ne servent
à rien (impossible de savoir à quoi ils correspondent si on ne
sait pas comment fonctionnent les sessions de SPIP en interne),
ils sont désactivés par défaut. Si on veut pouvoir les activer
sur tout un site, il faut remettre l'option de config.
Mais je crois qu'il n'y avait que Fil qui y tenait... ?
Amicalement
Antoine.
A propos du "mythe de la corbeille" qui ne se viderait jamais...
Eh ben, heu, il semblerait que le mythe ait raison.
En fait il y a longtemps eu un bout de code qui supprimait
les anciens articles effacés, lors de la création de nouveaux
articles, mais visiblement ce bout de code a dû jarter à un moment
ou un autre. Pareil pour les brèves.
Je vais ajouter ça dans optimiser.php3.
D'autre part, comme les avertissements "de sécurité" ne servent
à rien (impossible de savoir à quoi ils correspondent si on ne
sait pas comment fonctionnent les sessions de SPIP en interne),
oui, c'est pas bon.
ils sont désactivés par défaut. Si on veut pouvoir les activer
sur tout un site, il faut remettre l'option de config.
Mais je crois qu'il n'y avait que Fil qui y tenait... ?
je m'attache à mes trois scénarios, qui se ramènent à deux en fait :
* "Gênes" ou "cybercafé" : en gros, tu ne t'es pas déconnecté et tu veux le
faire pour empêcher quelqu'un d'utiliser ton cookie de connexion qui
traîne sur un ordinateut auquel tu n'as plus accès
* "vol de cookie" : quelqu'un a placé un javascript malicieux dans un forum
ou dans un article proposé, et ton site doit passer en "mode parano" le
temps de ramener un peu de calme
Tout l'attirail mis en place correspond plutôt au "vol de cookie". Si on
limite le cookie à un fonctionnement "lié à un IP", ce problème disparaît.
Par contre, d'autres soucis apparaissent : connexions qui sautent par
intermittence. Une solution serait de lier la session à un IP, et de la
rendre "suspecte" si elle arrive sur un nouvel IP. Une session "suspecte"
donne toujours l'accès, mais fait s'afficher les infos de sécurité, avec un
bouton "C'est OK pépère, pas de souci, c'est ma connexion qui bouge", et un
autre "déconnecter, on n'est jamais trop prudent, avec ces voleurs de
cookies qui rôdent dans les parages".
Pour le scénario "cybercafé", il suffirait que le bouton "déconnecter"
déconnecte toutes tes sessions.
Non ? (Le système actuel est mauvais, trop lourd, pas clair, pas facile à
expliquer. Mais "mieux qu'rien". D'où le statu quo.)
-- Fil
Ca ne me gêne pas du tout qu'il y ait un réglage dans la config,
mais il faut que ce soit le mode laxiste par défaut 
Je te laisse faire...
Amicalement
Antoine.
A propos du "mythe de la corbeille" qui ne se viderait jamais...
Eh ben, heu, il semblerait que le mythe ait raison.
En fait il y a longtemps eu un bout de code qui supprimait
les anciens articles effacés, lors de la création de nouveaux
articles, mais visiblement ce bout de code a dû jarter à un moment
ou un autre. Pareil pour les brèves.
et pareil pour les messages des forums... et pour les auteurs a la poubelle ...:))
Salut,
J'ai ajouté un titre en survol aux puces de couleurs indiquant
le statut des articles, brèves et sites référencés. Ceci afin
de faciliter un peu la vie des daltoniens qui utilisent SPIP
(même si ce n'est pas aussi immédiat que de remarquer la couleur
de la puce... ;-)).
a+
Antoine.
Salut,
Tu pourrais aussi essayer de mettre l'information dans la luminance des
couleurs utilisé et non seulement dans leur chrominance.
Si le résultat reste esthétique, c'est bien, je pense...
C'est pas évident de repérer une luminance dans l'absolu.
Tu reconnais facilement une couleur "rouge" ou "bleue"
sans avoir besoin d'un élément de comparaison,
mais "lumineuse à 80%" ou "lumineuse à 60%", bof.
De plus, esthétiquement, ce ne sera pas équilibré :
certaines puces "flasheront" plus que d'autres.
Salut les spipeurs ! (c'est comme ça qu'on vous appelle ?)
Cette discussion a attiré mon attention (non en fait c'est mon robot qui
m'a signalé des mots-clefs interessants ! ... J'déconne !). Bref, je vais
aller droit au but. Je suis dans l'equipe de developpement de SpipIndy
(j'ai votre attention maintenant ? 
), le moteur pour sites indymedia
basé sur Spip, voir plus bas pour les url.Un de nos sujets de discussion actuels est justement axés autour des puces
pour daltoniens. Etant moi-meme daltonien je suis un petit peu le moteur
de cette discussion. J'avais proposé qu'on crée des puces differentes dans
la forme en plus de la couleur. Par exemple des carrés verts, des
triangles oranges, des ronds blancs,... Notre principale contrainte c'est
qu'on voulait se tenir à l'ecart des stereotypes habituels, car les puces
seraient utilisées dans notre cas pour signaler si tel ou tel article a
été validé ou non par un moderateur. Comme c'est un sujet assez
controversé on ne voulait pas en plus ajouter aux puces une connation de
"panneau danger" ou "point d'exclamation" (pour les oranges) et "V de
validé" ou "feu vert" (pour les vertes. On aurait preferé qq chose de
neutre. Qq chose qu'on n'a pas encore trouvé ! :)Votre idée des titres en survol n'est pas mal, mais elle a quand meme des
inconvenients. Impossible d'avoir une vue d'ensemble dès le premier coup
d'oeil, compatibilité relative entre les browsers et dynamicité (ou
bougeotte !) souvent critiquée par de nombreux webmasters... Enfin, ça
n'enleve pas que c'est une solution qui a le merite d'exister ! :)Vous n'avez jamais pensé à proposer des puces de forme differente ?
Qu'est-ce que vous en pensez de cette idée ?
Evidemment, je renouvelle mon invitation auprès de la communauté spip à
travailler en commun sur cette plateforme SpipIndy qui s'annonce pour
l'instant très fonctionnelle. Nous ne sommes pour l'instant que 3/4
développeurs mais nous avons bien envie d'agrandir notre communauté !
Sur ce, bonne soirée à tous !
Dario
URLs:
http://docs.indymedia.org/view/Devel/SpipIndy - page de convergence du dev
http://indy.medianice.org/spip/ - un site de test
http://lists.indymedia.org/mailman/public/imc-france-tech/ - notre ml
http://cvsweb.tuxfamily.org/cvs/spip/?cvsroot=indynice - cvs
>Eh ben, heu, il semblerait que le mythe ait raison.
>En fait il y a longtemps eu un bout de code qui supprimait
>les anciens articles effacés, lors de la création de nouveaux
>articles, mais visiblement ce bout de code a dû jarter à un moment
>ou un autre. Pareil pour les brèves.et pareil pour les messages des forums... et pour les auteurs a la poubelle
...:))
un seul mot à dire : LOL
Salut,
J'ai ajouté un titre en survol aux puces de couleurs indiquant
le statut des articles, brèves et sites référencés. Ceci afin
de faciliter un peu la vie des daltoniens qui utilisent SPIP
(même si ce n'est pas aussi immédiat que de remarquer la couleur
de la puce... ;-)).
Pourquoi ne pas utiliser des icones du type mozilla, indiquant si on est en ligne ou pas, on comprendrait facilement si la breve est publiée ou pas ? ou bien ya ca aussi :
stock ok et stock no
http://jimmac.musichall.cz/i.php3?ikony=40
???
* "vol de cookie" : quelqu'un a placé un javascript malicieux dans un forum
ou dans un article proposé, et ton site doit passer en "mode parano" le
temps de ramener un peu de calme
Bon, j'ai trouvé et implémenté la solution "vol de cookie", c'est cool : un
cookie qui serait présenté en provenance d'un nouvel IP est marqué
'ip_change'. Si ma session est 'ip_change', le javascript en bas de page
appelle le renouvellement de cookie. Mais on ne peut le rejouer que si on
est du bon IP !
Conclusion : si mon IP change, j'ai un cookie teinté 'peu sûr', mais il ne
change pas et je continue à être logé ; si mon IP ne change pas mais qu'il y
a un vol, le voleur ne peut pas le changer, mais il le teinte, et je le
rejoue : paf il est déconnecté. Et si mon IP change au moment où je me fais
voler le cookie, je suis cuit 
Pour le scénario "cybercafé", il suffirait que le bouton "déconnecter"
déconnecte toutes tes sessions.
En quoi est-ce gênant d'avoir ça en standard ? Si tu déconnectes pour
changer d'utilisateur sur un brouteur donné, il suffit de quitter et de
relancer le navigateur. Si tu appuies sur "déconnexion", toutes tes
connexions sont mortes. Simple et efficace.
-- Fil
> * "vol de cookie" : quelqu'un a placé un javascript malicieux dans un forum
> ou dans un article proposé, et ton site doit passer en "mode parano" le
> temps de ramener un peu de calmeBon, j'ai trouvé et implémenté la solution "vol de cookie",
Encore ??
c'est cool : un
cookie qui serait présenté en provenance d'un nouvel IP est marqué
'ip_change'. Si ma session est 'ip_change', le javascript en bas de page
appelle le renouvellement de cookie. Mais on ne peut le rejouer que si on
est du bon IP !Conclusion : si mon IP change, j'ai un cookie teinté 'peu sûr', mais il ne
change pas et je continue à être logé ; si mon IP ne change pas mais qu'il y
a un vol, le voleur ne peut pas le changer, mais il le teinte, et je le
rejoue : paf il est déconnecté. Et si mon IP change au moment où je me fais
voler le cookie, je suis cuit
Tout ça, ça présuppose que tu restes en permanence derrière ton écran
pour rejouer les cookies qu'on te vole au passage. Sinon, le voleur peut
utiliser le cookie tranquillement.
> Pour le scénario "cybercafé", il suffirait que le bouton "déconnecter"
> déconnecte toutes tes sessions.En quoi est-ce gênant d'avoir ça en standard ? Si tu déconnectes pour
changer d'utilisateur sur un brouteur donné, il suffit de quitter et de
relancer le navigateur.
Sur mon navigateur, j'ai plusieurs onglets et plusieurs fenêtres
ouvertes. J'ai pas envie de le fermer pour changer d'utilisateur ;))
Encore ??
Cette fois-ci c'est la bonne
Tout ça, ça présuppose que tu restes en permanence derrière ton écran
pour rejouer les cookies qu'on te vole au passage. Sinon, le voleur peut
utiliser le cookie tranquillement.
Pour qu'il te vole ton cookie, il faut que tu sois en ligne ! Evidemment, si
tu vas sur la page où il a placé son bug, et qu'après tu ne fais plus rien,
il a toute latitude pour faire ses trucs. Dans tous les scénarios c'est
comme ça, sauf vérification IP stricte, qui pose problème.
> > Pour le scénario "cybercafé", il suffirait que le bouton "déconnecter"
> > déconnecte toutes tes sessions.Sur mon navigateur, j'ai plusieurs onglets et plusieurs fenêtres
ouvertes. J'ai pas envie de le fermer pour changer d'utilisateur ;))
Ca ne posera pas de problème... tant que tu te limites à UN navigateur. Si
tu ouvres deux navigateurs en même temps sur les mêmes login, puis que tu
veux changer de login dans un seul navigateur... il faudra alors que tu
quittes celui dans lequel tu veux changer de login sans déconnecter l'autre.
Pas cher payé, à mon avis, pour une solution **entièrement transparente**.
Et le code est très simplifié, du coup !
-- Fil
Dans tous les scénarios c'est
comme ça, sauf vérification IP stricte, qui pose problème.
Moui enfin avec le nouveau truc, si tu as une IP tournante et que ton
brouteur prend mal les cookies depuis des images chargées en javascript,
c'est pas tip top.
Et le code est très simplifié, du coup !
Oui.
brouteur prend mal les cookies depuis des images chargées en javascript,
c'est pas tip top.
Ca peut arriver ça ? Qu'il n'appelle pas l'image, à cause de jaja, pourquoi
pas, mais qu'il l'appelle et que, à cause de jaja, il ne prenne pas le
cookie ? Pff. Il faut changer de navigateur alors.
Bon, je regarde le code qui permet à un rédacteur de supprimer des docs
joints dans les articles d'un admin, et c'est pas très marrant...
-- Fil
Ca peut arriver ça ? Qu'il n'appelle pas l'image, à cause de jaja, pourquoi
pas, mais qu'il l'appelle et que, à cause de jaja, il ne prenne pas le
cookie ? Pff. Il faut changer de navigateur alors.
Ben, à ton avis, pourquoi des gens avaient des problèmes avec la
sécurité stricte ?
Bon, je regarde le code qui permet à un rédacteur de supprimer des docs
joints dans les articles d'un admin, et c'est pas très marrant...
Tu peux rajouter des smilies dans le code 