@blowingfish : pas la peine de s'énerver

Ou as tu vu que je m'énervais ? Un échange d'argument ne se résume pas automatiquement à un énervement.

Mais c'est vrai qu'il faut voir le public cible pour mieux faire son application/site web

@blowingfish : pas la peine de s'énerver, autant laisser à taric indiquer l'environnement qu'il utilise. d'après ces poste je serais tenté de croire que ce qu'indique mazarini. Malheureusement cela n'est pas confirmer.

Maintenant a partir du moment ou c'est une connexion web tu ne peux être certain de la sécurité car la plus part des utilisateurs ne se déconnecte pas et là quelque soit la méthode c'est la même chose.
un LDAP, ce n'est généralement pas utilisé par un particulier, il doit donc y avoir une structure, peut être amenée a évoluée mais déjà définie et surement peux flexible (windows ou pas).

reste donc deux cas :
- un script JS ou autre permettant la pré selection de l'utilisateur dans le LDAP pour affichage dans le formulaire (pour windows avec le code de mazarini, pour nux ben je sais pas c'est surement possible d'avoir le nom d'utilisateur aussi)
- afficher un formulaire vierge.

dans les deux cas l'utilisateur devra rentrer son mot de passe à la main, car comme l'indique mazarini, si l'on peux récupérer le mot de passe (quel que soit l'OS) c'est une faille de sécurité version grand canyon

dans pour le coté automatique il ne peux (devrait) pas être complet.
Pour la reconnexion, la c'est une "simple" gestion d'espace membre, donc en laissant ou pas la possibilité de rester connecté (option que l'on trouve sur n'importe quel forum basique). la seule façon de faire que je vois c'est soit un cookie, soit retrouver le nom de l'utilisateur automatiquement et dans les deux cas sauvegarder le mot de passe LDAP quelque part (criptage et stockage dans une table de db par exemple).

donc globalement c'est pas super sécurisé de stocker un mot de passe et seul taric pourra nous indiquer les conditions d'utilisation de son appli avant de raler pour rien dans tous les sens (oui la plus part des entreprises utilises windows qu'on le souhaite ou pas et ne sont pas prête a changer pour tous un tas de raison dont on se fou ici )

@+

Lorsqu'on définit des cookies, on peut définir leur durée. On peut tout à fait leur dire de durer un an comme de durer pendant qu'une session. Ils deviendront alors périmés lors de la prochaine session et l'utilisateur devra donc se reconnecter. Et rappel : on ne stocke pas les logs

Alors ce n'est pas ça qu'il chercher. La personne devrait avoir la possibilité de rester connecter ou pas, quoi que tu peux facilement le faire même avec son script, donc mon argument est invalide. Cependant, cela n'empêche pas que ce script n'est pas du tout adapté pour la diversité du web, sauf s'il fonctionne sur toutes les OS (ce qui m'étonnerait vu la fonction).

Surtout que s'il se connecte sur un ordinateur public, il sera oubliger de nettoyer les cookies pour que le prochain utilisateur ne puise y accéder sans les log.

Lorsqu'on définit des cookies, on peut définir leur durée. On peut tout à fait leur dire de durer un an comme de durer pendant qu'une session. Ils deviendront alors périmés lors de la prochaine session et l'utilisateur devra donc se reconnecter. Et rappel : on ne stocke pas les logs

bon bon bon..., et avec le module mod_auth_sspi.so sur apache ? ça foncionne?

Mazarini ta donné la méthode tu n'as plus qu'a appliqué ! Pourquoi changer ? Pour les fonctions qui peuvent te servir, je suppose que si tu poses ta question dans PHP avancé, c'est que tu souhaites une solution PHP. Tu as donc en PHP la fonction http://php.net/manual/en/function.setcookie.php pour définir un cookie et ensuite pour les cookies ta la superglobale $_COOKIE['nom de ton cookie'] pour le lire.

bon bon bon..., et avec le module mod_auth_sspi.so sur apache ? ça foncionne?

Bonjour,

La première étape est de vérifier le script que j'ai trouvé sur un site via google :

<script type="text/javascript">
var WinNetwork = new  ActiveXObject("WScript.Network");
alert(WinNetwork.UserName);
</script>

Si tu fait une page html avec ce script, il doit afficher ton user windows dans une fenetre.

Dans la première page de ton application, tu contrôles que le user est renseigné (cookie ou session) ou qu'il est transmis en paramètre.
1) le code n'est pas renseigné et n'est pas en paramètre :
=> tu envoies une page qui exécute le code qui permet d'accéder au user et tu gères la transmission via un formulaire et se valide tout seule pour retourner à la première page avec le code en paramètre.
2) le code est en paramètre :
=> tu l'enregistres en cookie ou en session
3) le user est renseigné (via le 2 éventuellement) :
=> tu vérifie le user via LDAP
Ensuite, en début de chaque page, il faut que tu vérifie le user renseigné et que tu renvoies sur la première page éventuellement.

Pour un minimum de sécurité (pas infaillible), tu peux vérifier que le paramètre "user' est bien envoyé par la bonne page via le referer.

Je répète que c'est un très mauvaise idée de faire ça. Il n'y a pas que des utilisateurs Windows sur le web, garde ça en tête ! Surtout que s'il se connecte sur un ordinateur public, il sera oubliger de nettoyer les cookies pour que le prochain utilisateur ne puise y accéder sans les log.

Bonjour,

La première étape est de vérifier le script que j'ai trouvé sur un site via google :

<script type="text/javascript">
var WinNetwork = new  ActiveXObject("WScript.Network");
alert(WinNetwork.UserName);
</script>

Si tu fait une page html avec ce script, il doit afficher ton user windows dans une fenetre.

Dans la première page de ton application, tu contrôles que le user est renseigné (cookie ou session) ou qu'il est transmis en paramètre.
1) le code n'est pas renseigné et n'est pas en paramètre :
=> tu envoies une page qui exécute le code qui permet d'accéder au user et tu gères la transmission via un formulaire et se valide tout seule pour retourner à la première page avec le code en paramètre.
2) le code est en paramètre :
=> tu l'enregistres en cookie ou en session
3) le user est renseigné (via le 2 éventuellement) :
=> tu vérifie le user via LDAP
Ensuite, en début de chaque page, il faut que tu vérifie le user renseigné et que tu renvoies sur la première page éventuellement.

Pour un minimum de sécurité (pas infaillible), tu peux vérifier que le paramètre "user' est bien envoyé par la bonne page via le referer.

Bonjour,

Je doute que cela soit la meilleur façon, surtout qu'il n'y a pas que des utilisateurs Windows dans le grand monde de l'information (Linux pour ma part)

Je suis tout à fait d'accord avec toi. Par contre, utiliser un annuaire LDAP et de ne pas vouloir se connecter manuellement me fait penser à une application dans une entreprise. Le fait de vouloir utiliser le user de connexion comme identifiant me fait encore plus penser à une entreprise.

De la à en déduire que l'on est dans un environnement purement windows pour les utilisateurs devant utiliser l'application, il y a un pas que je me suis permis de franchir. Mon expérience des entreprises me conduit même à penser que la connexion va être faites sans trop se poser de question sur la sécurité. Mais une application de réservation n'a pas forcement un grand besoin de sécurisation ; en cas de réservation injustifiée/usurpée, le coupable se fera taper sur les doigts tout simplement.

Tout d'abord merci! Mazarini t'as tout compris, peu importe pour la sécu, peux tu juste mieux m'expliquer t'as manip stpp
Merci

Bonjour,

Je doute que cela soit la meilleur façon, surtout qu'il n'y a pas que des utilisateurs Windows dans le grand monde de l'information (Linux pour ma part)

Je suis tout à fait d'accord avec toi. Par contre, utiliser un annuaire LDAP et de ne pas vouloir se connecter manuellement me fait penser à une application dans une entreprise. Le fait de vouloir utiliser le user de connexion comme identifiant me fait encore plus penser à une entreprise.

De la à en déduire que l'on est dans un environnement purement windows pour les utilisateurs devant utiliser l'application, il y a un pas que je me suis permis de franchir. Mon expérience des entreprises me conduit même à penser que la connexion va être faites sans trop se poser de question sur la sécurité. Mais une application de réservation n'a pas forcement un grand besoin de sécurisation ; en cas de réservation injustifiée/usurpée, le coupable se fera taper sur les doigts tout simplement.

Je doute que cela soit la meilleur façon, surtout qu'il n'y a pas que des utilisateurs Windows dans le grand monde de l'information (Linux pour ma part)

Bonjour,

Tu peux tester ce script :

<script type="text/javascript">
var WinNetwork = new  ActiveXObject("WScript.Network");
alert(WinNetwork.UserName);
</script>

Cela doit te permettre de connaitre le user windows de l'utilisateur. A priori, il n'est pas possible de connaitre le mot de passe (enfin je l'espère). Mais si l'utilisateur est connecté sur le poste, pas de problème.

A toi de vérifier sur le serveur si l'information est exact (page effectuant la requête ?). Enfin un gros travail de sécurisation pour qu'il ne soit pas possible à un utilisateur de se faire passer pour quelqu'un d'autre. Si c'est une application purement interne à l'entreprise, ca ne doit pas être trop grave. Il te faut expliquer que la fainéantise des utilisateurs peut faciliter les usurpations d'identités. A tes boss de prendre leur responsabilité.

Tu veux dire lorsqu'ils se connectent un fois, qu'ils n'aient plus à se reconnecter à leurs prochaines visites ?

Personne pour m'aider???

Bonjour,
j'ai installé GRR gestionnaire de ressources et reservations, j'utilise une connexion ldap pour l'authentification des utilisateus. Jusque la tout fonctionne, cependant j'aimerai que les utilisateurs n"entrent pas une seconde fois leurs id et mdp. Je souhaite qu'une fois loggué dans le domaine, la connexion se fasse automatiquement.
J'ai regardé les codes sources mais ça me semble compliqué et je pense qu'il n'y a pas grand chose à faire mais quand on ne sait pas quoi faire, bah c'est la me***!!!
Si quelqu'un veut bien m'aider, je peux faire un copier coller des codes.
Merci d avance