I managed to get Microsoft Example 52 to work last friday. But after the weekend (from 13. January on) I get the following error:
Error refreshing OpenId configuration:
System.InvalidOperationException: IDX20803: Unable to obtain configuration from: 'https://login.botframework.com/v1/.well-known/openidconfiguration'.
at Microsoft.IdentityModel.Protocols.ConfigurationManager1.GetConfigurationAsync(CancellationToken cancel) at Microsoft.IdentityModel.Protocols.ConfigurationManager1.GetConfigurationAsync()
at Microsoft.Bot.Connector.Authentication.JwtTokenExtractor.ValidateTokenAsync(String jwtToken, String channelId, String[] requiredEndorsements)
...
Error refreshing OpenId configuration: System.InvalidOperationException: IDX20803: Unable to obtain configuration from: 'https://login.botframework.com/v1/.well-known/openidconfiguration'.
---> System.IO.IOException: IDX20804: Unable to retrieve document from: 'https://login.botframework.com/v1/.well-known/openidconfiguration'.
---> System.Net.Http.HttpRequestException: connection attempt failed because the remote peer did not respond properly after a certain period of time, or the established connection was faulty because the connected host did not respond.
---> System.Net.Sockets.SocketException (10060): A connection attempt failed because the remote terminal did not respond properly after a certain period of time, or the established connection was faulty because the connected host did not respond
-> By the way I translated the last two exceptions with deepl as they where in German
I already checked the forum and also documentation but with no luck.
Today I tried the example from scratch with different bot, different bot channels registration, and new copied example project but I still get the same error.
I still have to mention: The only difference to documentation is, that I registered bot and channel registration with another my azure user. And in teams I use an other account with office 365 business basic license. But last week it has worked - so maybe that's no problem at all!?!
Does anyone has an idea what to try next?
As per the comments above, this sounded like an issue with how the bot was hosted, and jwt validation code not being able to call out to the internet (e.g. a security or proxy setting). It needs to be able to physically call out to login.botframework.com/v1/.well-known/openidconfiguration . That might be fine on a local dev workstation, but blocked on an internal company server, for instance. In the end it was something in this line - proxy settings blocking the outgoing call, so listing it here as an answer for future visitors.
Related
I'm working to create a video calling web app using WebRTC.
The communication is working fine on same network. But when communicating in different network I'm getting ICE failed error.
Error: ICE failed, see about:webrtc for more details
In about:webrtc I' able to get local and remote SDP's, but ICE State is failed. http://imgur.com/a/nPPDr
Here is the code of my main.js file
Here is the my log file from about:webrtc
P.S: Before posting the question I've checked several posts in SO and in other sites but no one did the trick.
Looking at the log file you provided it looks like you provided a TURN server, but the communication with that TURN server simply times out. So either something like a local firewall is blocking the communication with your TURN server or your TURN server is not working.
In case your local firewall blocks UDP traffic it might help to configure and use TURN TCP additionally to get through the firewall.
your about:webrtc does not show any relay candidates gathered from a TURN server. At the risk of sounding like a broken record: you need a TURN server for the majority of connections between different networks.
My app was rejected today due to 'not supporting IPv6'. I've attached screenshots of the error they received which comes from a Parse.com API call.
I could really use some help on this, as I have no clue where to start with this.
Does anyone know if Parse.com supports IPv6? Or do I need to add something to my code? Do I need to migrate to Parse Server?
Please help =\
---- EDIT ---- 9/22/16
OK so, after my first rejection due to "IPv6" issues, I re-submitted and the app was approved. I'd still like to understand if Parse.com and Parse Server are officially IPv6 compatible but as for now, I'm just happy my app was approved. I'll keep this thread open and will edit it when I find the answer.
I have a parse server hosted on Heroku which doesn't support IPv6 yet (see here). But your server is not the reason why the app is rejected. It is your app which should support IPv6.
A possible solution is to download the latest Parse framework from https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/releases/tag/1.14.2 and replace the old ones. I think it should work.
Below is my comparison with the logs in the console for my app with the two different versions of Parse framework.
I have used Parse.framework and Bolts.framework from Feb 2016 in my Apple TV app and also just got rejected also for not supporting IPv6. I checked the log and found that
nw_resolver_start_crazy_eyeballs_timer Received IPv4 result first, performing crazy eyeballs: waiting 50ms on IPv6 for myapp.herokuapp.com:0.
__nw_resolver_start_crazy_eyeballs_timer_block_invoke Crazy eyeballs timer fired: did not receive IPv6 in time, reporting only IPv4 result for myapp.herokuapp.com:0
nw_resolver_cancel_crazy_eyeballs_timer Cancelling crazy eyeballs timer for myapp.herokuapp.com".
It seems the performance issue comes from the 50ms when the app loads.
I use the latest Parse framework and no "crazy_eyeballs_timer" shows up. The log seems more promising because I can see a IPv6 address in the log now.
nw_resolver_create_dns_service_on_queue Starting host resolution myapp.herokuapp.com:0, flags 0x4000d000
nw_resolver_host_resolve_callback flags=0x3 ifindex=0 error=NoSuchRecord(-65554) hostname=myapp.herokuapp.com. addr=0.0.0.0:0 ttl=60
nw_resolver_host_resolve_callback flags=0x2 ifindex=0 error=NoError(0) hostname=us-east-1-a.route.herokuapp.com. addr=88:ffff::bbbb:afb9.0 ttl=74
Here I changed the addr of my server in the log for security reason.
I will send a new update of my app to review and I believe that it should work. I will leave a comment when it gets accepted :)
I have been struggling with what I believe to be a networking issue and haven't made much progress. I wanted to see if someone had some ideas to a solution or possible steps that could provide me more information to arrive at a solution.
Environment
I have a mobile web application (angular.js) that is running on a html 5 browser (proprietary browser) on a barcode scanning gun (intermec ck71) connecting to a spring boot backend (non clustered single instance dev box). I wrote the mobile web app, but have assumed ownership of the spring boot back end (first time working with springboot). I am in a corporate office where I do not own the networks so I don't have a complete understanding of how things are laid out.
Problem
I cannot get a mobile web app to connect to our dev box on the office wireless with https
Steps already taken
We recently switched our team dev box to https now that development is finished. Before https the mobile application loaded properly but now just shows a spinning wheel on the mobile browser and then times out after about a minute.
The first step I did was to load the server running https locally and checked to see if I could get the scan gun to connect (which it did).
I then tried my desktop computer loading the mobile web app from the dev box (which also worked).
So it seems like the problem is isolated to the mobile gun on the wireless network at the office with https. I had the networking team make sure port 443 and port 8443 were open (which they saw were blocked and opened for me).
I retried connecting and still no luck. I ran a tcpdump on the server and see the following logs on the calls that fail
From this log it looks like the server (172.18.222.121) is closing the connection by sending packet 12 (FIN, ACK)
I added some logging to the tomcat instance of the server and see the following
[pid 22505] accept(41, {sa_family=AF_INET, sin_port=htons(1037), sin_addr=inet_addr("172.31.12.157")}, [16]) = 46
[pid 22505] setsockopt(46, SOL_SOCKET, SO_LINGER, {onoff=0, linger=0}, 8) = 0
[pid 22505] setsockopt(46, SOL_TCP, TCP_NODELAY, [1], 4) = 0
but I still dont see anything about actively telling the conncetion to close. My next thought was that the box might have ip ranges whitelisted/blacklisted but according the the team that maintains the server there are no ip rules, firewalls, or anything that would interfere with network traffic on the box.
So I took this to the network team to show that traffic and they informed me that it is not a networking problem because the initial traffic is getting through and that the real problem is the FIN packet. I took that information to the server team who informed me that they had nothing on the box that would cause a FIN packet to be sent and that it was most probably a networking issue. I decided that it very well could be a server issue since that is what I have access to and everyone else believes there portion is functioning properly. I decided to create a new SSL cert as I am getting the untrusted message on the desktop browser when I connect. I created this new cert and then added it to the trusted root on the mobile scanner gun. I tried to connect again on the gun to no effect.
Next I reached out to the mobile gun vendor to see if there was any information available to me on the gun to troubleshoot it. After some troubleshooting with them they said they cannot reproduce on their side, and that because it works on my side except for connecting on that one network that it is probably a networking issue.
I went back to the server and added logging on the tomcat valve to see if I could see if I could get any additional information. When I look at the logs that the valve produces I get entries for any successful connection, but when I am unable to connect nothing shows up. My connector looks like this just for completeness.
Connector code:
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreType="PKCS12"
keystoreFile="/home/devadmin/.ssh/keystore.p12"
keystorePass="password" />
And the valve:
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="localhost_access_log." suffix=".txt"
pattern="%a %H %p %U %h %l %u %t "%r" %s %b %{xxx}i" />
Conclusion
So basically I can get the application to load everywhere except this one network which leads me to believe that it is networking related. Yet the network team says that it can't be networking related because the initial packets are being transmitted and that the problem is with the FIN packet being sent by the server. I have exhausted what I know about the environments... I am a mobile developer after all:) I still feel it is networking related, but don't have anything to show why the FIN packet is being sent. Any ideas on things to check or what could be causing the problem?
If you can connect with your browser or with curl (for instance) then I suspect the issue is in the client. You said that you had to ignore the certificate violations in the browser so that's a smell, and then you said you "create a new SSL cert". Since it isn't really possible for mortals to create a trusted certificate, that means you installed a self signed or otherwise incomplete certificate, and I would hazard a guess that the client will not allow access over a connection with an untrusted cert (for good reasons)?
This turned out to be related to a redhat/java bug. When the scanner gun reached out to this instance of the server which had the right combinations of versions to cause a bug the server was throwing a SSL exception caused by the library that had the problem. I didn't see these exceptions because of the way the logging was configured.
Here is a link to the bug for people who might be reading this after me.
https://bugzilla.redhat.com/show_bug.cgi?id=1022017
We are attempting to connect to a WebDAV server using net use over SSL. On some servers we're seeing an issue in which this connection only succeeds if we specify port 443 in the URL.
Does Map
net use * "https://example.com:443/folder"
net use * "\\example.com#SSL#443\folder"
and, bizarrely, so does this:
net use * "\\example.com#SSLasdf\folder"
Does Not Map
net use * "https://example.com/folder"
net use * "\\example.com#SSL\folder"
In the non-working cases we consistently receive the following error:
System error 67 has occured.
The network name cannot be found.
We have noticed some things that might be useful information:
We have a test server that's configured the same way as the prod server and it works as expected.
In the non-working cases, no incoming requests are ever seen at the prod server from the failing host.
All clients are based on the same image.
The problem does not manifest uniformly on all clients -- some work, some don't.
There is an existing, valid entry for example.com in the client DNS cache.
Flushing the client DNS cache of the affected servers does not resolve the problem.
Once the problem appears, it seems to stick. That is, if I execute one of the working mappings, delete it, and then immediately execute one of the non-working mappings, the problem persists.
We are utterly stumped. Any theories?
You are seeing different behaviors because you are connecting using different names. Once a name has been attempted and failed, the WebClient (this is the service that enables WebDAV) will cache the response for a period. To clear the cache, locate the WebClient service in the Services console and restart it. Or from an administrative command prompt execute the following command:
net.exe stop webclient && net.exe start webclient
We ultimately determined that we were mis-interpreting the System Error 67 that net use was returning. We discovered two interesting things:
In the event that the WebDAV returns a 404 or a 50x on the initial, root folder PROPFIND, net use will (rightly) interpret this as the root folder being unavailable. The fact that it says the network name could not be found let us to believe that the problem was with the name resolution, but it was really just saying, 'hey, I couldn't find anything at this path.'
If 'net use' fails due to a 404/50x, it appears that for a brief period of time it will automatically fail any additional mappings for that same host without issuing a request. For example, if net use http://me.com/foo returns a 404, then net use http://me.com/bar will instantly fail if made in rapid succession to that first call, and no request record will be seen in the WebDAV server logs.
My best guess is that appending the #443 port didn't make any real difference. What it perhaps did do was to trick net use into thinking it was talking to a different host, at least for the purposes of its 'auto-fail' feature. But that's just a guess.
I'm developing an App that works with Apple push notifications but I have some problems testing.
I have tested the app in the sandbox and it all works fine: it can send and receive push notifications, but for one single device (I think that is the correct behavior for an sandbox release).
But when I have create an ad hoc version with his production provisioning I have the same behavior: only one device works fine, it sends and receives the push, but the others devices do not receive any push. All devices can send a push but only the the first one can receive.
After installing 'PersistentConnectionLogging.mobileconfig' on devices that can't receive a push, I can read on the console:
Sep 7 13:17:51 unknown apsd[49] <Warning>: <APSCourier: 0x25a0a0>: Received message for enabled topic 'myapp.name' with payload '(null)'
Sep 7 13:17:51 unknown apsd[49] <Warning>: <APSCourier: 0x25a0a0>: Failed to parse JSON message payload for topic 'myapp.name': The operation couldn’-t -b-e -c-o-m-p-l-e-t-e-d-. -(-C-o-c-o-a -e-r-r-o-r -3-8-4-0-.-)
I can't resolve the issue, I have regenerated the provisioning profile many times and all work fine on server sides connections, the Apple feedback is OK.
I have checked my stored devices token and sandbox and production are different, any suggestions?
Amalgamation of comments posted as an answer, on request: (these helped to break the problem down and identify where the error was occuring)
How/where are you storing your device tokens? How are you generating the message to be pushed?
Your code that connects to the push servers and creates the payload... how is it sending to >1 devices?
I don't know the easyApns code, but either your other device tokens are invalid or the code is not looping correctly to push the message to the other devices. Also, have a browse through Google for the cocoa error 3840 and see if anything helps you to better understand the issue. Else pick some different push code, have a look at [link below] as a starting point.
http://www.raywenderlich.com/3443/apple-push-notification-services-tutorial-part-12