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
For you many thanks for pointing me the right way. To anyone else stuck in the same hole:
The answer is to add two more parameters onto the definition of the sqlAuthCookie in webconfig.config thus:
<authentication mode="Forms"> <forms loginUrl="logon.aspx" name="sqlAuthCookie" timeout="60" path="/" cookieSameSite="None" requireSSL="true"> </forms> </authentication>and to add a line to mark the cookie secure in logon.aspx.cs in AllowInReader thus:
if (passwordVerified) { HttpCookie cookie = FormsAuthentication.GetAuthCookie(sUserName, false); cookie.Secure = true; FormsAuthentication.RedirectFromLoginPage( sUserName, false); } else { this.BtnLogon.Text = "Failed"; Response.Redirect("logon.aspx"); }I hope this saves someone else having to read as much contradictory Microsoft documentation as I had to!
Chris
4 Replies
- jubinsoni
Memorable Member
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.
- chrisb_bNew Member
Thank you. That makes sense. I’ll try it over the weekend.
Chris
- chrisb_bNew Member
That was really helpful. The problem appears to be in the Custom Security extension as there are loads of 401 errors trying to get at items like:
http://<some hostname>/powerbi/libs/scripts/customVisualsHost.js.
I'm still not able to solve the problem. Reading the (extensive) documentation there appears to be nothing that points me as to what to change in the Extension's CheckAccess method (the array of permissions seems complete when compared with the Interfaces), or what to change in the config file (allowing some other cookie or token to be passed?). I'll ask a question of the developers of the Custom Security Sample and see if they can get me further, but thanks for helping me focus. In the meanwhile I'll stick on May 25 and not upgrade until I have found a mechanism in May 26+ to get the same functionality.
Chris
- chrisb_bNew Member
For you many thanks for pointing me the right way. To anyone else stuck in the same hole:
The answer is to add two more parameters onto the definition of the sqlAuthCookie in webconfig.config thus:
<authentication mode="Forms"> <forms loginUrl="logon.aspx" name="sqlAuthCookie" timeout="60" path="/" cookieSameSite="None" requireSSL="true"> </forms> </authentication>and to add a line to mark the cookie secure in logon.aspx.cs in AllowInReader thus:
if (passwordVerified) { HttpCookie cookie = FormsAuthentication.GetAuthCookie(sUserName, false); cookie.Secure = true; FormsAuthentication.RedirectFromLoginPage( sUserName, false); } else { this.BtnLogon.Text = "Failed"; Response.Redirect("logon.aspx"); }I hope this saves someone else having to read as much contradictory Microsoft documentation as I had to!
Chris