<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.
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.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)
Tout d'abord merci! Mazarini t'as tout compris, peu importe pour la sécu, peux tu juste mieux m'expliquer t'as manip stppBonjour,
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.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)
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.
<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.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 :Si tu fait une page html avec ce script, il doit afficher ton user windows dans une fenetre.<script type="text/javascript"> var WinNetwork = new ActiveXObject("WScript.Network"); alert(WinNetwork.UserName); </script>
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.
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 logsSurtout 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.
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?
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).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
@blowingfish : pas la peine de s'énerver