> -----Original Message----- > From: Bob DeRemer [mailto:bob.dere...@thingworx.com] > Sent: Monday, September 09, 2013 1:30 PM > To: Tomcat Users List > Subject: RE: how to access HTTP response from jsr-356 > ServerEndpointConfig.Configurator.modifyHandshake? > > > > > -----Original Message----- > > From: Niki Dokovski [mailto:nick...@gmail.com] > > Sent: Monday, September 09, 2013 1:11 PM > > To: Tomcat Users List > > Subject: Re: how to access HTTP response from jsr-356 > > ServerEndpointConfig.Configurator.modifyHandshake? > > > > On Mon, Sep 9, 2013 at 5:26 PM, Bob DeRemer > > <bob.dere...@thingworx.com>wrote: > > > > > Thanks for the direction on using the respective Client/Server > > > EndpointConfig.Configurator plumbing to do a pre-connection AUTH. > > > Unfortunately, I'm stuck on the server side when trying to actually > > > modify the HTTP response result code from within the Configurator. > > > It doesn't appear that the HandshakeResponse [or anything else that > > > I could see] provides access to modify the actual HTTP response - > > > setting it to > > 403 if > > > the AUTH fails. In fact, from looking at the UpgradeUtil.doUpgrade, it > > > seems that the decision to upgrade has already been made by the time > > > the modifyHandshake override gets called. > > > > > Yes the decision is'already made at that point. In this version of the > > spec and current implementation, the only place to actully provide > > different status code (aka 403) is when checkOrigin returns false. > > http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpo > > intC > > onfig.Configurator.html#checkOrigin(java.lang.String) > > > > I don't know wether this works in your case, but for sure the next > > spec revision could try to provide more application control in > "modifyHandshake" > > > > checkOrigin would work if there was some way to gain access to the client > supplied headers. Is there any way for my checkOrigin method to get access to > the calling request and associated HTTP headers? If not, then I'm not sure > how > to perform a pre-connected AUTH check based on the current implementation. > > if there are any other suggestions, please LMK; meanwhile, I'll keep digging > to > see if there's another solution. > > Thx,bob >
After looking at the options available and going through the websocket protocol specification again, I've found a better solution for authenticating using a JSR-356 implementation than the original concept of using ServerEndpointConfig.Configurator.modifyHandshake. The new approach still uses custom Client and Server EndpointConfig/Configurator instances to pass security information during the handshake, but instead of rejecting the handshake, it's cleaner to grab the security information in the OnOpen (from the ServerEndpointConfig) of the actual endpoint. At this point, simply perform whatever AAA you wish - calling close with an appropriate CloseReason if AAA fails. With regard to DOS and opening websocket connections: The websocket protocol already prohibits multiple clients from being in the connecting/handshake phase at once, which already helps reduce the DOS surface area. In addition, the client and/or server side implementations can add additional logic to prohibit the number of concurrent connections from the same client endpoint based on configuration. And, yes, once I get it done and tested, I'll write this up. -bob > > cheers > > Niki > > > > > > > > **** > > > > > > ** ** > > > > > > If I'm missing anything, please let me know.**** > > > > > > ** ** > > > > > > Thanks,**** > > > > > > ** ** > > > > > > *Bob DeRemer* > > > > > > *Senior Director, Architecture and Development* > > > > > > ** ** > > > > > > [image: Description: Description: Description: Description: > > > cid:image001.png@01CBE3DE.51A12030]**** > > > > > > http://www.thingworx.com**** > > > > > > Skype: bob.deremer.thingworx**** > > > > > > O: 610.594.6200 x812**** > > > > > > M: 717.881.3986**** > > > > > > ** ** > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
