Redirect HTTPS Tableau Traffic to a Valid URL

You’ve heard it before: it’s past time to encrypt ALL the things! Even internal traffic should be encrypted, since you never know what rogue devices or people may be listening on an ethernet port or an unsecured hotspot. That’s why, when I inherited a Tableau server, I decided that encryption should be a priority. Especially when you consider the kind of data that can flow in and out of Tableau. And, Tableau makes it surprisingly easy to turn on TLS (or SSL, as they and so many others like me still call it). What they don’t make so easy is redirecting users over to an address that matches your cert. No big deal if your users have always accessed Tableau Server with the right alias, but until now, we only had an internal address that doesn’t match the cert we applied. The good news is Tableau Server uses Apache for its web server. With a pretty small tweak, you can redirect your users in no time.

Please note: this is not documented or supported by Tableau as far as I can tell. Be sure to test thoroughly before applying to your production environment. I also assume these settings will be overwritten by an update/upgrade, thus needing to be reapplied afterward (update: Having since gone through a few upgrades, I can confirm that these settings need to be reapplied afterward).

As I mentioned, Tableau Server uses Apache for its web server. An interesting choice since Tableau is only supported on Windows. This means a couple rewrite conditions/rules in httpd.conf will have you off and running. The first thing you need to know is where this file lives. It will be under Tableau’s data folder, which is located based on which drive Tableau was installed on. Tableau was installed on C: for us, which puts the httpd.conf file in C:\ProgramData\Tableau\Tableau Server\data\tabsvc\config (we will talk about moving your data folder to another drive in a later post). I am not entirely certain what the structure looks like if you installed on a separate drive, so you may need to do some digging.

Once you have located the httpd.conf file, the second thing you need to know is that this file is formatted for *nix line feeds and carriage returns. I.E: If you open it in Notepad, it will all be jumbled together. If you already have a tool like Notepad++ installed on the server, it should do nicely. In my case, I chose to copy the file to my local machine, edit it with Atom, and then push it back to the server. Just be sure to make a backup of the file first.

Ok, so you’ve found httpd.conf, you’ve made a backup, and opened it up in your favorite *nix-friendly text editor. If you scroll down to around line 581, you will start to see several RewriteCond and RewriteRule lines. Our rules don’t have to go here, but it seemed logical since there are already related rules in the vicinity. If you aren’t familiar with mod_rewrite rules, they basically look for certain conditions in an Apache request and rewrite/redirect (with a 301 by default) the URL sent to the server. Here is what I added after Tableau’s built-in list of rewrite rules:

RewriteCond %{HTTP_HOST} !^tableau\.mycompany\.net [NC]
RewriteCond %{HTTP_HOST} !^localhost [NC]
RewriteRule (.*)$1 [R=301,L]

What does each line mean? The first line looks for requests containing a URL that doesn’t match the address we want people to use. Replace “” with your company’s preferred address for Tableau. Of course, make sure the record actually exists in DNS and points to your Tableau server.

The second line is an AND condition (by virtue of the previous line not ending in “[OR]”) and filters out requests using the “localhost” URL. The reason for this is that Tableau Web Data Connectors (WDC) published on the server will always be refreshed using http://localhost/webdataconnectors/yourWDCname.htm. And, as I found out, Tableau won’t follow the redirect when it tries to extract, but it will seemingly ignore the certificate/server name mismatch. Adding this line makes sure we don’t break any scheduled extracts using a WDC. Side note: it seems that in Tableau 10, you can maintain a list of approved WDC’s external to Tableau (aw yeah!), which I find preferable and would make this line unnecessary.

Now, the third line. This line takes the requests that haven’t been filtered out by the two previous conditions, and rewrites them to use our preferred address. Notice that here I have added the protocol (https://), whereas it is not needed for the conditions since we want to catch HTTP and HTTPS requests. The variables at the end will keep the rest of the URL as-is, so that something like becomes, rather than redirecting to Tableau’s landing page.

Once you have updated httpd.conf with the lines above, restart Tableau Server (tabadmin restart). Now, whenever someone tries the old address, they should be redirected to the new one. This all depends on the visitor or other clients following a 301 redirect, which is pretty standard. Still, be thorough in your testing to account for all conditions.

That’s it! A lot of talking for 3 lines of text.


Get a Working Date/Time Format Using a Tableua Web Data Connector

Here’s a tip that resulted from quite a bit of frustration. It has to do with Tableau’s new-ish Web Data Connector and a difference in JavaScript date functions across browsers (particularly, Chrome and Safari). While trying to pull in JIRA data, depending on which JavaScript method I attempted, I would see either a NULL or NaN (Not a Number) in any date field. The frustrating things is that it worked perfectly in the simulator. I only ran into the problem in Tableau Desktop (on a Mac) and could not find any errors in the logs or console.

To start with, Tableau has a pretty good tutorial to help people get started writing a WDC, which I recommend you check out first if you haven’t already. Within their documentation, you can find a cheat sheet for accepted date/time formats. However, even though I referred to this cheat sheet and tried several formats, I could never get anything to produce a result other than NULL or NaN in Tableau. Again, despite the dates rendering properly using the simulator in Chrome. Writing a WDC wasn’t a high priority, so I would bang my head on it for a while, set it aside for something else, and then come back the next week to do the same thing all over again.

A breakthrough finally came when I asked myself, “Does the simulator behave the same in all browsers?” I fired it up in Firefox and saw the same valid results as I saw in Chrome. Next, I brought up the simulator in Safari. Much to my surprise, the dates produced a NULL or NaN! For my purposes, the WDC was connecting to a proxy server, which then connected to JIRA using PHP’s cUrl functions. In order to confirm my suspicion that Tableau was using Safari, I checked the access log for this proxy server. What user agent did I find when trying to connect using Tableau Desktop, rather than the simulator?


As you can see, Tableau was using Safari. A Google search lead me to this question on Stack Overflow, which made me think Safari was not quite comfortable with the date/time string provided by JIRA (e.g.:2016-07-23T05:31:15.000-0400). The accepted answer suggests trying out moment.js, which I did and found it incredibly easy to use. Just remember to include the moment.js file when you add your WDC to the server.

With moment.js in hand, the solution was simple. I included moment.js in my WDC with something like the following:

<script src="moment.js"></script>

Then, I used the following code to get the date string supplied by JIRA into a format supported by Tableau:

var dateFormat = "Y-MM-DD HH:mm:ss";

var createdDate = moment(issues[ii].fields.created).format(dateFormat);

Tableau magically rendered a real date! So, if you find yourself trying to solve the same puzzle, give moment.js a try and see if that doesn’t get you onto the next hurdle (which is getting Tableau Server to a version that is compatible with the WDC found in the tutorial/simulator).