When building using the CLI, everything seems to work OK, until I look at the console in for the preview, then I see that there are some missing files. Here's the console output:
Android:
Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check http://xhr.spec.whatwg.org/.
GET http://localhost:10080/MyProject/apps/services/preview/MyApp/android/1.0/default/cordova/cordovasim.js 404 (Not Found)_mbs_cordova_sim_load_js # cordova.js:21(anonymous function) # cordova.js:53
worklight.js:5138 Uncaught Exception: Uncaught ReferenceError: cordova is not defined at (compiled_code):16156WL.Logger.__log # worklight.js:5138WL.Logger.$.each.PUBLIC_API.(anonymous function) # worklight.js:5520WL.Logger.window.onerror # worklight.js:5478
worklight.js:16156 Uncaught ReferenceError: cordova is not defined(anonymous function) # worklight.js:16156
worklight.js:5134 Initialization option 'connectOnStartup' is deprecated. Use WL.Client.connect() to connect to the IBM MobileFirst Platform Server.
worklight.js:5134 wlclient init started
dependencies.js:10 WL not defined ReferenceError: cordova is not defined
at klass.WL.BusyIndicator.WLJSX.Class.create.show (http://localhost:10080/MyProject/apps/services/preview/MyApp/android/1.0/default/worklight/worklight.js:12157:6)
at __showBusy (http://localhost:10080/MyProject/apps/services/preview/MyApp/android/1.0/default/worklight/worklight.js:7345:18)
at onEnvInit (http://localhost:10080/MyProject/apps/services/preview/MyApp/android/1.0/default/worklight/worklight.js:7660:14)
at init (http://localhost:10080/MyProject/apps/services/preview/MyApp/android/1.0/default/worklight/worklight.js:8128:4)
at http://localhost:10080/MyProject/apps/services/preview/MyApp/android/1.0/default/assets/js/dependencies.js:10:990(anonymous function) # dependencies.js:10
angular-libs.js:8 [10:40:49]MyApp.home.controller :: [INFO] Welcome to MyApp
iPhone:
http://localhost:10080/MyProject/apps/services/preview/MyApp/iphone/1.0/default/worklight/cordova.js Failed to load resource: the server responded with a status of 404 (Not Found)_mbs_cordova_sim_load_js # cordova.js:21
cordova.js:26 Uncaught ReferenceError: cordova is not defined
worklight.js:5134 Initialization option 'connectOnStartup' is deprecated. Use WL.Client.connect() to connect to the IBM MobileFirst Platform Server.
worklight.js:5134 wlclient init started
worklight.js:5134 Request [/MyProject/apps/services/api/MyApp/iphone/init]
worklight.js:5134 Application details header: {"applicationDetails":{"platformVersion":"7.0.0.0","nativeVersion":"1161280635"}}WL.Logger.__log # worklight.js:5134
http://localhost:10080/MyProject/apps/services/api/MyApp/iphone/init Failed to load resource: the server responded with a status of 401 (Unauthorized)
worklight.js:5134 Application details header: {"applicationDetails":{"platformVersion":"7.0.0.0","nativeVersion":"1161280635"}}WL.Logger.__log # worklight.js:5134
worklight.js:5134 Request [/MyProject/apps/services/api/MyApp/iphone/init]
angular-libs.js:8 [10:38:54]MyApp.home.controller :: [INFO] Welcome to MyApp
http://localhost:10080/favicon.ico Failed to load resource: the server responded with a status of 404 (Not Found)
worklight.js:5134 response [/MyProject/apps/services/api/MyApp/iphone/init] success: /*-secure-
{"userPrefs":{},"WL-Authentication-Success":{"wl_directUpdateRealm":{"userId":"null","attributes":{},"isUserAuthenticated":1,"displayName":"null","deviceId":"null"},"wl_remoteDisableRealm":{"userId":"null","attributes":{},"isUserAuthenticated":1,"displayName":"null","deviceId":"null"},"wl_antiXSRFRealm":{"userId":"1n4ulchkhlmjgom2cmafk8qvpm","attributes":{},"isUserAuthenticated":1,"displayName":"1n4ulchkhlmjgom2cmafk8qvpm","deviceId":"1n4ulchkhlmjgom2cmafk8qvpm"},"wl_deviceNoProvisioningRealm":{"userId":"previewDummyId","attributes":{"mobileClientData":"com.worklight.core.auth.ext.MobileClientData#ff55f"},"isUserAuthenticated":1,"displayName":"previewDummyId","deviceId":"previewDummyId"},"wl_anonymousUserRealm":{"userId":"6ba49e22-f899-4b14-ae72-fc4fde9100de","attributes":{},"isUserAuthenticated":1,"displayName":"6ba49e22-f899-4b14-ae72-fc4fde9100de","deviceId":"6ba49e22-f899-4b14-ae72-fc4fde9100de"}},"gadgetProps":{"ENVIRONMENT":"iphone"},"userInfo":{"SubscribeServlet":{"userId":null,"attributes":{},"isUserAuthenticated":0,"displayName":null,"deviceId":null},"wl_directUpdateRealm":{"userId":"null","attributes":{},"isUserAuthenticated":1,"displayName":"null","deviceId":"null"},"wl_authenticityRealm":{"userId":null,"attributes":{},"isUserAuthenticated":0,"displayName":null,"deviceId":null},"SampleAppRealm":{"userId":null,"attributes":{},"isUserAuthenticated":0,"displayName":null,"deviceId":null},"wl_remoteDisableRealm":{"userId":"null","attributes":{},"isUserAuthenticated":1,"displayName":"null","deviceId":"null"},"wl_antiXSRFRealm":{"userId":"1n4ulchkhlmjgom2cmafk8qvpm","attributes":{},"isUserAuthenticated":1,"displayName":"1n4ulchkhlmjgom2cmafk8qvpm","deviceId":"1n4ulchkhlmjgom2cmafk8qvpm"},"wl_deviceAutoProvisioningRealm":{"userId":null,"attributes":{},"isUserAuthenticated":0,"displayName":null,"deviceId":null},"wl_deviceNoProvisioningRealm":{"userId":"previewDummyId","attributes":{"mobileClientData":"com.worklight.core.auth.ext.MobileClientData#ff55f"},"isUserAuthenticated":1,"displayName":"previewDummyId","deviceId":"previewDummyId"},"myserver":{"userId":"6ba49e22-f899-4b14-ae72-fc4fde9100de","attributes":{},"isUserAuthenticated":1,"displayName":"6ba49e22-f899-4b14-ae72-fc4fde9100de","deviceId":"6ba49e22-f899-4b14-ae72-fc4fde9100de"},"wl_anonymousUserRealm":{"userId":"6ba49e22-f899-4b14-ae72-fc4fde9100de","attributes":{},"isUserAuthenticated":1,"displayName":"6ba49e22-f899-4b14-ae72-fc4fde9100de","deviceId":"6ba49e22-f899-4b14-ae72-fc4fde9100de"}}}*/
worklight.js:5788 No matching configurations found from the server. Defaulting to local configuration
worklight.js:5134 wlclient connect success
worklight.js:5134 before: initOptions.onSuccess
worklight.js:5134 after: initOptions.onSuccess
worklight.js:5134 wlclient init success
worklight.js:5134 Request [/MyProject/apps/services/loguploader]
worklight.js:5134 Application details header: {"applicationDetails":{"platformVersion":"7.0.0.0","nativeVersion":"1161280635"}}WL.Logger.__log # worklight.js:5134
worklight.js:5134 Request [/MyProject/apps/services/loguploader]
worklight.js:5134 Application details header: {"applicationDetails":{"platformVersion":"7.0.0.0","nativeVersion":"1161280635"}}WL.Logger.__log # worklight.js:5134
worklight.js:5134 response [/MyProject/apps/services/loguploader] success:
worklight.js:5701 Client logs successfully sent to the server
worklight.js:5134 response [/MyProject/apps/services/loguploader] success:
worklight.js:5701 Client logs successfully sent to the server
worklight.js:5134 Piggybacking event transmission
worklight.js:5134 Flush called
worklight.js:5134 Request [/MyProject/apps/services/api/MyApp/iphone/heartbeat]
worklight.js:5134 Application details header: {"applicationDetails":{"platformVersion":"7.0.0.0","nativeVersion":"1161280635"}}WL.Logger.__log # worklight.js:5134
worklight.js:5134 response [/MyProject/apps/services/api/MyApp/iphone/heartbeat] success:
worklight.js:5134 Heartbeat sent successfully
worklight.js:5134 Piggybacking event transmission
worklight.js:5134 Flush called
worklight.js:5134 Request [/MyProject/apps/services/api/MyApp/iphone/heartbeat]
worklight.js:5134 Application details header: {"applicationDetails":{"platformVersion":"7.0.0.0","nativeVersion":"1161280635"}}WL.Logger.__log # worklight.js:5134
worklight.js:5134 response [/MyProject/apps/services/api/MyApp/iphone/heartbeat] success:
worklight.js:5134 Heartbeat sent successfully
worklight.js:5134 Piggybacking event transmission
worklight.js:5134 Flush called
worklight.js:5134 Request [/MyProject/apps/services/api/MyApp/iphone/heartbeat]
worklight.js:5134 Application details header: {"applicationDetails":{"platformVersion":"7.0.0.0","nativeVersion":"1161280635"}}WL.Logger.__log # worklight.js:5134
worklight.js:5134 response [/MyProject/apps/services/api/MyApp/iphone/heartbeat] success:
worklight.js:5134 Heartbeat sent successfully
worklight.js:5134 Piggybacking event transmission
worklight.js:5134 Flush called
worklight.js:5134 Request [/MyProject/apps/services/api/MyApp/iphone/heartbeat]
worklight.js:5134 Application details header: {"applicationDetails":{"platformVersion":"7.0.0.0","nativeVersion":"1161280635"}}WL.Logger.__log # worklight.js:5134
worklight.js:5134 response [/MyProject/apps/services/api/MyApp/iphone/heartbeat] success:
worklight.js:5134 Heartbeat sent successfully
worklight.js:5134 Piggybacking event transmission
worklight.js:5134 Flush called
worklight.js:5134 Request [/MyProject/apps/services/api/MyApp/iphone/heartbeat]
worklight.js:5134 Application details header: {"applicationDetails":{"platformVersion":"7.0.0.0","nativeVersion":"1161280635"}}WL.Logger.__log # worklight.js:5134
worklight.js:5134 response [/MyProject/apps/services/api/MyApp/iphone/heartbeat] success:
worklight.js:5134 Heartbeat sent successfully
worklight.js:5134 Piggybacking event transmission
worklight.js:5134 Flush called
worklight.js:5134 Request [/MyProject/apps/services/api/MyApp/iphone/heartbeat]
worklight.js:5134 Application details header: {"applicationDetails":{"platformVersion":"7.0.0.0","nativeVersion":"1161280635"}}WL.Logger.__log # worklight.js:5134
worklight.js:5134 response [/MyProject/apps/services/api/MyApp/iphone/heartbeat] success:
worklight.js:5134 Heartbeat sent successfully
worklight.js:5134 Piggybacking event transmission
worklight.js:5134 Flush called
worklight.js:5134 Request [/MyProject/apps/services/api/MyApp/iphone/heartbeat]
worklight.js:5134 Application details header: {"applicationDetails":{"platformVersion":"7.0.0.0","nativeVersion":"1161280635"}}WL.Logger.__log # worklight.js:5134
worklight.js:5134 response [/MyProject/apps/services/api/MyApp/iphone/heartbeat] success:
worklight.js:5134 Heartbeat sent successfully
worklight.js:5134 Piggybacking event transmission
worklight.js:5134 Flush called
worklight.js:5134 Request [/MyProject/apps/services/api/MyApp/iphone/heartbeat]
worklight.js:5134 Application details header: {"applicationDetails":{"platformVersion":"7.0.0.0","nativeVersion":"1161280635"}}WL.Logger.__log # worklight.js:5134
worklight.js:5134 response [/MyProject/apps/services/api/MyApp/iphone/heartbeat] success:
worklight.js:5134 Heartbeat sent successfully
worklight.js:5134 Piggybacking event transmission
worklight.js:5134 Flush called
worklight.js:5134 Request [/MyProject/apps/services/api/MyApp/iphone/heartbeat]
worklight.js:5134 Application details header: {"applicationDetails":{"platformVersion":"7.0.0.0","nativeVersion":"1161280635"}}WL.Logger.__log # worklight.js:5134PUBLIC_API.(anonymous function) # worklight.js:5520window.WLJSX.Ajax.WLRequest.WLJSX.Class.create.createRequestHeaders # worklight.js:3337window.WLJSX.Ajax.WLRequest.WLJSX.Class.create.sendRequest # worklight.js:3395window.WLJSX.Ajax.WLRequest.WLJSX.Class.create.initialize # worklight.js:3309klass # worklight.js:527sendHeartBeat # worklight.js:7276onTimerEvent # worklight.js:896(anonymous function) # worklight.js:959
worklight.js:5134 response [/MyProject/apps/services/api/MyApp/iphone/heartbeat] success:
worklight.js:5134 Heartbeat sent successfully
worklight.js:5134 Piggybacking event transmission
worklight.js:5134 Flush called
I notice there's a date number difference between the files written when I build the project using Eclipse and when I do it from the cli ... is there an easy way to check for and get updates to the CLI?
(Just to be clear, we don't see this problem when using Studio in Eclipse.)
This is perfectly expected.
From the preview URL it seems you are looking at the "Simple Preview" which actually only loads the web resources - and in this case Cordova is indeed not available, as Cordova is available only when previewing the actual app in either the Mobile Browser Simulator or in the specific environment's IDE (Xcode, Android Emulator, etc...).
If you will launch your app in the Mobile Browser Simulator - this tool provide some Cordova functionality by mimicking it.
If you will take an MBS-preview URL, for exmaple the following - you will not see any errors: http://10.0.0.3:10080/_MobileBrowserSimulator/index.html?webpage=/test/apps/services/preview/test/iphone/1.0/&platform=ios.iphone
However if you'll then "strip" out the MBS and preview the following - you will see the same errors: http://10.0.0.3:10080/test/apps/services/preview/test/iphone/1.0/default/index.html
http://10.0.0.3:10080/test/apps/services/preview/test/iphone/1.0/default/worklight/cordova.js
Failed to load resource: the server responded with a status of 404
(Not Found)_mbs_cordova_sim_load_js # cordova.js:19
2015-06-25 20:01:08.608 cordova.js:24 Uncaught ReferenceError: cordova
is not defined
As Idan explained, this is expected.
I was starting the previews with mfp preview --noshell. If I drop --noshell, it uses the MobileBrowserSimulator link and I don't get these errors.
Related
I've run a turn server(from Coturn) on a subnet machine 192.168.1.5, while its Internet IP is 183.xxx.xxx.xxx, and from https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ .
I can see the subnet ip is gathered.
The TURN startup command is:
turnserver -o -a -f -v --mobility -m 10 --max-bps=100000 --min-port=32355 --max-port=65535 --user=webrtc0:webrtc1234 -r demo
But when I open Chrome to access the WebRTC service, in console, I saw the error log:
But in FireFox, the error log is:
I'm wondering why it says WebRTC: ICE failed, add a STUN server and see about:webrtc for more details.
And if I visit 183.xxx.xxx.xxx:3478, The connection was reset appears :
Some points to notice:
In intranet environment, use 192.168.1.5 or 183.xxx.xxx.xxx to access the WebRTC service is OK!
2.In Extranet environment, which is Internet environment, use 183.xxx.xxx.xxx to access the WebRTC service failed!
The log's here:
1068: : session 128000000000000003: realm <demo> user <>: incoming packet BINDING processed, success
1068: : session 128000000000000003: realm <demo> user <>: incoming packet message processed, error 401: Unauthorized
1068: : IPv4. Local relay addr: 192.168.1.5:43040
1068: : session 128000000000000003: new, realm=<demo>, username=<webrtc0>, lifetime=600
1068: : session 128000000000000003: realm <demo> user <webrtc0>: incoming packet ALLOCATE processed, success
1068: : session 128000000000000003: refreshed, realm=<demo>, username=<webrtc0>, lifetime=0
1068: : session 128000000000000003: realm <demo> user <webrtc0>: incoming packet REFRESH processed, success
1069: : session 128000000000000003: usage: realm=<demo>, username=<webrtc0>, rp=4, rb=232, sp=4, sb=416
1069: : session 128000000000000003: peer usage: realm=<demo>, username=<webrtc0>, rp=0, rb=0, sp=0, sb=0
1069: : session 128000000000000003: closed (2nd stage), user <webrtc0> realm <demo> origin <>, local 192.168.1.5:3478, remote 58.101.35.211:48671, reason: allocation timeout
1069: : session 128000000000000003: delete: realm=<demo>, username=<webrtc0>
1073: : session 004000000000000003: refreshed, realm=<demo>, username=<webrtc0>, lifetime=600
1073: : session 004000000000000003: realm <demo> user <webrtc0>: incoming packet REFRESH processed, success
1073: : IPv4. tcp or tls connected to: 183.xxx.xxx.xxx:64128
1073: : session 001000000000000008: realm <demo> user <>: incoming packet message processed, error 401: Unauthorized
1073: : IPv4. Local relay addr: 192.168.1.5:48887
1073: : session 001000000000000008: new, realm=<demo>, username=<webrtc0>, lifetime=600
1073: : session 001000000000000008: realm <demo> user <webrtc0>: incoming packet ALLOCATE processed, success
1088: : session 008000000000000008: refreshed, realm=<demo>, username=<webrtc0>, lifetime=600
1088: : session 008000000000000008: realm <demo> user <webrtc0>: incoming packet REFRESH processed, success
1088: : IPv4. tcp or tls connected to: 183.xxx.xxx.xxx:64156
1088: : session 002000000000000008: realm <demo> user <>: incoming packet message processed, error 401: Unauthorized
1088: : IPv4. Local relay addr: 192.168.1.5:42791
1088: : session 002000000000000008: new, realm=<demo>, username=<webrtc0>, lifetime=600
1088: : session 002000000000000008: realm <demo> user <webrtc0>: incoming packet ALLOCATE processed, success
1089: : session 003000000000000001: realm <demo> user <webrtc0>: incoming packet message processed, error 438: Stale nonce
1089: : session 003000000000000001: refreshed, realm=<demo>, username=<webrtc0>, lifetime=600
1089: : session 003000000000000001: realm <demo> user <webrtc0>: incoming packet REFRESH processed, success
1104: : session 001000000000000003: refreshed, realm=<demo>, username=<webrtc0>, lifetime=600
1104: : session 001000000000000003: realm <demo> user <webrtc0>: incoming packet REFRESH processed, success
1104: : session 003000000000000002: realm <demo> user <webrtc0>: incoming packet message processed, error 438: Stale nonce
1104: : session 003000000000000002: refreshed, realm=<demo>, username=<webrtc0>, lifetime=600
1104: : session 003000000000000002: realm <demo> user <webrtc0>: incoming packet REFRESH processed, success
Can anyone give me a clue?
I have an ASP.NET Core application using a SignalR hub. When running via a console application (development mode), no keep-alive requests are sent by the server to the client. Consequently, the connection is re-established every 30 seconds or so.
However, when running the same application via Service Fabric, keep-alive requests are sent and everything works as expected.
Here are the server logs when running under the console app:
dbug: Microsoft.AspNetCore.Http.Connections.Internal.HttpConnectionManager[1]
New connection T2NKQg0jyrm7QAPz4p0ZWA created.
dbug: Microsoft.AspNetCore.Http.Connections.Internal.HttpConnectionDispatcher[4]
Establishing new connection.
dbug: Microsoft.AspNetCore.SignalR.HubConnectionHandler[5]
OnConnectedAsync started.
dbug: Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsTransport[1]
Socket opened using Sub-Protocol: '(null)'.
trce: Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsTransport[9]
Message received. Type: Text, size: 32, EndOfMessage: True.
dbug: Microsoft.AspNetCore.SignalR.Internal.DefaultHubProtocolResolver[2]
Found protocol implementation for requested protocol: json.
dbug: Microsoft.AspNetCore.SignalR.HubConnectionContext[1]
Completed connection handshake. Using HubProtocol 'json'.
trce: Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsTransport[11]
Sending payload: 3 bytes.
trce: Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsTransport[9]
Message received. Type: Text, size: 11, EndOfMessage: True.
trce: Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsTransport[9]
Message received. Type: Text, size: 11, EndOfMessage: True.
dbug: Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsTransport[4]
Waiting for the application to finish sending data.
dbug: Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsTransport[2]
Socket closed.
trce: Microsoft.AspNetCore.Http.Connections.Internal.HttpConnectionContext[1]
Disposing connection T2NKQg0jyrm7QAPz4p0ZWA.
trce: Microsoft.AspNetCore.Http.Connections.Internal.HttpConnectionContext[2]
Waiting for application to complete.
dbug: Microsoft.AspNetCore.SignalR.HubConnectionHandler[6]
OnConnectedAsync ending.
trce: Microsoft.AspNetCore.Http.Connections.Internal.HttpConnectionContext[3]
Application complete.
dbug: Microsoft.AspNetCore.Http.Connections.Internal.HttpConnectionManager[2]
Removing connection T2NKQg0jyrm7QAPz4p0ZWA from the list of connections.
dbug: Microsoft.AspNetCore.Http.Connections.Internal.HttpConnectionManager[1]
New connection JW_1AnoGvhvNJ6MdWGb5RA created.
dbug: Microsoft.AspNetCore.Http.Connections.Internal.HttpConnectionDispatcher[4]
Establishing new connection.
dbug: Microsoft.AspNetCore.SignalR.HubConnectionHandler[5]
OnConnectedAsync started.
dbug: Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsTransport[1]
Socket opened using Sub-Protocol: '(null)'.
trce: Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsTransport[9]
Message received. Type: Text, size: 32, EndOfMessage: True.
dbug: Microsoft.AspNetCore.SignalR.Internal.DefaultHubProtocolResolver[2]
Found protocol implementation for requested protocol: json.
dbug: Microsoft.AspNetCore.SignalR.HubConnectionContext[1]
Completed connection handshake. Using HubProtocol 'json'.
trce: Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsTransport[11]
Sending payload: 3 bytes.
trce: Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsTransport[9]
Message received. Type: Text, size: 11, EndOfMessage: True.
And the client logs:
Microsoft.AspNetCore.Http.Connections.Client.HttpConnection: Debug: Transport 'WebSockets' started.
Microsoft.AspNetCore.Http.Connections.Client.HttpConnection: Information: HttpConnection Started.
Microsoft.AspNetCore.SignalR.Client.HubConnection: Information: Using HubProtocol 'json v1'.
Microsoft.AspNetCore.SignalR.Client.HubConnection: Debug: Sending Hub Handshake.
Microsoft.AspNetCore.Http.Connections.Client.Internal.WebSocketsTransport: Debug: Received message from application. Payload size: 32.
Microsoft.AspNetCore.Http.Connections.Client.Internal.WebSocketsTransport: Debug: Message received. Type: Text, size: 3, EndOfMessage: True.
Microsoft.AspNetCore.SignalR.Client.HubConnection: Debug: Handshake with server complete.
Microsoft.AspNetCore.SignalR.Client.HubConnection: Debug: Receive loop starting.
Microsoft.AspNetCore.SignalR.Client.HubConnection: Debug: Sending PingMessage message.
Microsoft.AspNetCore.Http.Connections.Client.Internal.WebSocketsTransport: Debug: Received message from application. Payload size: 11.
Microsoft.AspNetCore.SignalR.Client.HubConnection: Debug: Sending PingMessage message completed.
Microsoft.AspNetCore.SignalR.Client.HubConnection: Information: HubConnection started.
Microsoft.AspNetCore.SignalR.Client.HubConnection: Trace: The HubConnection is attempting to transition from the Connecting state to the Connected state.
Microsoft.AspNetCore.SignalR.Client.HubConnection: Trace: Releasing Connection Lock in StartAsyncInner (/_/src/SignalR/clients/csharp/Client.Core/src/HubConnection.cs:280).
The thread 0x8184 has exited with code 0 (0x0).
Microsoft.AspNetCore.SignalR.Client.HubConnection: Trace: Acquired the Connection Lock in order to ping the server.
Microsoft.AspNetCore.SignalR.Client.HubConnection: Debug: Sending PingMessage message.
Microsoft.AspNetCore.SignalR.Client.HubConnection: Debug: Sending PingMessage message completed.
Microsoft.AspNetCore.SignalR.Client.HubConnection: Trace: Releasing Connection Lock in RunTimerActions (/_/src/SignalR/clients/csharp/Client.Core/src/HubConnection.cs:1881).
Microsoft.AspNetCore.Http.Connections.Client.Internal.WebSocketsTransport: Debug: Received message from application. Payload size: 11.
Microsoft.AspNetCore.SignalR.Client.HubConnection: Trace: Waiting on Connection Lock in HandleConnectionClose (/_/src/SignalR/clients/csharp/Client.Core/src/HubConnection.cs:1279).
Microsoft.AspNetCore.Http.Connections.Client.HttpConnection: Debug: Disposing HttpConnection.
Microsoft.AspNetCore.Http.Connections.Client.Internal.WebSocketsTransport: Information: Transport is stopping.
Microsoft.AspNetCore.Http.Connections.Client.Internal.WebSocketsTransport: Debug: Send loop stopped.
Microsoft.AspNetCore.Http.Connections.Client.Internal.WebSocketsTransport: Debug: Transport stopped.
Microsoft.AspNetCore.Http.Connections.Client.HttpConnection: Information: HttpConnection Disposed.
Microsoft.AspNetCore.SignalR.Client.HubConnection: Debug: Canceling all outstanding invocations.
Microsoft.AspNetCore.Http.Connections.Client.Internal.WebSocketsTransport: Debug: Receive loop canceled.
Microsoft.AspNetCore.Http.Connections.Client.Internal.WebSocketsTransport: Debug: Receive loop stopped.
Microsoft.AspNetCore.SignalR.Client.HubConnection: Trace: The HubConnection is attempting to transition from the Connected state to the Reconnecting state.
Microsoft.AspNetCore.SignalR.Client.HubConnection: Error: HubConnection reconnecting due to an error.
I won't include them here, but the logs when running under Service Fabric show that the server is correctly sending keep-alives to the client ("Sent a ping message to the client").
It might seem obvious that there is some difference in configuration between my console and Service Fabric hosts, but I've gone through it carefully and cannot see anything that would explain this. In fact, the SignalR integration differed only in that the development host configured detailed errors to be enabled, but even if I remove that the behavior remains the same.
Short of running my own build of ASP.NET Core (something I'm perhaps lazily attempting to avoid only because it was looking far from trivial to build), is there anything I might be missing that would explain this situation?
I have been using Zabbix for a while now. I tried to configure the telegram media type so as to receive notifications. Due to some error, I'm not receiving any notification. While testing the media type this is the error that appears on the log. Please help me resolve this.
Media type test log
00:00:00.000 [Debug] [Telegram Webhook] URL: https://api.telegram.org/bot/sendMessage
00:00:00.000 [Debug] [Telegram Webhook] params: {"chat_id":"-xyxyxyxyxy","text":"{ALERT.SUBJECT}\n{ALERT.MESSAGE}","disable_web_page_preview":true,"disable_notification":false}
00:00:05.183 [Debug] [Telegram Webhook] HTTP code: 200
00:00:05.184 [Debug] [Telegram Webhook] notification failed: TypeError: cannot read property 'ok' of null
We are trying to setup an oidc provider for authZ and authN with istio in our k8s cluster. We followed this example here: Bookinfo with Authservice Example for the integration.
Below are the details on the setup:
OIDC provider: Keycloak
Grant type: authorization_code
Istio version: 1.5
Authentication flow:
On first request, since there is no authentication, authservice successfully redirects to Keycloak, where we're able to login successfully.
Keycloak then redirects the request to the application on the redirect_uri. The authorization code is present in this uri now.
The redirect_uri is intercepted by the authservice again and it detects the url to be the filter url for oidc as defined in the configmap
Now it tries to call keycloak for exchanging the authorization code for the access token.
This is the step where authservice fails and gives the error IdP connection error. The log for the request is as follows:
Check: processing request ://microservice.url.com/appservice/oauth/callback?state=LeCNEqfwA6EUFGNGLt7JALx8jCWkPxjn7qCELbqkKrk&session_state=18f0e3b0-bee2-44a5-b049-6e349dbeda49&code=ddea1ea6-5616-416d-8291-c00bce6f2e9b.18f0e3b0-bee2-44a5-b049-6e349dbeda49.af7e7c31-fd4b-4a66-9856-25d1ac305d3f with filter chain idp_filter_chain
20/03/2020 17:27:48 [2020-03-20 11:57:48.546] [console] [trace] New
20/03/2020 17:27:48 [2020-03-20 11:57:48.547] [console] [trace] OidcFilter
20/03/2020 17:27:48 [2020-03-20 11:57:48.548] [console] [trace] Process
20/03/2020 17:27:48 [2020-03-20 11:57:48.548] [console] [debug] Call from #10.42.5.53 to #10.42.5.58
20/03/2020 17:27:48 [2020-03-20 11:57:48.549] [console] [trace] MatchesCallbackRequest: checking handler for ://microservice.url.com/appservice/oauth/callback?state=LeCNEqfwA6EUFGNGLt7JALx8jCWkPxjn7qCELbqkKrk&session_state=18f0e3b0-bee2-44a5-b049-6e349dbeda49&code=ddea1ea6-5616-416d-8291-c00bce6f2e9b.18f0e3b0-bee2-44a5-b049-6e349dbeda49.af7e7c31-fd4b-4a66-9856-25d1ac305d3f
20/03/2020 17:27:48 [2020-03-20 11:57:48.549] [console] [trace] RetrieveToken
20/03/2020 17:27:48 [2020-03-20 11:57:48.550] [console] [trace] Post
20/03/2020 17:27:48 [2020-03-20 11:57:48.618] [console] [info] Post: HTTP error encountered: stream truncated
20/03/2020 17:27:48 [2020-03-20 11:57:48.618] [console] [info] RetrieveToken: HTTP error encountered: IdP connection error
20/03/2020 17:27:48 [2020-03-20 11:57:48.618] [console] [trace] Request processing complete
20/03/2020 17:27:48 [2020-03-20 11:57:48.619] [console] [trace] Processing completion and deleting state
On further checking the code, I found this error is triggered from here: Authservice oidc filter - Github
To rule out the issues with the configuration, I used OpenID Debugger to manually generate an authorization code and then called the api to exchange it for an api token. I was able to successfully retrieve it, there was no issue with that. But somehow it is failing with authservice.
Could there be something wrong on my end? Has anyone experienced this issue before? Any help appreciated. Let me know if any more details are needed.
This issue has been now fixed by the authservice team. The issue here was, as stated by Ryan from authservice:
The log indicates that the request was successful right up until the end, when the Authservice tried to gracefully shutdown the TLS connection, and the server on the other side did not participate fully in the graceful shutdown.
The fix here was to ignore the truncation errors. The fix has now been merged to master and will be available in the next release. You can build the docker image yourself for a quick fix. More details about the issue and compilation instructions can be found here on this github issue
Here's a interesting problem I started facing since migrating from Heroku to Google Container Engine:
Since moving to GCE, after a few hours after server start/restart/deploy, out of nowhere, my Elixir application can't deliver push notifications to APNS any longer. I'm using the apns4ex library. Here is roughly what I found out so far:
Internally on init, the library opens a :ssl (erlang) socket to APNS and keeps recycling that inside a GenServer process
def connect_socket(host, port, opts, timeout_seconds) do
address = "#{host}:#{port}"
case :ssl.connect(host, port, opts, timeout_seconds * 1000) do
{:ok, socket} ->
APNS.Logger.debug("successfully connected to #{address}")
{:ok, socket}
{:error, reason} ->
APNS.Logger.error("failed to connect to push socket #{address}, reason given: #{inspect(reason)}")
{:error, {:connection_failed, address}}
end
end
Now, from hour x, after attempting to send a message, the library starts receiving the :ssl_closed message/callback to indicate that the SSL connection got closed
def handle_info({:ssl_closed, socket}, %{socket_apple: socket} = state) do
APNS.Logger.debug("ssl socket closed, returning :connect")
{:connect, {:error, "ssl_closed"}, %{state | socket_apple: nil}}
end
How it handles this is that it just let's the connection close and returns :connect, which will then re-connect to APNS (here)
Once push notifications stop working, the debug log always reports the following pattern on every message.
Attempt to send the message
Report "success sending" (nothing is being delivered to the phones. This message is caused by :ssl.send reporting :ok)
Then receive a ssl socket close message
Reconnect to gateway.push.apple.com (:ssl.connect returns :ok)
Repeat
send_package code:
def send_package(socket, packet) do
result = :ssl.send(socket, [packet])
case result do
:ok ->
APNS.Logger.debug("success sending ssl package")
{:error, reason} ->
APNS.Logger.warn("error #{reason} sending ssl package")
end
result
end
In contrast, on successful sending it stops at point 2.
Here is some raw log output from my app when sending a push (notice the last 9 lines showing the pattern I described)
01:41:14.820 request_id=fecds3h3s1so2825c44qfestvvvpv707 [debug] [APNS] #PID<0.20135.97> 23303051:1ad798 sending in poolboy transaction :myapp
01:41:14.821 request_id=fecds3h3s1so2825c44qfestvvvpv707 [debug] [APNS] #PID<0.20135.97> 23303051:1ad798 sending message
01:41:14.821 request_id=fecds3h3s1so2825c44qfestvvvpv707 [debug] [APNS] #PID<0.20135.97> 62064556:b12e98 sending in poolboy transaction :myapp
01:41:14.821 [debug] [APNS] #PID<0.349.0> 23303051:1ad798 handling cast :send
01:41:14.821 [debug] [APNS] #PID<0.349.0> 23303051:1ad798 message's payload looks good
01:41:14.821 request_id=fecds3h3s1so2825c44qfestvvvpv707 [debug] [APNS] #PID<0.20135.97> 62064556:b12e98 sending message
01:41:14.821 request_id=fecds3h3s1so2825c44qfestvvvpv707 [debug] [APNS] #PID<0.20135.97> 19048099:b3ed8e sending in poolboy transaction :myapp
01:41:14.822 [debug] [APNS] #PID<0.349.0> success sending ssl package
01:41:14.822 [debug] [APNS] #PID<0.349.0> 23303051:1ad798 success sending
01:41:14.822 [debug] [APNS] #PID<0.349.0> 23303051:1ad798 handle call :send received :ok
01:41:14.822 [debug] [APNS] #PID<0.348.0> 62064556:b12e98 handling cast :send
01:41:14.822 [debug] [APNS] #PID<0.348.0> 62064556:b12e98 message's payload looks good
01:41:14.823 request_id=fecds3h3s1so2825c44qfestvvvpv707 [debug] [APNS] #PID<0.20135.97> 19048099:b3ed8e sending message
01:41:14.823 request_id=fecds3h3s1so2825c44qfestvvvpv707 [info] Sent 200 in 22ms
01:41:14.823 [debug] [APNS] #PID<0.348.0> success sending ssl package
01:41:14.823 [debug] [APNS] #PID<0.348.0> 62064556:b12e98 success sending
01:41:14.823 [debug] [APNS] #PID<0.348.0> 62064556:b12e98 handle call :send received :ok
01:41:14.823 [debug] [APNS] #PID<0.347.0> 19048099:b3ed8e handling cast :send
01:41:14.824 [debug] [APNS] #PID<0.347.0> 19048099:b3ed8e message's payload looks good
01:41:14.824 [debug] [APNS] #PID<0.347.0> success sending ssl package
01:41:14.824 [debug] [APNS] #PID<0.347.0> 19048099:b3ed8e success sending
01:41:14.824 [debug] [APNS] #PID<0.347.0> 19048099:b3ed8e handle call :send received :ok
01:41:15.027 [debug] [APNS] #PID<0.348.0> ssl socket closed, returning :connect
01:41:15.029 [debug] [APNS] #PID<0.347.0> ssl socket closed, returning :connect
01:41:15.043 [debug] [APNS] #PID<0.349.0> ssl socket closed, returning :connect
01:41:15.207 [debug] [APNS] #PID<0.348.0> successfully connected to gateway.push.apple.com:2195
01:41:15.207 [debug] [APNS] #PID<0.348.0> successfully connected to socket
01:41:15.209 [debug] [APNS] #PID<0.347.0> successfully connected to gateway.push.apple.com:2195
01:41:15.209 [debug] [APNS] #PID<0.347.0> successfully connected to socket
01:41:15.214 [debug] [APNS] #PID<0.349.0> successfully connected to gateway.push.apple.com:2195
01:41:15.214 [debug] [APNS] #PID<0.349.0> successfully connected to socket
One theory is that GCE is closing the connection for being idle but this doesn't explain why another message after reconnect immediately results in the same pattern. Also why does the socket only close after sending with :ssl.send?
I have same issue with apns4erl, when socket close after trying send message, but problem was on my side, do not remember, it was either in the wrong certificate file or malformed messages