[SQLLab] Regression: "share query" is broken behind https-only proxy

[rumbin]

Make sure these boxes are checked before submitting your issue - thank you!

• I have checked the superset logs for python stacktraces and included it here as text if any
• I have reproduced the issue with at least the latest released version of superset
• I have checked the issue tracker for the same issue and I haven't found one similar

Superset version

0.20.4

Expected results

Selecting share query from a tab's context menu copies the link for this very query.
This worked in superset 0.15.4, generating a link of the syntax http(s)://host/r/123

Actual results

Trying the same in 0.20.4 copies a link of the syntax http(s)://host/superset/sqllab?id=5.
Accessing the link yields a message THE QUERY COULDN'T BE LOADED

The workaround of first saving the query and then copying the link in the Saved Queries overview table works, but this is probably not the best way of quickly sharing a query.

Steps to reproduce

Selecting share query from a tab's context menu and try to access the copied URL.

[rumbin]

Interestingly, it may also happen, that simply nothing at all gets copied into the paste buffer. I haven't found a pattern, though.

[mistercrunch]

Tried to reproduce but couldn't. Maybe it's related to something in your application state? To confirm you can try to recreate in incognito mode.

[rumbin]

What I tried so far:

• browsers: Firefox, IE, Vivaldi
• Clearing browser history, cookies and cache in Vivaldi
• incognito mode in FF
• rebooting Windows7

None of this had any effect. What else could I try for debugging?
Is the URL pattern as it was in 0.15.4 still the one that is supposed to be generated in 0.20.4?

[rumbin]

Just tried it on a different client PC and got the same result.

I'd like to mention that the superset instance is running in an entirely fresh python 3.4 venv. I.e., the only part that has been migrated (superset db upgrade && superset init) was the superset database.

For this reason I'm particularly puzzled why you, Max, don't face the same issue...

[rumbin]

A little bit of debugging:

• When selecting share query from the tab's context menu, the action is confirmed by a Copied! popup. The console output changes from [stats_logger] (incr) queries (1 entry per second, BTW) to [stats_logger] (incr) store once.
• However, there is no new entry created in the superset's url table.
• Sharing of slices is working as it used to. So the creation of the entry in the url table is not an issue, apparently.

[mistercrunch]

But you get a url with an id don't you?

There should be an entry in the keyvalue table.

[rumbin]

• I do get an URL (most of the time), which is built like this one: https://hostname/superset/sqllab?id=17.
• And I do get an entry in the keyvalue table which carries this id and the corresponding SQL string .

However, when I try to load this URL again, superset claims:

Unfortunately, there is not the tiniest hint in the console log when calling this URL.

This is the bugzilla output:

When I try to access the redirect's target URL https://hostname/kv/17/, the page loads, showing the key-value tuple

In this very case now, the console log actually shows that the value got requested

Judging from the console log, it seems to me that the ...sqllab?id=17 URL did not even request the key-value entry.

---

Just in case that this may be the cause: we are using Postgres as OLTP database for superset.

[rumbin]

OK, it's not the DB's problem. It rather seems to be caused by our reverse-proxy configuration. SSH-ing to the machine and tunnelling port 8088 provided the full functionality.

I'll try to get this issue tackled with our nice guys from the IT dept, but would like to keep it open just in case someone could give me a hint why we observe this behavior when being behind the reverse proxy...

[rumbin]

Our IT found the issue being caused by the fact that the hostname/kv/[\d]* URL is called as http link, not as https. In our configuration http is not allowed though, but redirected to https. This is where the resolution fails somehow.

@mistercrunch: In my understanding this really seems to be a bug, as http should be used, if the rest of superset is served via https. Or is there anything wrong in our configuration, where we fail to tell superset that only https links should be generated?

[xrmx]

@rumbin a patch from your IT department is very welcome :)

[rumbin]

@xrmx Well they just checked their logs, not the source code. They are not developers. Neither am I, but I can have a look, if anyone gave me a hint to where to start looking....

[rumbin]

Our IT department got the issue sorted. The following Apache settings did the trick:

ProxyAddHeaders On
RequestHeader set X-Forwarded-Proto "https"
ProxyAddHeaders

This ensures the following flags are set: X-Forwarded-For, X-Forwarded-Host and X-Forwarded-Server.

[xrmx]

@rumbin Please add it to the documentation

[rumbin]

reopening, until documantation task is done;

BTW: Adding RequestHeader set X-Forwarded-Proto "https" is sufficient.