All Apps and Add-ons

Sideview Utils: Why doesn't "export" work correctly when a user accesses the app through SSO?

Builder

When I log into our Splunk instance (v6.1.2) as the admin user, open a dashboard in a specific app that uses the Sideview Utils' SearchControls module (v.3.2.8) with an export section, run the search, and then export the results, I get prompted to enter a file name and that filename.csv downloads just fine.

When I log into the instance as the unique user that only has access to that app, go to the dashboard, run the search, and export the results, I get prompted to enter a file name and that filename.csv downloads just fine. (This confirms that permissions for the user/role are set correctly to allow the export and download the file.)

When I enter the app as that unique user through our Single Sign-On implementation, go to the dashboard, run the search, and export the results, I get prompted to enter a file name (as normal). However, when it tries to download, it downloads as "results" with no file extension, NOT as filename.csv. Technically, these files can be saved to disk while manually specifying the ".csv" extension in the "Save As" box and they'll open just fine, but not all of our users are tech-savvy enough to be able to do that...

So it seems like the problem has something to do with SSO interaction. I haven't been able to find any errors in Splunk's internal logs or in the files in var/run/splunk/dispatch for the searches to indicate where the problem lies.

Is there something that needs to be configured in the SSO implementation to make this work?

1 Solution

SplunkTrust
SplunkTrust

I think you'll find that in the SSO case the content-disposition header isn't being passed back to the browser? What you're describing sounds like what would happen if that one header didn't make it back at least.

Any chance you can verify this with something like Wireshark? Thanks for the extremely detailed analysis and writeup. I'd love to be able to fix this or give some workaround but I think it's going to be an issue in the proxy.

View solution in original post

SplunkTrust
SplunkTrust

I think you'll find that in the SSO case the content-disposition header isn't being passed back to the browser? What you're describing sounds like what would happen if that one header didn't make it back at least.

Any chance you can verify this with something like Wireshark? Thanks for the extremely detailed analysis and writeup. I'd love to be able to fix this or give some workaround but I think it's going to be an issue in the proxy.

View solution in original post

Builder

My proxy developer confirmed that we are not allowing the "content-disposition" header to pass back through. We'll have to do some work to fix that, but that sounds likely. I'll mark this as the answer as soon as we know for sure (or get back to you with more information if it doesn't fix it). Thanks!

0 Karma

Builder

It may be worth noting that as part of our Single Sign-On implementation, we are using a custom endpoint and a proxy to make the Splunk app be white-labeled under different domains.

e.g., instead of showing analytics.our-domain.com/Analytics to access Splunk, the SSO users see company.admin.our-domain.com/Analytics

0 Karma