Websocket connection fails when connecting to protected URL (basic login) ------------------------------------------------------------------------- Key: WFLY-3113 URL: https://issues.jboss.org/browse/WFLY-3113 Project: WildFly Issue Type: Clarification Security Level: Public(Everyone can see) Components: Web (Undertow) Affects Versions: 8.0.0.Final Environment: WildFly 8.0.0.Final, Windows 8, RedHat Linux Chrome, Firefox Reporter: Alexandre Nikolov Assignee: Stuart Douglas Labels: jsr356,, 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: https://groups.google.com/forum/#!topic/atmosphere-framework/ntIHOohlYIc There is test WAR and source in the Atmosphere forum to reproduce the problem.