Skip to content
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.

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

Websocket without auth will hang forever #925

Closed
2 tasks done
wenerme opened this issue Mar 14, 2022 · 3 comments · Fixed by #926
Closed
2 tasks done

Websocket without auth will hang forever #925

wenerme opened this issue Mar 14, 2022 · 3 comments · Fixed by #926
Assignees
Labels
bug Confirmed reproducible bug

Comments

@wenerme
Copy link

wenerme commented Mar 14, 2022

Defect

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

Versions of nats.go and the nats-server if one was involved:

  • nats.go 1.3.0
  • nats:2.7.3-alpine

OS/Container environment:

macos

Steps or code to reproduce the issue:

k -n nats port-forward svc/nats 8443:443

# hang
nats rtt -s ws://127.0.0.1:8443
# OK
nats rtt -s ws://127.0.0.1:8443 --creds /Users/wener/data/dl/nsc/nkeys/creds/KO/JS1/js-user.creds

server log

[7] 2022/03/14 11:07:36.458612 [ERR] 127.0.0.1:59596 - wid:99 - "v1.13.0:go:NATS CLI Version 0.0.30" - authentication error

Expected result:

report not authed

Actual result:

hang

@wenerme wenerme added the bug Confirmed reproducible bug label Mar 14, 2022
@kozlovic
Copy link
Member

@wenerme I will try to reproduce, but it would help a lot if you could show the configuration of the NATS Server and how you start it. Also, you mention using the Go client v1.3.0, but the "nats" tool uses go.mod and may have a different version. So would be good too to know "nats" specific version or git commit. Thanks!

@wenerme
Copy link
Author

wenerme commented Mar 14, 2022

@kozlovic tried running in code using 1.3.0 and latest version, debug found the hang at processConnectInit/sendConnect/readProto .

nats --version
0.0.30

Server is started by helm

nats:
  nats:
    jetstream:
      enabled: true
      domain: xxx
      memStorage:
        enabled: false
      fileStorage:
        # bases on usecase
        enabled: true
        storageClassName: openebs-zfspv
        size: 10Gi
  exporter:
    serviceMonitor:
      enabled: true
  mqtt:
    enabled: true
  websocket:
    enabled: true
    noTLS: true
    allowedOrigins:
    - "https://xxx"
  appProtocol:
    enabled: true

  cluster:
    enabled: false

  auth:
    enabled: true
    resolver:
      type: full
      allowDelete: true
      store:
        dir: "/accounts/jwt"
        size: 1Gi
      operator: XXX
      systemAccount: XXX
      resolverPreload:
        XXX: XXX
dependencies:
- name: nats
  version: 0.14.1
  repository: https://nats-io.github.io/k8s/helm/charts

@kozlovic
Copy link
Member

@wenerme Thanks! Yes, I was able to reproduce and will work on a fix. Stay tuned.

@kozlovic kozlovic self-assigned this Mar 14, 2022
kozlovic added a commit that referenced this issue Mar 14, 2022
This was due to the fact that server sends a websocket CLOSE protocol,
to which the library tried to respond to, but since it was done during
the "connect" handshake under the connection lock, this caused a
deadlock.

Resolves #925

Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Confirmed reproducible bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants