views:

383

answers:

2

I'm presently working on a large intranet mashup that uses sharepoint to aggregate content from several other internal servers such as:

  • moss.myapp.internalserver.local - The MOSS portal
  • ssrs.myapp.internalserver.local - SQL Server reporting services reports
  • app.myapp.internalserver.local - Custom ASP.NET MVC forms

The moss portal invokes the MVC forms using iframes in jQuery dialogs (boxy to be precise), which in turn call back into the moss page with javascript for various things, including closing the jQuery dialog.

This would obviously fail the same origin policy on the browsers (and therefore not allow javascript to call into the frames/windows from different sources), so I've worked around this by setting document.domain = "myapp.internalserver.local" in the MOSS master pages and the app forms pages, which allows cross domain scripts to run fine between moss and app content.

So, that's working great, until I add an SSRS report into the mix using a report viewer web part (sharepoint's default one, plus a couple of third party ones including my own which just use the ASP.NET report viewer component).

The report viewer seems to require a handler that returns html into the page. However, The resultant report viewer content seems to render and script into some iframes, but it doesn't give us any way to set document.domain on those iframes, and so the scripts fail.

At best this means we get the little yellow javascript error icon in the status bar, and at worse, where dynamic rendering is used, the "rendering report" progress wheel just animates and never delivers a report.

Has anyone seen this before and if so, how did you get around it?

Thanks, Tony

A: 

Typically to get the SSRS web parts to behave in SharePoint you will want to enable Kerberos, if you want to pass the same reports (using the same security context) you will need to grant your SharePoint app pool account rights to retrieve/run the reports. You could also consider installing SSRS in "integrated" mode but this is quite a difficult process as the sql server will need to host SharePoint as another farm member, with SharePoint fully installed.

UJ
Already got the servers etc talking to each other fine, and the report viewer works perfectly - we're using Kerberos. This isn't the issue - the issue is where the portal page sets the document domain in javascript to a higher level domain, so that we get around some issues with same origin polict - IE: so that it can do cross domain stuff with other pages from other servers in the setup. SSRS doesn't set this, nor can it be set from what I see, therefore the report viewer web part doesn't work correctly as it's not in the same domain as the host page, so it's scripting of iframes fails.
deepcode.co.uk
A: 

I ended up solving this by using sub-frames as per this blog post:

http://www.deepcode.co.uk/2009/11/overcoming-cross-domain-issues-between.html

deepcode.co.uk