<div dir="ltr">Hi Michael,<br><div class="gmail_extra"><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"> * It will be hard to justify supporting such a homegrown authentication scheme<br>
</blockquote><br></div><div class="gmail_extra">Well it won't need that much support as the changes are minimal and impact just a few lines of code in two source files, and also it'll be just a temporary solution till proper support for SSL client auth will be implemented :)<br>
<br></div><div class="gmail_extra"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"> * It may also run into limitations in SockJS<br></blockquote><br>
</div><div class="gmail_extra">What kind of limitations do you mean here?<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">So I'd recommend combining HTTPS connection with credentials obtained from an HTTPS endpoint in your JS application.<br>
</blockquote><br></div><div class="gmail_extra">We have considered this approach, however the problem is that the JS code initiating the websocket connection runs in the user's web browser, and this makes such kind of solutions rather insecure. <br>
On the other side using client certificate data for authentication is both secure and happens completely transparently to the end-user.<br><br></div><div class="gmail_extra">So, I'd be very grateful if you could take a closer look at the solution I've previously suggested and provide some hints on which changes should be applied to the sockjs-erlang-wrapper and web-stomp source in order to implement it.. unfortunately I'm having a bit of a hard time figuring out where exactly to add that additional HTTP header processing code..<br>
<br></div><div class="gmail_extra">Another issue I ran into playing with this is an error showing up when trying to compile the original web-stomp plugin from the rabbitmq-public-umbrella:<br><br>../cowboy-wrapper/cowboy-git/src/cowboy_clock.erl: undefined parse transform 'eunit_autoexport'<br>
make: *** [../cowboy-wrapper/ebin/cowboy_clock.beam] Error 1<br><br></div><div class="gmail_extra">Could you please shed some light on this? I've checked out the latest rabbitmq-public-umbrella and my Erlang version is R16B02.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">Also, maybe you missed my last question from last time:<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
P.S.: Although you have CCd rabbitmq-discuss group in the previous
messages, somehow these are not visible to me on the Rabbitmq-discuss
Google Group. Are there some viewing or access restrictions set up?<br></blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra">Thank you!<br><br></div><div class="gmail_extra">Best regards,<br>Andy.<br>
</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 19, 2014 at 10:30 AM, Michael Klishin <span dir="ltr"><<a href="mailto:mklishin@gopivotal.com" target="_blank">mklishin@gopivotal.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">On 18 June 2014 at 19:51:57, Andrei (<a href="mailto:andrei002@gmail.com">andrei002@gmail.com</a>) wrote:<br>
> > 1. Is there any possibility for this feature to be implemented<br>
> in one of the next releases, in order for Web-STOMP to be fully<br>
> compatible with STOMP plugin?<br>
><br>
> 2. In case it is too complex to implement due to lack of client SSL<br>
> authentication mechanisms in Cowboy, could it be implemented<br>
> in the following way, as a workaround?<br>
<br>
</div>It's possible to add SSL certificate authentication to Web STOMP<br>
but it may involve upgrading Cowboy and SockJS first => not a trivial amount of work.<br>
<br>
The workaround you suggest may work but<br>
<br>
* It will be hard to justify supporting such a homegrown authentication scheme<br>
* It may also run into limitations in SockJS<br>
<br>
So I'd recommend combining HTTPS connection with credentials obtained from an HTTPS<br>
endpoint in your JS application. This is not great but largely is the state of<br>
the art in Web messaging authentication. Fairly big Web players recommend something<br>
very similar [1].<br>
<br>
1. <a href="https://devcenter.heroku.com/articles/websocket-security" target="_blank">https://devcenter.heroku.com/articles/websocket-security</a> <br>
<div class=""><div class="h5">--<br>
MK<br>
<br>
Software Engineer, Pivotal/RabbitMQ<br>
</div></div></blockquote></div><br></div></div>