5 Replies Latest reply on Mar 9, 2015 8:54 AM by Carisa Chang

    Error handling trusted ticket

    Chris O'Connell

      I am trying to get my Tableau Server to display a Dashboard on an SF.com page and I am so close to having things work that I can taste it.  I think I have resolved my problems except for one last issue.  When I visit the SF.com page, I get an error message returned from the Tableau Server that states:

      • Could not locate unexpired trusted ticket <!DOCTYPE HTML PUBLIC


      It seems that when Heroku is trying to get a trusted ticket from the Tableau Server, it is getting some response that is not a trusted ticket, but instead it is an html doctype declaration.  There is no meaningful information in the Heroku log and I have gone through all of the Tableau Server logs and I can't find anything that even logs the request for the ticket in the first place.  I do see this the log, but it looks like that is the post from Heroku that attempts to get the ticket in the first place.  But, I can't find any details about this request, either details of post parameters or what the server response was:

      - - [30/Jul/2014:00:58:12 -0500] 80 "POST /trusted HTTP/1.1" "-" 307 249 "18" 1000 U9iJdAoAAAwAABeg38oAAAHw


      I'll be honest, I'm not 100% sure how to read this.    I understand that the first part is the IP of the Heroku server and I have confirmed that this is added to the trusted IP's (I am using the proximo addon).  The second part is the date/time and after that is port, the method and the URL along with the HTTP version used in the request.  After that, I have no idea.  I suspect that 307 is the http error code (which is a redirect, which doesn't seem right to me, but I don't know).  After that, I don't know what the rest of those items are.


      Any help would be greatly appreciated.




      edit: I was able to fake out a post to my Tableau Server using a REST tool I found online.  It looks like Heroku is making an HTTP call to my Tableau Server to get the ticket (from the log line above, the request comes to port 80).  I faked this call and it looks like my server sends back a redirect to HTTPS at the same URL.  So, for some reason, Heroku is making a non-secure call to Tableau Server to get the ticket and my Tableau Server is automatically redirecting non-secure calls to a secure version.  Since the code isn't expecting this, it just assumes that the first so many characters are the actual ticket.  So, does anyone have any idea why either 1)Heroku is making the call via HTTP or 2) why is my server trying to redirect to HTTPS?


      Just for a test, I removed the SOCKS_PROXY config param from Heroku and repeated my test.  After doing that, I just got a security exception in Heroku.  So, the SOCKS_PROXY must be required.  So, how do I get my Tableau Server instance to just send back a ticket instead of redirecting the call back to HTTPS?


      edit 2: Ok, I found a parameter in the wgserver.properties file called "ssl.redirect" and it was set to true.  I changed it to "false" and restarted my server and everything started working.  So, I know how to fix my immediate problem, but this doesn't seem right to me.  I couldn't find anything in the documentation about this and it doesn't seem terribly secure to set this flag to false.  Is there any reason why Heroku wouldn't just make the 'secure' call in the first place?  For a POC, this seems fine, but I have a difficult time imagining this being the way a server is supposed to be configured in a production environment.  Again, anyone who has any ideas on this, I would love to know that I just did something wrong in my setup.


        • 1. Re: Error handling trusted ticket

          Hi Chris,


          Thanks for the update.  The feedback is extremely helpful.  Unfortunately, Tableau Server does not support HTTPS tunneling which is what Heroku Proximo is trying to do behind the scenes.  It simply rejects the request.  So the other 2 options in Heroku are to request via HTTP or to go via SOCKS proxy and specifying an alternate port to connect, default being 1080.  The other option is to go the non Heroku route and setup your own tomcat instance but that will take a bit more effort to setup.

          • 2. Re: Error handling trusted ticket
            Chris O'Connell



            Thank you for the reply, but I don't think I'm following you.  You mention that there are 2 other options in Heroku.  I understand the first, which is to request via HTTP.  This is what I think I have been doing and I was able to work around this.  I don't understand the second.  I have configured Sparkler to use the SOCKS proxy by setting the environment variable in Heroku.  However, it is still making the post via HTTP.  I don't understand what you mean by specifying an alternate port, etc.  Is there documentation that outlines how to do this?  I'd love to give it a try, but I don't know what I would need to do to make this happen.




            • 3. Re: Error handling trusted ticket

              Sorry, I thought I provided that info.  Yes, it's not in the docs.  It probably needs to be in there..  Challenging piece is that there are so many ways to go about doing this. 


              So in heroku, set the following variables




              Default port socks goes off of is 1080 so to change it you can use this variable




              If you want detailed logging enabled for Sparkler set it to TRACE

              SPARKLER_LOG_LEVEL:             TRACE


              Keep in mind this is based on the proximo add-on being installed and the PROXIMO_URL being set via the addon.


              Hope this works out




              • 4. Re: Error handling trusted ticket
                Ben Sullins

                I am having this exact same issue. The strange part is it first started after we upgraded to 8.2.4 Prior to that it worked fine w/o changing any wgserver.properties


                samson.kim I'm not sure I follow your suggestion totally, but can you answer, if I change the wgserver.properties for the ssl.redirect and someone then tries to browse to our tableau server over http, will it not redirect them to https?


                If so that's not a deal breaker for us, I might just stand up my own redirect via a firewall or something. However, if it doesn't change that behavior I wouldn't see much of an issue with this considering the inherent security using trusted tickets and client ip matching.

                • 5. Re: Error handling trusted ticket
                  Carisa Chang

                  In Tableau Server 8.2 and later, any request that hits an SSL-enabled Tableau Server on port 80 is redirected to port 443 for security reasons. Prior to 8.2, trusted ticket requests were allowed on port 80 (which is why you saw the behavior change).


                  The original problem in this thread was the request for trusted ticket came in on port 80. You'd have to fix the Heroku config to use port 443.