Alexandre Nikolov created WFLY-3113: --------------------------------------- Summary: 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: Bug 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 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 because the reques.getPathInfo() returns the context root prepended to the path info. For example if the context root is "jsr356test" and the protected path is /pubsub/protected, the path info returned is /jsr356test/pubsub/protected instead of /pubsub/protected 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira