Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-3113

Websocket connection fails when connecting to protected URL (basic login)



      In a sample application for JSR356 support, added security constraints with basic log-in. The websocket endpoint is protect with basic log-in.

      When a websocket connection is attempted to the protected URL, there is inconsistent behavior in different browsers:
      1. Chrome fails with 401 error code and the log-in screen is not displayed at all.
      2. Firefox displays the log-in screen and the websocket is created and opened after the log-in succeeds.

      But in a different application, using Atmosphere - both connections fails:
      1. Chrome fails with the same error and the log-in screen is displayed after that. Most probably the log-in screen is triggered by Atmosphere when it falls back to long-polling
      2. Firefox - The login screen is displayed and if the log-in suceeds, the socket is created, but Atmosphere fails to process it.
      For example if the context root is "jsr356test" and the protected path is /pubsub/protected, Atmosphere tries to map /jsr356test/pubsub/protected (which in JSR356 is Session#getRequestURI()) but has mapping set-up for /pubsub/protected (which for a Http request would be the path info)
      Here is the related discussion on the Atmosphere users group:

      There is test WAR and source in the Atmosphere forum to reproduce the problem.

        Gliffy Diagrams




              • Assignee:
                swd847 Stuart Douglas
                alexandre.nikolov Alexandre Nikolov
              • Votes:
                0 Vote for this issue
                2 Start watching this issue


                • Created: