6 Replies Latest reply on Mar 1, 2017 11:34 AM by Jeff Strauss

    Embedded views, secure filter that is immune to revert, ssl

    Andrew Jones

      Hi,

       

      I have tableau reports embedded into a website. I have encountered various problems, and wondering if there is any solution to these problems.

       

      Filters are generated on the web server by checking who the logged in user is, and getting a list of values relevant to that user. This data is then added to the filter parameter of the object that is embedded into the webpage. The first approach we had was to use the filter method in the javascript api, but this resulted in an unexpired ticket not found error as soon as the filter method was run. Either way, the same result is achieved. The thing is, this is in no way secure as it is all just client-side. Anyone can intercept that page before it has finished loading and change the filter values. The other problem is that all of the filter information is lost when the user clicks on "revert". These filters are the only way we could find to prevent people from seeing information they were not allowed to see, but don't seem to be secure.

       

      The other issue is that embedding the reports into the website, which is over SSL, results in same origin policy being violated as the server that runs the reports has a different subdomain to the web server.

       

      Thanks,

       

      Andrew

        • 1. Re: Embedded views, secure filter that is immune to revert, ssl
          Joshua Milligan

          Andrew,

           

          Have you tried using user filters?  Those would avoid the  revert / intercept  issues you describe.  You can find more information here: http://onlinehelp.tableausoftware.com/current/pro/online/en-us/publish_userfilters.html.  It is also a great way to build the views and dashboards as you can test each user from within Desktop to check what data they will be able see.

          • 2. Re: Embedded views, secure filter that is immune to revert, ssl
            Tamas Foldi

            The other issue is that embedding the reports into the website, which is over SSL, results in same origin policy being violated as the server that runs the reports has a different subdomain to the web server.

             

            Hmm, you can change the javascript domain settings by modifying one of the javascripts in tableau web application. When I embed tableau visualizations that's the first that I change.

            • 3. Re: Embedded views, secure filter that is immune to revert, ssl
              Tamas Foldi

              Joshua is right, user filters is the one and only way to restrict your user's filters and data. All other things are simply unsecure

              • 4. Re: Embedded views, secure filter that is immune to revert, ssl
                Russell Christopher

                Hey Andrew -

                 

                In nearly all circumstances, using sensitive values in filters or using filters as a security mechanism is not the right way to go.

                 

                As you've discovered, anyone with a Fiddler-ish tool can happily camp on the client and watch values go by.

                 

                Here are a few alternatives you may want to investigate:

                 

                • As Joshua mentioned, leverage User Filters. This will require you to spend extra time keeping the Tableau user store up to date. This is probably the best solution
                • You're running into a JavaScript bug (we re-submit the original trusted ticket each time you use the Filter()  method - this won't work since a ticket can only be redeemed once.). However, ever if this did work correctly for you, we're still just populating a string and using it with a GET so it would be visible via Fiddler
                • Put a proxy in front of your Tableau Server. Remove the logic from your portal that ads the "secret" filters to the URL and put the logic in a module that is part of the Proxy. Requests from your web app go to the proxy, where the user-specific filters are injected into the URL. Then, the URL is fired against Tableau. This will prevent users from seeing what is going in with your "secret filters" and neatly solves the problem. However, it takes a lot of effort to implement.

                 

                In Tableau Server 8, the JavaScript API passes filter values to Tableau Server using a different technique, so they should NOT be visible to the user via Fiddler. I haven't tested this myself, but that's what I've been told. I still don't think that using normal filters is a good way to implement security, however.

                 

                Hope this helps, have a good new year.

                • 5. Re: Embedded views, secure filter that is immune to revert, ssl
                  Andrew Jones

                  Thanks guys. I did not know about the user filters as I am only responsible for the server-side stuff and don't know anything about the creation of the reports. As for the other issue, it turned out to be caused by Netscaler blocking a request as it thought it was an SQL Injection attack. We also added a rewrite policy to change the returned Location field in the response header sent by Tableau to prevent the mixed-content issues.

                  • 6. Re: Embedded views, secure filter that is immune to revert, ssl
                    Jeff Strauss

                    yeah, I know that this post is 4+ years old.  Any-hoo, did you ever do this proxy approach and are you able to share any deeper insights into this approach?

                     

                     

                    • Put a proxy in front of your Tableau Server. Remove the logic from your portal that ads the "secret" filters to the URL and put the logic in a module that is part of the Proxy. Requests from your web app go to the proxy, where the user-specific filters are injected into the URL. Then, the URL is fired against Tableau. This will prevent users from seeing what is going in with your "secret filters" and neatly solves the problem. However, it takes a lot of effort to implement.