[
https://issues.apache.org/jira/browse/KNOX-3033?focusedWorklogId=919546&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919546
]
ASF GitHub Bot logged work on KNOX-3033:
----------------------------------------
Author: ASF GitHub Bot
Created on: 15/May/24 15:25
Start Date: 15/May/24 15:25
Worklog Time Spent: 10m
Work Description: moresandeep commented on code in PR #912:
URL: https://github.com/apache/knox/pull/912#discussion_r1601848944
##########
gateway-provider-ha/src/main/java/org/apache/knox/gateway/ha/dispatch/ConfigurableHADispatch.java:
##########
@@ -121,9 +123,16 @@ public void init() {
/* setup the active URL for non-LB case */
activeURL.set(haProvider.getActiveURL(getServiceRole()));
- // Suffix the cookie name by the service to make it unique
- // The cookie path is NOT unique since Knox is stripping the service name.
- stickySessionCookieName = stickySessionCookieName + '-' + getServiceRole();
+ // TODO I'm not sure that appending the role to the cookie name (or the
alternative of setting the correct cookie path)
+ // is really necessary.
+ // Knox sets a single session cookie for a topology, and I don't see how
that would be used for multiple services.
+ // I think only a seriously broken client would mix up the sticky cookies,
and even then
+ // Knox would drop any sticky cookie that does not point to a proper
backend.
+ if (!useRoutesForStickyCookiePath) {
Review Comment:
i see what you are trying to do, if routes are set then scope the cookie
based on path. There are few problems with this approach.
We have default topology feature
(https://knox.apache.org/books/knox-1-1-0/user-guide.html#Default+Topology+URLs)
where services do not need to specify context, we do that for CM. Not sure
how this will be impacted.
Debugging would be tricky with this given cookies names won't be intuitive.
##########
gateway-provider-ha/src/main/java/org/apache/knox/gateway/ha/dispatch/ConfigurableHADispatch.java:
##########
@@ -121,9 +123,16 @@ public void init() {
/* setup the active URL for non-LB case */
activeURL.set(haProvider.getActiveURL(getServiceRole()));
- // Suffix the cookie name by the service to make it unique
- // The cookie path is NOT unique since Knox is stripping the service name.
- stickySessionCookieName = stickySessionCookieName + '-' + getServiceRole();
+ // TODO I'm not sure that appending the role to the cookie name (or the
alternative of setting the correct cookie path)
+ // is really necessary.
Review Comment:
This is needed because a topology can have multiple services and those
services can have sticky enabled and disabled. So, a topology can have one
service with sticky session ON and other with OFF. This is the reason for
appending the service name.
Issue Time Tracking
-------------------
Worklog Id: (was: 919546)
Time Spent: 0.5h (was: 20m)
> Add option to set the correct path for sticky session cookies instead of
> appending the role name
> ------------------------------------------------------------------------------------------------
>
> Key: KNOX-3033
> URL: https://issues.apache.org/jira/browse/KNOX-3033
> Project: Apache Knox
> Issue Type: Improvement
> Components: Server
> Reporter: Istvan Toth
> Assignee: Istvan Toth
> Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I have tried to override the sticky session cookie name by using the
> following HA parameter:
> {noformat}
> <param>
> <name>WEBHBASE</name>
>
> <value>enableStickySession=true;noFallback=true;enableLoadBalancing=true;stickySessionCookieName=STICKYCOOKIE</value>
> </param>
> {noformat}
> However, KNOX still appended the service name to the cookie name:
> {noformat}
> 24/04/30 08:25:11 DEBUG http.wire: http-outgoing-0 << "Set-Cookie:
> STICKYCOOKIE-WEBHBASE=58d004bcaccfddfdc69739ea053505c69b2679d6fc1da6f7e46d3907be2d1e6c;
> Path=/gateway/cdp-proxy-api-stoty; Secure; HttpOnly[\r][\n]"
> {noformat}
> AFAICT the point of overriding the cookie name would be integrating with
> other components (like a cloud LB) that expect a specific cookie name.
> Appending the service name after the specified cooke name defeats this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
