SignalR-Client-Swift
SignalR-Client-Swift copied to clipboard
Reason for connection closed by server not passed on in connectionDidClose delegate method.
PROBLEM: Actual error message returned by server is not passed on to the delegate connectionDidClose() method
If I pass wrong authentication code (which I received in login API) to the server then server dont create connection (wihch is our business requirement) and returns a error message which I can see in logs printed by library (Message received: {“type”:7,“error”:“Connection closed with an error. HubException: Provided auth-code is failed to authorize.“}) as mentioned below in logs, subsequently connectionDidStop() method is called but I recieve error = nil or sometime improper message like not found 404 etc. But not the actual reason which is printed by createHubMessage(payload: Data) in JSONHubProtocol class
Expected behavior
connectionDidClose() should return the reason that is printed in debug logs i.e "Connection closed with an error. HubException: Provided auth-code is failed to authorize."
Logs
2020-09-30T10:22:36.841Z debug: Data received 2020-09-30T10:22:36.841Z debug: Processing handshake response: {} ======connectionDidOpen(hubConnection:)====== 2020-09-30T10:22:36.842Z debug: Payload contains 0 message(s) 2020-09-30T10:22:36.845Z debug: Received data from transport 2020-09-30T10:22:36.845Z debug: Data received 2020-09-30T10:22:36.846Z debug: Payload contains 1 message(s) 2020-09-30T10:22:36.846Z debug: Message received: {“type”:7,“error”:“Connection closed with an error. HubException: Provided auth-code is failed to authorize.“} 2020-09-30T10:22:36.848Z info: WebSocket close. Clean: true, code: 1000, reason: 2020-09-30T10:22:36.848Z info: Transport closed 2020-09-30T10:22:36.848Z debug: Attempting to chage state from: ‘(nil)’ to: ‘stopped’ 2020-09-30T10:22:36.848Z debug: Changing state to: ‘stopped’ succeeded SwiftSignalRClient was compiled with optimization - stepping may behave oddly; variables may not be available. 2020-09-30T10:22:36.848Z debug: Previous state connected 2020-09-30T10:22:39.618Z debug: Invoking connectionDidClose (transportDidClose(_:): 260) 2020-09-30T10:22:49.549Z info: Stopping connection 2020-09-30T10:22:49.549Z debug: Attempting to chage state from: ‘(nil)’ to: ‘stopped’ 2020-09-30T10:22:49.549Z debug: Changing state to: ‘stopped’ succeeded 2020-09-30T10:22:49.549Z info: Connection already stopped 2020-09-30T10:22:49.550Z info: HubConnection closing with error: nil 2020-09-30T10:22:49.551Z info: Terminating 0 pending hub methods ======connectionDidClose(error:) error=nil ======
Code To Reproduce the Issue
- Running the app which creates connection with the provided SignalR URL
- Passing invalid auth-code in header.
Additional context
As per our requirement server should not establish a connection if provided auth-code in header in HubConnectionBuilder.withHttpConnectionOptions is invalid.
Any help would by highly appreciatable! Thanks in advance
Looks like a race. WebSocket was closed immediately after the Close message was received so there were two invocations to connectionDidClose in progress at the same time. One was initiated by the Close message, one was initiated by the transport closure. The transport closure was clean (code 1000) so it did not have an error. The Close message should have the error as per:
https://github.com/moozzyk/SignalR-Client-Swift/blob/48e0ec1a8cc875129fae4a6d1da77fcbec053e73/Sources/SignalRClient/HubConnection.swift#L336-L337
but it lost the race. Since connectionDidClose can be only invoked once the subsequent invocation was discarded:
2020-09-30T10:22:49.549Z info: Connection already stopped
Side note: This has nothing to do with authorization and the authorization here is some custom implementation. When using the built-in auth any request would be rejected (401 AFAIR) if it did not pass auth. Here a webSocket is opened just fine and the connection is started successfully and only later the connection is closed over SignalR connection via the Close message.
Thanks @moozzyk for a great library and insights about my problem. We have come around a workaround to use an observer method named "globalError" that returns error message in closure which allows me to take relevant actions.
I am glad you were able to find workaround!