Socket_mode internals uses its own SSL context and not the one provided by the client

[charlch]

SocketModeHandler doesn't seem to use the ssl_context provided to it by the client passed to it.
I think it should use the context provided if available and fall back to the default context if not.

I'm work on a fix here: charlch@afd7cf0

Reproducible in:

pip freeze | grep slack
python --version
sw_vers && uname -v # or `ver`

The Slack SDK version

slack-sdk==3.14.1

Python runtime version

Python 3.6.5 |Man Group Plc| (default, Jul  4 2019, 14:15:57) 
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

OS info

LSB Version:	:core-4.1-amd64:core-4.1-noarch
Distributor ID:	CentOS
Description:	CentOS Linux release 7.5.1804 (Core) 
Release:	7.5.1804

Expected result:

I expect to be able to provide an SSL context for the websockets to use.
I can provide one to the WebClient:

WebClient(token=BOT_TOKEN, ssl=ssl_context)

and I want to use the same context for the websocket.

Actual result:

When the SocketModeHandler constructs a Connection it uses ssl.create_default_context() for the context:

and not the one I provide.

Requirements

For general questions/issues about Slack API platform or its server-side, could you submit questions at https://my.slack.com/help/requests/new instead. 🙇

Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.

[seratch]

Hi @charlch, thanks a lot for taking the time to report this issue and the suggestion to fix it!

Your changes look great to me 👍 If you don't mind, could you send a pull request to this repo?

[charlch]

Hi @seratch, I just need get the validation, codegen, black and lint steps run and fixed before I raise the pull request.
(unless you're happy with the change here anyway: charlch@afd7cf0)
Should have some time to run those and raise the PR within the next day

[seratch]

Fixed by #1177 - @charlch Thanks a lot for fixing this quickly! As for the next release, #1176 is the last remaining task. Once that PR is merged, we'll ship a new minor version shortly!