Ah non, il n'y a pas forcément besoin de gérer toutes les méthodes d'authentification HTTP... qui ne sont d'ailleurs pas forcément si nombreuses que ça côté client (beaucoup sont faites par le site lui-même, pas en HTTP : si tu regardes les pages web, le code renvoyé est toujours 200 et non 401/403). Mais les principales pourraient l'être.
Après, tu peux effectivement faire confiance au proxy (apache ou nginx), qui va (par exemple) ajouter un header HTTP (souvent REMOTE_USER) contenant le nom d'utilisateur. Le serveur applicatif n'a plus qu'à utiliser ce header HTTP, et c'est gagné.
Au passage, SSH connaît d'autres méthodes que les trois que tu cites (notamment Kerberos/GSSAPI) :)
[^] # Re: Transport via SSH
Posté par flan (site web personnel) . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 2.
Ah non, il n'y a pas forcément besoin de gérer toutes les méthodes d'authentification HTTP... qui ne sont d'ailleurs pas forcément si nombreuses que ça côté client (beaucoup sont faites par le site lui-même, pas en HTTP : si tu regardes les pages web, le code renvoyé est toujours 200 et non 401/403). Mais les principales pourraient l'être.
Après, tu peux effectivement faire confiance au proxy (apache ou nginx), qui va (par exemple) ajouter un header HTTP (souvent REMOTE_USER) contenant le nom d'utilisateur. Le serveur applicatif n'a plus qu'à utiliser ce header HTTP, et c'est gagné.
Au passage, SSH connaît d'autres méthodes que les trois que tu cites (notamment Kerberos/GSSAPI) :)