Forum Discussion
Custom visuals not showing with Custom authentication
I have a PBIX that works fine in PBI Desktop and Report Server (both May 26). It has a variety of Visualizations: built-in, downloaded from AppSource and one imported from a pbiviz. It also works when uploaded to Service.
I need this to run on-prem, with Anonymous login, so I have implemented the Reporting-Services CustomSecuritySample. Once this is activated I can successfully access the PBIX but none of the non-built-in visualisers appear. I have opened the PBIX as a zip file and checked they are all present.
Since this used to work in the May 25 Server release I assume that something extra needs to be done in the Server config to fix things. It is as if the external visualizers are now no longer trusted, even the certified ones from AppSource. Logs show no suspicious entries.
Does anyone have any clues as to what I need to do before I roll back to May 25 which will limit my ability to use new visualisers going forward?
Thanks in advance
Chris
2 Replies
Thank you. That makes sense. I’ll try it over the weekend.
Chris
jubinsoniSkilled Sharer
Hi chrisb_b,
Since built-in visuals render and only the custom ones disappear, my first suspect would be the extra requests custom visuals make. They are loaded separately from the report (the visual package is fetched and then run in a sandboxed iframe), so if those requests are not authenticated by your custom security extension, or are redirected to the logon page, the visual silently renders as blank while the rest of the report works.
How I would confirm it before rolling back:
1. Open the report, F12 > Network, filter on "visual" / "pbiviz" / "resource" 2. Look for requests that return 401, 403 or a 302 to your logon page (or HTML instead of JSON/JS) 3. F12 > Console: look for sandbox / CSP / "refused to load" errorsIf the network trace shows auth failures for those calls, the fix is on the extension side: make sure the anonymous/forms cookie is accepted for those endpoints too, and that your CheckAccess implementation in the custom security sample grants the read operations for resources/items the report references, not just the report item itself. Changes in the newer release around how visual packages are requested would explain why it worked in May 25 and not May 26.
If instead you see CSP or sandbox errors, compare the rsreportserver.config / web.config between the two builds (an upgrade can reset custom changes), and test one AppSource visual in a brand-new report to rule out the specific .pbix.
Either way, capture the failing request URL and status from the trace; that is exactly what support or the docs team would need, and it tells you whether to fix the extension or wait for a fix.
So my overall approach would be:
F12 network trace: find the failing visual requests (401/302/HTML) -> Extend custom auth / CheckAccess to cover those endpoints -> CSP/sandbox errors instead: diff config files between May 25 and May 26 -> Report with the failing URL if the extension is not the causeAI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
