This resolves a race condition where data could be written to a NULL
FILE pointer causing a crash as a websocket connection was in the
process of shutting down by adding locking to websocket session writes
and by deferring session teardown until session destruction.
(closes issue ASTERISK-23605)
Review: https://reviewboard.asterisk.org/r/3481/
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@413123 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Several fixes for the WebSockets implementation in res/res_http_websocket.c
* Flush the websocket session FILE* as fwrite() may not actually guarantee sending
the data to the network. If we do not flush, it seems that buffering on the SSL
socket for outbound messages causes issues
* Refactored ast_websocket_read to take into account that SSL file descriptors
may be ready to read via fread() but poll() will not actually say so because
the data was already read from the network buffers and is now in the libc buffers
(closes issue ASTERISK-23099)
(closes issue ASTERISK-21930)
Review: https://reviewboard.asterisk.org/r/3248/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@409681 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The WebSocket code would allocate, on the stack, a string large enough
to hold a key provided by the client, and the WEBSOCKET_GUID. If the key
is NULL, this causes a segfault. If the key is too large, it could
overflow the stack.
This patch checks the key for NULL and checks the length of the key to
avoid stack smashing nastiness.
(closes issue ASTERISK-21825)
Reported by: Alfred Farrugia
Tested by: Alfred Farrugia, David M. Lee
Patches:
issueA21825_check_if_key_is_sent.patch uploaded by Walter Doekes (license 5674)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@391560 65c4cc65-6c06-0410-ace0-fbb531ad65f3
