Question

J'ai un système WSS 3.0 en utilisant SSL où chaque page est censé être servi comme https. Presque toutes les pages ne sortent que https, mais dans certains cas, je clique sur un lien et qui met en place une version http d'une page (qui ne se charge pas). Dans ces cas, je dois mettre le « s » à la main pour obtenir la page à charger. Les endroits où cela se produit sont:

  • / _ layouts / newgrp.aspx: lorsque je tente de créer un nouveau groupe, il me faut http: / /server/_layouts/newgroup.aspx , bien qu'il devrait être https. La page ne se charge pas à l'adresse http. Il ne charge si je change l'adresse à la main.
  • / _ layouts / edtgrp.aspx: même chose que newgrp.aspx
  • si je vais dans une bibliothèque de documents et visualiser l'historique de version pour un fichier, les URL aux différentes versions de ce fichier sont http. Fait intéressant, la barre d'état du navigateur indique également http quand je passe la souris sur eux (il semble donc que SharePoint devient confus quand il génère les liens, plutôt que lorsque je clique sur eux)

Pour résoudre ce problème, je l'ai essayé d'ajouter un peu de javascript au DOM qui recherche pour les instances de http et les remplace par https. Cela fonctionne dans certains cas, mais il y a des endroits où le javascript ne peut pas atteindre, par exemple lorsque SharePoint fournit l'URL cible en réponse à une requête POST, qui je pense est le cas avec Newgrp / edtgrp.aspx.

J'ai aussi essayé d'ajouter des filtres ISAPI pour rediriger les pages de http https. Cela semble faire rediriger les boucles, et en tout cas, je ne suis pas sûr si ces filtres préserveraient querystring ou POST informations.

Quelqu'un at-il vu ce problème?

Mise à jour: Nous avons passé à ISA de Squid, et le problème se poursuit dans l'histoire de version, mais pas sur un nouveau groupe ou d'un groupe d'édition. On n'a pas vu une amélioration encore de modifier les paramètres de l'AAM.

Lieux où cela se passe dans ISA:

  • « Historique des version » sous le point dans la liste ou d'une bibliothèque de documents
  • « Gérer les autorisations » au titre du point dans la liste ou d'une bibliothèque de documents
  • « Alerte Me » au titre du point dans la liste ou d'une bibliothèque de documents
  • page "Ajouter des utilisateurs" menuitem dans "Les personnes et les groupes"
  • page "Paramètres de groupe" ligneMenu "Les gens et les groupes"
  • "Modifier le groupe Quick Launch" ligneMenu la page "Les gens et les groupes"
  • page « Créer des groupes » ligneMenu « Les personnes et les groupes »
  • page "Paramètres de la liste" ligneMenu "Les gens et les groupes"
Était-ce utile?

La solution 5

Alex a répondu à cette question avec une approche qui, je pense généralement travailler. Voici comment je fixe ce spécifiquement.

Il semble que lorsqu'une page aspx SharePoint est chargé, il remplit une structure de type javascript contextInfo (défini dans Init.js), qui est instancié dans le ctx variable. Cette structure a un membre appelé httpRoot, qui est ensuite utilisé dans core.js pour construire menuitems dans divers menu déroulant.

Cette ctx.httpRoot est pour une raison peuplée en javascript dans les fichiers ASPX créés par SharePoint avec une ligne comme celle-ci:

    ctx.HttpRoot = "http:\u002f\u002fsubdomain.domain.com";

Oui, il a Unicode barres obliques et il a http au lieu de https. Je ne sais pas pourquoi. Mais, fixer cette ligne de javascript semble résoudre le problème.

J'ai changé la ligne en ajoutant une règle de traduction d'URL dans ISA qui convertit http: \ u002f \ u002f \ https: \ u002f \ u002f \. Je pense qu'un module HTTP qui fait le même remplacement fonctionnerait aussi. Ou peut-être un peu javascript bien placé que réaffecte la variable à un moment donné.

Je crois toujours ce n'est pas idéal et il doit y avoir un moyen plus approprié de fixer ces liens.

Autres conseils

Je ne sais pas si cela est, mais avez-vous vérifié vos mappages d'accès pour vous assurer qu'ils disent https au lieu de http?

J'écho à la suggestion de vérifier vos Mappages Alternate d'accès. Le SSL se fait sur les extrémités avant SharePoint, ou est-il se fait au moyen d'un morceau de matériel SSL dédié?

Utilisez HTTP Module pour modifier la sortie de SharePoint afin que les liens sont toujours changés à https. Un tel module peut brancher dans IIS et modifier le code HTML de quoi que ce soit rendu. Je l'ai utilisé cette technique pour rendre conformes SharePoint XHTML et il fonctionne bien.

Mieux encore, presque tout le travail a déjà été fait pour vous. Module UrlRewritingNet est open source et disponible en téléchargement gratuit. Il devrait fonctionner correctement pour votre site SharePoint. Cet outil a une grande documentation et utilise des expressions régulières pour correspondre les URL à modifier. Il devrait être assez facile d'écrire pour votre cas, par exemple ^http://. Il y a aussi beaucoup plus d'options avancées, vous pouvez profiter de si nécessaire.

Si vous préférez écrire votre propre alors il y a un bon article intitulé Rewrite.NET -. Une URL Rewriting Engine .NET sur le site de 15 secondes

Enfin, si vous utilisez IIS 7, vous pouvez essayer ses Module Rewrite. Je ne l'ai jamais utilisé moi-même et je ne sais pas si cela fonctionne avec SharePoint, mais il est la solution la plus axée sur l'interface utilisateur-disponible.

Ajouter une redirection dans IIS http https. Chaque fois que vous accédez à cette page, il vous rediriger vers votre page https au lieu.

Je suggère également de placer WSS sur un autre serveur pour voir si vous avez les mêmes problèmes. Si vous ne le faites pas, vous pourriez avoir besoin de reconstruire / migrer vos trucs sur.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top