Feature Request: Support for Custom NSURLSessionConfiguration in Native WebSocket Implementation

[shalom-aviv]

Reason for Changes

We encountered an issue on iOS versions earlier than iOs 17. In these versions, system-wide proxy settings are not applied to new instances of URLSessionWebSocketTask. This means that if the application relies on system-level proxy configurations, the WebSocket connections will bypass them.

To enable proxying for iOS versions below 17, proxy settings must be explicitly provided when creating the URLSession. Without this capability, developers cannot ensure that WebSocket traffic respects proxy configurations, leading to potential security and compliance issues in controlled network environments.

This limitation makes it critical to allow developers to pass a custom NSURLSessionConfiguration to the NativeWebSocket implementation.

proxyman: Capture WS/WSS from iOS

Description

Currently, the NativeWebSocket implementation uses URLSessionConfiguration.default for its NSURLSessionConfiguration. While this works for standard use cases, it becomes a limitation for advanced configurations where custom settings (e.g., proxy settings) are required. Without a way to inject a custom NSURLSessionConfiguration, developers are forced to use method swizzling, which is not ideal because:

1. Swizzling affects all instances of NSURLSession, leading to uncontrolled side effects.
2. It is impossible to control which parts of the codebase are impacted by these changes.

To address this, I have implemented changes that allow developers to pass a custom NSURLSessionConfiguration through the WebSocketTransport configuration. These changes are backward-compatible and provide a more flexible approach for advanced configurations.

Key Features Added:

1. Custom NSURLSessionConfiguration Injection:
   • Developers can now pass a custom URLSessionConfiguration provider to the NativeWebSocket through the WebSocketTransport configuration.
   • Example use case: Adding proxy settings to the WebSocket connection.
2. Backward Compatibility:
   • The default behavior remains unchanged, using URLSessionConfiguration.default if no custom provider is specified.

Code Changes:

1. Added urlSessionConfigurationProvider to NativeWebSocket
2. Utilized the Configuration in getOrCreateSession
3. Backward-Compatible Changes to CentrifugeClientConfig

Extended Example, now user can specify proxy params for centrifuge client.

Risks or Considerations:

• Potential Misuse of Configuration Provider: Developers need to ensure the custom URLSessionConfiguration is well-defined, as incorrect configurations could cause unexpected behavior.

Screenshot Descriptions

Below are screenshots to assist with configuring Charles Proxy and testing proxying of WebSocket traffic for CentrifugeClient:
1. Charles Proxy Configuration:
• The Charles Proxy server is set up on the local IP address 192.168.1.80 and listens for traffic on port 8889.
• The screenshot shows the necessary settings in the Charles application to enable WebSocket proxying.

2. Captured Traffic in Charles:
• This screenshot demonstrates successful interception of WebSocket traffic between the CentrifugeClient and the Centrifugo server.
• The server hosting Centrifugo is running on 192.168.1.136 with port 8000.

3. Application Proxy Settings:
• The screenshots shows the proxy settings applied directly within the application using the urlSessionConfigurationProvider configuration.

Proxy params	Proxy ON