Je travaille actuellement sur un grand mashup intranet qui utilise sharepoint pour agréger le contenu de plusieurs autres serveurs internes tels que:spectateur SSRS rapport à sharepoint avec document.domain mis
- moss.myapp.internalserver.local - Le portail mOSS
- ssrs.myapp.internalserver.local - reporting services SQL Server rapports
- app.myapp.internalserver.local - personnalisé forme ASP.NET MVC
Le portail mousse invoque les formulaires MVC en utilisant les iframes dans les boîtes de dialogue jQuery (pour être précis), qui à son tour rappeler dans la page mousse avec javascript pour diverses choses, y compris la fermeture de la boîte de dialogue jQuery. Cela aurait évidemment échouer la même politique d'origine sur les navigateurs (et donc ne pas autoriser javascript à appeler dans les cadres/fenêtres de différentes sources), donc j'ai travaillé autour de cela en définissant document.domain = "monapplinternet.internalserveur .local "dans les pages maîtres MOSS et les pages de formulaires d'application, ce qui permet aux scripts inter-domaines de fonctionner correctement entre le contenu de mousse et d'application. Cela fonctionne très bien, jusqu'à ce que j'ajoute un rapport SSRS dans le mix à l'aide d'un composant WebPart Report Viewer (celui par défaut de Sharepoint, plus quelques tiers, dont le mien, qui utilise le composant ASP.NET Report Viewer).).
La visionneuse de rapports semble nécessiter un gestionnaire qui renvoie html dans la page. Cependant, le contenu du visualiseur de rapport résultant semble afficher et écrire dans certaines iframes, mais il ne nous donne aucun moyen de définir document.domain sur ces iframes, et ainsi les scripts échouent. Au mieux, cela signifie que nous obtenons la petite icône d'erreur jaune javascript dans la barre d'état, et pire, lorsque le rendu dynamique est utilisé, la roue de progression "rendu" ne fait qu'animer et ne délivre jamais un rapport.
Est-ce que quelqu'un a déjà vu ça et si oui, comment l'avez-vous contourné?
Merci, Tony
déjà obtenu les serveurs etc parler les uns aux autres fins, et le spectateur de rapport fonctionne parfaitement - nous utilisons Kerberos. Ce n'est pas le problème - la question est où la page du portail définit le domaine de document en javascript à un domaine de niveau supérieur, de sorte que nous contourner certains problèmes avec le même polict d'origine - IE: afin qu'il puisse faire des choses avec d'autres domaines les pages des autres serveurs de l'installation. SSRS ne le définit pas et ne peut pas être défini à partir de ce que je vois. Par conséquent, le composant WebPart Report Viewer ne fonctionne pas correctement car il ne se trouve pas dans le même domaine que la page hôte. –