Nap a écrit 3207 commentaires

quelle largesse !

on pourrait imaginer une petite boite te demandant si tu veux installer le theme pour l'utilisateur courant ou pour tous, et te demandant le mot de passe administrateur dans le deuxieme cas.

c'était un hommage

Je viens de lire l'article, première chose la feuille de style est superbe, et les explications très claires.

sinon, j'ai fais la même install chez moi, mais je rencontre un probleme avec thunderbird en imap. Seul le dossier inbox existe, pas la poubelle ou le dossier envoyés, et je me prends plein d'erreurs rien qu'en envoyant un mail, quand il veut le déplacer dans envoyés. De plus il affiche des dossiers qui en fait n'existent pas, et lorsque je clique dessus il me dit "vous n'êtres pas abonné au dossier" ou un truc du genre
il faut dire que je ne connais pas bien IMAP

quelqu'un peut m'aider ou m'expliquer ce qui ne va pas ?

monstrueuse, cette esquive de troll. Du grand art !

zut je suis grillé :o)

Bah si t'es pressé et que tu tolère des bouts de codes pas toujours très propres générés par un IDE, pourquoi pas.

Un IDE ça sert pas qu'à générer du code, tu peux très bien utiliser un IDE en tapant tout toi même.
L'avantage est l'intégration de l'éditeur, du compilateur, du débuggeur, le browser de classes, les méta données qui permettent la complétion automatique... I.D.E. quoi :)

Comme XP ?

mais pour atteindre cet objectif il ne faut pas partager la bande passante mais modifier la priorité des paquets. Si les paquets des connexions ssh sont placés directement en tête de la file d'attente, ils passent sans problème, non ?

plus intégristes que RMS et linus

Plus intégriste que linus, c'est pas dur :o)

on peut pas, ils sont à une install party dans les nuages

non ça je connais pas, désolé :(

mais bon tu as déjà des specs solides comme ça... et un système intéropérable, qui est Bien :)

http://linuxfr.org/journal/new.html(...)

bah tu peux conquérir le desktop avec une distrib basée sur debian... et là ls dons à debian sont bénéfiques

J'ajouterai que la croix gammée n'a pas été inventée par les nazis, ils l'ont reprise c'est tout. Je croyais d'ailleurs qu'ils en avaient inversé le sens

sinon il y a TuxConsole si il est triste...

En plus de ton 3) :

¤ parallèliser :
- le démarrage des services (ça me dérange pas que crond démarre en même tant que samba
- l'activation des interface réseau : sur ma débian, si le réseau wifi n'est pas dispo, il faut attendre le time out du dhcp, c'est trop naze

¤ démarrer le dm le plus tôt possible

Donc en fait, le principe c'est qu'on a un site A et un site B et que pour logguer il fait une requête vers le site Y qui va dire si l'utilisateur a donné le bon mdp etc. Je suppose que chacun de ces sites est sur un serveur différent.

La solution existe, elle s'appelle SAML, pour Simple Authentication Markup Language. Ce standard, basé sur XML, est promu par le consortium OASIS, et décrit dans différents documents ici :
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security(...)

De nombreux cas d'utilisation sont décrits, le tiens en fait partie.

Sinon tu as le système passport de MS :-) /o\

Sinon LDAP j'y connait rien et il parait que ça supporte pas du tout la charge.

Non tu n'y connais rien :)
Le modèle de données LDAP, utilisé conjointement avec des index, est environ dix fois plus performant que le modèle de données relationnel pour les requêtes de recherche.

Il est fait pour les données rarement mises à jour et souvent lues.

non, le modèle de données est différent, on ne peut pas appliquer à LDAP le modèle de données relationnel, ni même essayer de le traduire. Il faut repartir des specs initiales.

En LDAP, les données sont hiérarchisées : l'annuaire a une racine, sous laquelle on peut mettre d'autres entrées, sous lesquelles on peut en mettre encore d'autres. Tu te constitues donc un annuaire avec des branches en plaçant sous la racine un objet de type "unité organisationnelle", que tu appelles par exemple "users", sous lequel tu places tes utiisateurs, qui sont eux de type "inetOrgPerson"

Le type d'une entrée est une classe, qui définit quels attributs l'entrée doit ou peut implémenter. Selon la spécification de la classe utilisée, il n'est pas toujours obligatoire de renseigner une valeur (par exemple, le champ 'secretary' de inetOrgPerson n'est pas renseigné si la personne n'a pas de secrétaire), et on peut souvent renseigner plusieurs valeurs (par exemple si tu as plusieurs adresses email, tu renseigne plusieurs fois le champ mail.

Ce dernier concept (les attributs multi-valués) est étranger aux SGBDR et permet souvent d'avoir un équivalent d'une distribution des données sur plusieurs tables dans un SGBD (par exemple, pour renseigner toutes les adresses emails d'une personne tu devrais avoir une table personne, et une table mail avec ID_personne et email. Ici tout est dans les infos de la personne). De plus tu peux ainsi tout récupérer en une seule requête de recherche.

Une grosse différence est aussi le système d'authentification. Avec LDAP, toute entrée de l'annuaire peut servir d'identifiant, du moment qu'elle a un mot de passe (champ 'userPassword') ou quel est référencée dans le système d'authentification utilisé.
Donc c'est naturellement que tout utilisateur peut s'authentifier, grace à l'opération LDAP du bind. Inutile d'aller chercher dans la base qui a ce login et qui a ce mot de passe.

Euh... c'était quoi la question ? Ah, oui. Et bien, donne nous un exemple, on verra ce qu'on peut faire.
LDAP ne peut dans la plupart des cas pas remplacer une base de donées relationnelle. Il est fait pour être complémentaire de celle-ci, et principalement :
- stocker des informations (et non des relations)
- assumer la fonction d'authentification
- stocker les données d'autorisation (exemple : groupes, objets)

Donc si tes relations servent à autoriser des personnes à accéder à des fonctionnalités ou à des données, c'est transcriptible sous LDAP. Pour le reste, il faut voir dans le détail. Tu peux toujours utiliser dans ta base des références vers les identifiants LDAP des utilisateurs, et mixer les deux dans ton appli PHP.

Bravo les gars, je suis en manque de Atom Heart Mother maintenant :-/

Ca s'appelle du Single Sign-On.

Ça c'est pour la partie authentification. Pour le reste, ça s'appelle du provisionning.

si les applis font de l'authentification par cookie, ça doit être possible de générer le cookie à partir d'une autre appli, non ?

Pour ce genre de truc on utilise plutôt LDAP, les applis web commencent à le prendre en compte (SPIP par exemple)

Comme LDAP propose un schéma standard indépendant des applications, chacune peut s'y ratacher en ignorant les autres

Une interface web pour créer les comptes : phpLdapAdmin
Mais je ne crois pas qu'il permette à un anonyme de créer un compte, ce serait une améiloration intéressante

Le seul problème est qu'LDAP est rare chez les hébergeurs

pour le forum je te conseille fouletexte ( http://www.echodelta.net/scriptsphp/fouletexte/fouletexte.htm(...) ), il est très léger et s'intégre bien dans un site.
Un de mes projets est de le reprendre pour le faire passer en css et LDAP

tiens est-ce que vim gère l'utf8 ?

euh... c'est une encyclopédie

des fois il faut redescendre sur terre non ?