Putting Yellowfin behind a Zuul gateway
We're currently running yellowfin 9.2
In an attempt to be able to control session timeouts in our application suite, I have been attempting to put our Yellowfin behind a Zuul gateway.
I'm 99% of the way there.
The one problem I'm left with is that the first access of yellowfin includes a call that looks like this:
<gateway-address>/<sub-path>/BrowserCheck.i4;jsessionid=<yellowfin-session-id>
And ZUUL kicks merry heaven about having a semicolon in the path and throws an error page up. If i then press <F5> the gateway attempts to get into Yellowfin again and succeeds.
Nomally Yellowfin appears to _not_ put the jsessionid into the path, it seems to appear just this once. I'd surmise that its checking to see if it can use cookies...
I believe I can configure zuul to ignore semi-colons in paths, however the whole point of my exercise is to pass various security penetration test issues, and disabling any security feature like this is rather frowned upon.
My question: is this path (<blah>BrowserCheck.i4;jsessionid=<blah>) being generated by Yellowfin or is it something in Tomcat that's doing this? In either case do you know of anyway I could disable this?
The same question
Hi Peter,
It's a bit odd that a semi-colon is causing issues for you, as in Javascript it shouldn't create any weird behaviours, as long as it's contained within single or double quotes.
Anything with i4 in the name generally forms part of the core Yellowfin codebase, and BrowserCheck.i4 is an intermediary page between login.i4 and MIEntry.i4
I had a look through all of our documentation and existing tickets but was unable to find anything related to disabling it.
Are you able to circumvent the problem with the semi-colon? If it becomes a sticking point for you, I could ask the wider team if it's possible to avoid/disable it.
Kind regards,
Chris
Hi Peter,
It's a bit odd that a semi-colon is causing issues for you, as in Javascript it shouldn't create any weird behaviours, as long as it's contained within single or double quotes.
Anything with i4 in the name generally forms part of the core Yellowfin codebase, and BrowserCheck.i4 is an intermediary page between login.i4 and MIEntry.i4
I had a look through all of our documentation and existing tickets but was unable to find anything related to disabling it.
Are you able to circumvent the problem with the semi-colon? If it becomes a sticking point for you, I could ask the wider team if it's possible to avoid/disable it.
Kind regards,
Chris
For the moment I've had to (i) configure zull to allow urls with semicolons in (ii) add extra security config in zuul to reject requests with semi-colons in unless that request is "<blah>BrowserCheck.i4;jsessionid=<blah>"
I'm hoping that the code i've done in (ii) will be good enough to pass the penetration test... If not I'll probably come back to you... May as well close for now.
For the moment I've had to (i) configure zull to allow urls with semicolons in (ii) add extra security config in zuul to reject requests with semi-colons in unless that request is "<blah>BrowserCheck.i4;jsessionid=<blah>"
I'm hoping that the code i've done in (ii) will be good enough to pass the penetration test... If not I'll probably come back to you... May as well close for now.
Hi Peter,
Okay thanks for letting me know. Keep me informed with how it goes!
Kind regards,
Chris
Hi Peter,
Okay thanks for letting me know. Keep me informed with how it goes!
Kind regards,
Chris
Hmm.
This turns out related to the mix of http and https that we have behind the (main, external) firewall, the JSESSIONID cookie ending upon the path was a result of that rather than anyone's explicit coding.
Hmm.
This turns out related to the mix of http and https that we have behind the (main, external) firewall, the JSESSIONID cookie ending upon the path was a result of that rather than anyone's explicit coding.
Hi Peter,
Thanks for letting me know. I know that having both HTTP and HTTPS can cause some problems. If you were able to nail down the cause, shall I go ahead and close this ticket?
Kind regards,
Chris
Hi Peter,
Thanks for letting me know. I know that having both HTTP and HTTPS can cause some problems. If you were able to nail down the cause, shall I go ahead and close this ticket?
Kind regards,
Chris
Yes, best close.
Thanks for listening.
Peter
Yes, best close.
Thanks for listening.
Peter
Replies have been locked on this page!