[jboss-jira] [JBoss JIRA] (WFLY-3113) Websocket connection fails when connecting to protected URL (basic login)

[Alexandre Nikolov (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-3113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952885#comment-12952885 ] 

Alexandre Nikolov commented on WFLY-3113:
-----------------------------------------

After further investigation, I think this is not a problem with WildFly, but a combination of two different issue with:
1. Chrome connecting to protected endpoint
2. Atmosphere when the incoming connection is to protected endpoint.

With unprotected endpoint everything works as expected.

So I am changing this issue type to "Clarification". Probably someone needs to take this with Chrome dev. team.
                
> 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 wuld 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.

--
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