Discussion :

[lodan]

Bonjour,

Je veux intégré "webcalendar" dans mon intranet.

J'ai un login et password lorsque je rentre dans mon intranet et lorsque je vais depuis mon intranet vers webcalendar, il me redemande un login et un mot de passe.

J'ai fait en sorte que dans mon intranet et dans webcalendar, ce soit le même password.

Je voudrais éviter qu'il me redemande le password lorsque je vais sur webcalendar.

Faut-il que je stock le password quelque part pour le passer en paramètre ? Dangereux non ?

Une autre solution ?

Merci d'avance

[Invité]

Bonjour,

Qu'est-ce que tu utilises comme authentification sur ton intranet?

Dangereux je ne dirais pas comme toi. Tu es sur un intranet et à toi de juger de la valeur des données y circulant. Si tu es derrière un pare-feu et/ou NAT, tu n'as rien à craindre de l'internet.

webrider.

[lodan]

Je vais ouvrir l'intranet vers internet pour que les salariés nomades et uniquement eux puissent se connecter.

L'authentification se fait par login/password en md5

[Invité]

Ok donc j'en déduis que ce n'est pas une authentification http

Si tu travailles avec des sessions, au lieu de transmettre le mot de passe, tu devrais passer l'état de l'utilisateur de page en page (à savoir authentifié ou non).

Dès qu'un utilisateur se connecte avec succès tu écris

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$_SESSION["connected"] = 1;

A l'arrivée sur webcalendar, tu testes la valeur de $_SESSION["connected"].

Si elle est à 1 -> pas de demande login/mdp
Si elle est à 0 ou non déclarée -> demande d'authentification

Qu'en penses-tu?

webrider

[lodan]

Oui, c'est très simple comme solution.

Je dois donc modifier webcalendar pour qu'il ne demande pas l'authentification si je suis à "1"

Merci

[Invité]

Pas de quoi!

[lodan]

Une question tout à coup, tu constates :

Ok donc j'en déduis que ce n'est pas une authentification http

Est-ce bon ou pas bon de ne pas utiliser cette fonction ?

[Invité]

Disons que l'authentification http basique fait transiter les informations (login/mdp) en clair donc pas de sécurité du tout.

La gestion des comptes est plus difficile, les login/mdp sont dans un fichier texte avec login et mdp crypté... schéma propre au serveur web.

Le login se fait dans un petit pop-up dès l'arrivée sur le site, pas moyen de personnaliser la mise en page.

Comme tu le vois, la manière que tu as retenue est bien plus modulable et sécurisée que l'authentification http.

Bon dimanche,

webrider.

[lodan]

Merci webrider,

Je suis rassuré, sécurisé et je vais passer un bon dimanche

Bon dimanche à toi aussi.

[Invité]

Pour passer encore un meilleur dimanche et pour t'amuser aussi un tout petit peu tu pourrais utiliser SSL pour ton intranet!

Pour cela il te faudra un certificat, dispo gratuitement là http://cert.startcom.org/?lang=fr&app=100

J'utilise leurs services pour mon site internet et j'en suis très content. Avec tout ça tu seras au top de la sécurisation! Et puis jouer avec le cryptage te mènera de découverte en découverte.

@++

webrider

[lodan]

Ouhaaaa !!!! ça me tente beaucoup.

Combien de temps dois-je prévoir pour utiliser cette technique que je ne connais pas du tout ?

Je me connais, si je m'y met tout de suite, je ne vais pas compter mon temps et prendre du retard sur le reste.

Il parle de quelques minutes

[Invité]

Si tout va bien, je dis bien si tout va bien

Compte une demi-journée pour apprendre et mettre en place. Mais comme tu le sais certainement rien ne va jamais bien du premier coup!

Dans ton cas, délai oblige, finis d'abord le travail que tu as à faire. Tu peux toujours ajouter SSL plus tard sans rien changer au contenu du site. C'est comme ça que j'ai fait!

Tu comptes utiliser ton propre serveur web? Si ce n'est pas le cas, il faut d'abord contacter ton hébergeur pour la partie technique.

Pour configurer à fond mon serveur Apache j'ai lu le livre Apache 2 Installation, administration et sécurisation aux éditions ENI. On y parle de SSL de manière intéressante (fonctionnement et mise en place).

Un autre aspect de la sécurité sous Apache sont les URL rewriting : l'internaute entre ou est dirigé vers une URL fictive et le "rewriting" transcris cette adresse vers un vrai nom sur ton serveur. Ainsi les internautes ignorent le vrai nom de tes fichiers! Il paraît qu'on peut l'utiliser pour d'autres choses mais je n'ai pas encore poussé plus loin.

webrider

[lodan]

Merci pour le livre, j'avais déjà commandé "linux pour les nuls" et "
Sécurité Internet pour les nuls "

Je donc commandé en plus ce livre que tu préconises, je devrai l'avoir d'ici une semaine.

Merci encore, je double le temps que tu préconises

Ce sera sur mon propre serveur et aussi chez mon hébergeur en serveur dédié donc je ne devrai pas avoir trop de problème à mettre ce que je veux.

[Invité]

Pas de problème et bon courage pour la suite!

webrider