8000 login does not stick between controllers · Issue #65 · tchiotludo/akhq · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

login does not stick between controllers #65

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
ftardif opened this issue May 15, 2019 · 5 comments
Closed

login does not stick between controllers #65

ftardif opened this issue May 15, 2019 · 5 comments
Labels
question Further information is requested

Comments

@ftardif
Copy link
ftardif commented May 15, 2019

If I log in the app (let's say from the topic list page) and then I go in the consumergroup page, I see the login button on the lower left does not show me as logged in anymore. Then if I click on a given consumer group and I try to update the offset (the update button is available), it brings me back on the login page. If I log, I am back at the home of the app and if I navigate back to my consumer group, I am still not recognized as logged in.

my config is the following:

kafkahq:
  server:
    base-path: "/kafka/kafkahq"
  connections:
    kafka-vic:
      properties:
        bootstrap.servers: geo-kafka-broker.query.consul:9092
      schema-registry:
        url: http://geo-kafka-schema-registry.query.consul:8081

  security:
    default-roles:
      - topic/read
      - node/read
      - topic/data/read
      - group/read
      - registry/read
      - connect/read
    basic-auth: # admin/admin
      admin:
        password: 8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918
        roles:
          - topic/insert
          - topic/delete
          - topic/config/update
          - node/config/update
          - topic/data/insert
          - topic/data/delete
          - group/delete
          - group/offsets/update
          - registry/insert
          - registry/update
          - registry/delete
          - registry/version/delete
          - connect/
          - connect/insert
          - connect/update
          - connect/delete
          - connect/state/update
@tchiotludo
Copy link
Owner

Your configuration seems to be valid.
Just try with the last image, and can't reproduce the bug.

Difficult without more detail.

Maybe seeing the configuration your are behind a reverse proxy ?
Are you sure the cookie are keep between request ? (chrome, F12, application > cookie, there is a cookie SESSION that must be keep between page)

@ftardif
Copy link
Author
ftardif commented May 16, 2019

well I confirm that I don't have the problem when applying the same security configuration on your default docker-compose ran locally. So the problem must be I guess on the our reverse proxy configuration. Is there an easy way to log the http request coming in the kafkahq container to confirm if the SESSION header continues to be propagated downstream our reverse proxy?

@ftardif
Copy link
Author

My deployment had 3 hq containers load balanced behind an haproxy.
if I kill 2 hq and keep only a single instance, the auth starts behaving as expected!!!

here is a trace of a working session:
Could it be possible that hq stores the sessions in memory?

T 10.90.0.65:55224 -> 10.90.0.60:9001 [AP] #3478
POST /kafka/kafkahq/login HTTP/1.1.
Content-Length: 29.
Cache-Control: max-age=0.
Upgrade-Insecure-Requests: 1.
Content-Type: application/x-www-form-urlencoded.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36.
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3.
Accept-Encoding: gzip, deflate, br.
Accept-Language: en-US,en;q=0.9,fr;q=0.8.
Cookie: __bda_prst_languageandprovince=en-qc; __bda_prev_previouspagename=business%20units%3Anetwork%3Anews%3Aaccess%20forbidden; __bda_serial_sessionid=191331521371; __bda_serial_sidactionid=191331521371; __bda_pv=1; s_fid=3C4FE1731606BB1F-268F5AC578B49D52; s_cc=true; s_vi=[CS]v1|2E6CE1CF8507BB28-6000011C20002A0C[CE]; _ga=GA1.2.1334519545.1538751275; SESSION=OTI5ZDI1MGQtYjY0Mi00MWNlLWJmNDItMWQ5N2UxYTUxZDU4; _gid=GA1.2.1508820809.1557946823; VT_AUTH_JWT=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJleHAiOjE1NTgwMzc5MDMsImdyb3VwcyI6ImZvbnNlX3ByaXZpbGVnZSxmb25zZSxzdXBwb3J0LHJlcG9ydHMsZm9uc2VfYWRtaW4sZm9uc2Utb3BzLXRvb2xzLGxybXQiLCJ1c2VyIjoic2FtdWVsLmNhcnBlbnRpZXIiLCJhdHRyaWJ1dGVzIjoibGFzdG5hbWU9Q2FycGVudGllcixlbWFpbD1zYW11ZWwuY2FycGVudGllckBiZWxsLmNhLGZpcnN0bmFtZT1TYW11ZWwsaWQ9NjA5MDE3OSJ9.FeGtJmv2wjGWecqqZ3G_0ZXdfSMZFwU4xHbSheVVL5ZthARszUHf0R3deJhx1y_fNomUqjnVtGWeVE16nRg-tJR4DddL-smbiCJT8qPsqIA3V8aRTWcim2ptsfgh3D07hkocVYOE3HFnMmj_qFLlB_r71mxhR5os3IeN8y1vWIVq_mdSqHzv8N5t8cF9vI18_Mev1RT42V6otZTWKBDQhEGgmOcrkqqS1QzRGpZEkpjQ1OwIVMrs5u5b7ggTtPsM-wO11XS0jkx5q4f5N_jcZT2k5lztrABtwrnugv0TFopWQW2ecDqYLRSVfZmRnT8ur8Ro0IEtz_FWtJAQay-lzQ.
X-Forwarded-For: 10.21.85.9.
.
username=**&password=**

T 10.90.0.60:9001 -> 10.90.0.65:55224 [AP] #3480
HTTP/1.1 303 See Other.
Location: /kafka/kafkahq/.
set-cookie: SESSION=ODE3ZWNjNmUtODYyZi00NjNiLWExZWYtM2YwNzJkNTM2M2M2; Path=/; HTTPOnly.
Authorization-Info: 817ecc6e-862f-463b-a1ef-3f072d5363c6.
Date: Thu, 16 May 2019 12:21:56 GMT.
transfer-encoding: chunked.
connection: close.
.
0.


T 10.90.0.65:43486 -> 10.90.0.60:9001 [AP] #5093
GET /kafka/kafkahq/kafka-vic/topic/create HTTP/1.1.
Accept: text/html, application/xhtml+xml.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36.
Accept-Encoding: gzip, deflate, br.
Accept-Language: en-CA,en;q=0.9,fr-CA;q=0.8,fr;q=0.7,en-GB;q=0.6,en-US;q=0.5,nb;q=0.4.
Cookie: VT_AUTH_JWT=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJleHAiOjE1NTgwMzY4NTMsImdyb3VwcyI6ImZvbnNlX3ByaXZpbGVnZSxmb25zZSxzdXBwb3J0LGZvbnNlX2FkbWluLHJlcG9ydHMsZm9uc2Utb3BzLXRvb2xzLGxybXQtcmVhZG9ubHksbHJtdCIsInVzZXIiOiJmcmVkZXJpYy50YXJkaWYiLCJhdHRyaWJ1dGVzIjoibGFzdG5hbWU9VGFyZGlmLGVtYWlsPWZyZWRlcmljLnRhcmRpZkBiZWxsLmNhLGZpcnN0bmFtZT1GcmVkZXJpYyxpZD02MDI3Njc1In0.B3MPnZfAVu-CsjxBCtmvhHjHIQ6IU3K0S_KO_aZYDw0QNmNWOOVXItP6R_vSD4dTHqZOU6jTd987RYUQVetpJdYgzQl-6--vy5Tx-uLLG8QIs2SxsG2ZIo0PAgo-dCPUftaVmMKc_gn_LB7acW4C6OkCWveG76lDCyglzYzt7vFS6QRhQ6_R0_fGcmN0f-Jtf4Fb9xAOl3MxniAbtnMgVkFRGUi7N4PobiFISpywK01eBCmp-cf2VJe3gN2vAIRXvVbxkLezGzAnC6B8i8mHM8mqgoqx-SxJkaw45DbbM90tRdgeVpPa590UMexkXEJbYu6xDcD35aQ-EgnDoLgbSw; SESSION=NzRhMzRmYmUtZGQwMS00NjIyLWIzZTktYWQ3MzI0Y2JkYTk2.
X-Forwarded-For: 10.34.122.36.
.


T 10.90.0.60:9001 -> 10.90.0.65:43486 [AP] #5095
HTTP/1.1 200 OK.
Content-Type: text/html.
set-cookie: SESSION=NzRhMzRmYmUtZGQwMS00NjIyLWIzZTktYWQ3MzI0Y2JkYTk2; Path=/; HTTPOnly.
Authorization-Info: 74a34fbe-dd01-4622-b3e9-ad7324cbda96.
Date: Thu, 16 May 2019 12:25:30 GMT.
connection: keep-alive.
content-encoding: gzip.
content-length: 1427.

@tchiotludo
Copy link
Owner

I don't catch that you've multiple instance of KafkaHQ.
for now, session are store in memory, so this is the main reason.

2 solutions

@ftardif
Copy link
Author
ftardif commented May 16, 2019

Everything we deploy is always HA and typically geoD by default, including our ops tools. But I recognize this is maybe overkill for HQ. Anyway, for the moment, we simply scaled down to 1 instance and it works! I will explore your recommendation on haproxy session stickyness.

@tchiotludo tchiotludo added the question Further information is requested label May 16, 2019
tchiotludo added a commit that referenced this issue May 16, 2019
@tchiotludo
Add precision about session store
3388fea 
relate to #65
ghost pushed a commit that referenced this issue Jun 19, 2020
@goncaloValentim
Merge pull request #65 from polarising-oss/AKHQ-109
f6431f8 
AKHQ-109 - Fix Consumer Groups Details Members Assignments Display
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question Further information is requested
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ftardif @tchiotludo
0