I am trying sample code of Microsoft Translator in Windows Store App from this link
The sample code is given here
When I run the app, I get an exception "The remote server returned an unexpected response :(417) Expectation Failed"
This exception occurs on the following line:
germanTranslationTextBlock.Text = await webService.TranslateAsync("Bearer " + accessToken.access_token, sourceTextBox.Text, "en", "de", "text/plain", "");
P.S. I am behind a proxy.
Some googling shows that System.Net.ServicePointManager.Expect100Continue = false; is the solution but I do not know how to do that for Windows Store App.
Could not solve this error, but got a better and infact best source code [which works successfully] for doing text to speech and translate too here.
Could have saved a lifetime if I would have found it earlier, but it's really hard to find any good resources for windows app development.
Related
Our application is using CefSharp version 73.1.130. The issue only occurs on a small number of internal workstations within our organization. Worth noting, we are also seeing the same error with CefSharp version 92. Another strange thing is that it the issue is consistent, but only when the web apps are launched through certain navigations. Other navigations work consistently for these users.
We use RegisterJsObject to register a javascript object with browser. If I understand correctly, asynchronous binding is preferred moving forward.
The issue presents as strange/unexpected behavior in the hosted web application due to failure to retrieve context from the host WinForms application. The behavior would suggest a failure to register/bind the js object with the RegisterJsObject method. However, that method is not throwing an exception.
Enabled Cef logging showed the following error:
ERROR:JavascriptRootObjectWrapper.cpp(34)] IBrowserProcess is null, unable to bind object
After looking into the code, it appears the location that the value pointed to by "IBrowserProcess" is set is in WcfEnabledSubProcess::OnBrowserCreated (https://github.com/cefsharp/CefSharp/blob/cefsharp/73/CefSharp.BrowserSubprocess.Core/WcfEnabledSubProcess.cpp). I was able to build CefSharp and add additional logging to that method.
On my workstation (I'm not affected by the issue), I get through OnBrowserCreated with no exceptions. However, on my coworkers workstation I see the following line is failing:
...
channelFactory->Open();
auto browserProcess = channelFactory->CreateChannel();
auto clientChannel = ((IClientChannel^)browserProcess);
try
{
clientChannel->Open(); <-- FAILS
browser->ChannelFactory = channelFactory;
browser->BrowserProcess = browserProcess;
}
catch (Exception^)
{
}
}
With the error:
There was an error reading from the pipe: The pipe has been ended. (109, 0x6d)
Has anyone seen this issue before? I'm not sure how much this will help, but does anyone know if it's possible to enable WCF tracing with the CefSharp.BrowserSubProcess.exe. I have been trying this, but no luck so far.
I have the following code...
async function GetFirstAssessment() {
try {
const response = await axios.get('http://192.168.254.10/App/GetFirstAssessment/');
return response.data;
} catch (error) {
alert('error: ' + error);
console.error(error);
}
};
It's been working fine for some time, but suddenly it no longer works and eventually times out. Or I don't even know if it "times out" since I believe the default timeout for axios is 0 but eventually it does error with the message "Error: Network Error". I've also added a picture of the stack trace but I don't think it's helpful.
I can put the url in a browser and it returns the json I'm expecting, so the problem is definitely not on the server side. I am testing from an android device connected via usb and developing with cli (not expo).
If there is any other information I can provide please let me know... not sure what to do next because this really makes no sense. I would wonder if it was a security issue except that it was working perfectly earlier. Also I have updated some other code that calls this, but even after reverting I still have the same problem... and seeing as how it is making it to the catch, I don't see how any other code could be affecting this.
I did just install the standalone react native debugger. I believe it has worked since I installed it, though I'm not 100% certain on that. Still doesn't work after closing it.
I set a break point in the server code on the first line of the api method, but it doesn't get hit. Not sure how to troubleshoot further up the chain though. I also just thought to check fiddler and it doesn't show any request coming in, though I honestly don't know if it should normally or not.
Our server OAuth validation via Google has started throwing NullPointerException within GoogleTokenResponse.parseIdToken():
java.lang.NullPointerException:
at com.google.api.client.json.webtoken.JsonWebSignature$Parser.parse(JsonWebSignature.java:462)
at com.google.api.client.googleapis.auth.oauth2.GoogleIdToken.parse(GoogleIdToken.java:57)
at com.google.api.client.googleapis.auth.oauth2.GoogleTokenResponse.parseIdToken(GoogleTokenResponse.java:106)
This is new behavior that started today. There was no change to our server code (it has worked for months). The problem occurs only with credentials from one Android device -- I have another that works fine. Refreshing the client's server access token does not solve the problem.
The GoogleTokenResponse is being created by GoogleAuthorizationCodeTokenRequest(), that call succeeds and when I log the GoogleTokenResponse it looks valid:
{"access_token":"ya29.mwJvM...","expires_in":3600,"token_type":"Bearer"}
UPDATE: tested some more and found tokenResponse.getIdToken() is returning null, so I assume that's what's causing the NPE when I call parseIdToken().
What would cause getIdToken() to return null when GoogleAuthorizationCodeTokenRequest() apparently succeeded and there is an access token?
Final resolution: this issue appears to be triggered intermittently by the Google Play Services update in early 2016 to anonymize PlayerID. We were able to fix our problems by changing our server validation of the access token to a newer method instead of relying on the older getIdToken()/parseIdToken() methods. See the last UPDATE below for details
After two days the Android device with this failure mysteriously started to work again. So the cause may be a transient error in the client's Google Play Services state which self-corrected. The fix occurred after a device reboot.
However I'm not certain that was the cause. There are also Play Services changes rolling out to enable authentication without exposing the G+ user ID -- another explanation is the server was not being given scope to retrieve the ID. (If that was the cause, then again the fix must have been deployed by Google as we have not changed anything)
We'll continue to monitor it, if anyone else runs into this add a comment please.
4/19/16 This problem has occurred on a different device. I am wondering if this is related to the Google Play auth changes described here http://android-developers.blogspot.com/2016/01/play-games-permissions-are-changing-in.html?m=1
That explanation is a bit sparse but it does say "The user_id returned by token info may no longer be present with the new model. And even if it is present, the value won’t be the same as the new player ID"
In this case the problem occurred after
Device had previously authorized with Google Play Services in the old G+-style
App data was cleared so re-auth was necessary
During re-auth GPS prompted for the new GPS-only player ID (not real name), which makes me wonder if it switched that device to the new non-G+ ID
Then server calls to tokenResponse.getIdToken() returned null
I'm not yet sure what's happening but researching two areas of concern:
1) Although the Google docs referenced above say "existing players ... will continue to get their Google+ ID" I'm wondering if this is managed per-client. That would be a big problem because we use that ID to store cloud state for a user across devices, so if a user who originally set up their account before the new player ID then installed the app on a second device, they could sign in with gplay but the two accounts would not match
2) If this is the cause, then either our server code fails to work with the new non-G+ player ID, or there is a google back-end bug when a device transitions between the two. This is still confusing though because our prior problem did self-correct after a couple of days, which implies the server code is fine -- but I'm sure hoping the alternate explanation of a bug with google back-end auth is wrong!
--- UPDATE
I think the issue is related to the new GPS anonymized PlayerID changes. It has been hard to debug because it appears that Google's legacy server auth flow, which requires a non-null GoogleTokenResponse.getIdToken(), fails for a newly created GPS PlayerID, but after 12-24 h the problem seems to self-correct and the legacy Google auth calls begin to succeed including returning a non-null getIdToken().
However I tried implementing the new PlayerID flow in the Step 7 of the google info page above which converts the access token (generated from a server auth code) to a Player ID via www.googleapis.com/games/v1/applications//verify/
This code successfully retrieves a Player ID from the accessToken even when getToken() returns null:
// URL: www.googleapis.com/games/v1/applications/<app_id>/verify/
URL url = new URL("https://www.googleapis.com/games/v1/applications/" + GPlayServicesAppId + "/verify/");
HttpURLConnection httpConnection = (HttpURLConnection) url.openConnection();
httpConnection.setRequestProperty("Authorization", "OAuth " + accessToken);
httpConnection.setRequestMethod("GET");
int responseCode = httpConnection.getResponseCode();
if (responseCode != HttpURLConnection.HTTP_OK) {
...
}
BufferedReader reader = new BufferedReader(new InputStreamReader(httpConnection.getInputStream()));
String responseJson = (read contents of reader)
// Example response: { "kind": "games#applicationVerifyResponse", "player_id": "11520..."}
I ran some tests, far as I can tell the new method works in all cases where the older G+ getToken() method works as well as fixing the cases where it doesn't, so I believe we can just switch to the new method in the code snippet above and hopefully that will be reliable.
I am trying to use PushSharp to send notification to my mobile devices using Google Gcm.
I downloaded the sample application from github depending upon that I have written my sample code. below is my sample code.
var googleKey = CustomConfigurationManager.GetValueFromSection("appSettings", "GoogleServerAccessKey");
AndroidPushBroker.RegisterGcmService(new PushSharp.Android.GcmPushChannelSettings(googleKey));
GcmNotification androidNotifcation = new GcmNotification().WithDryRun()
.WithJson("{\"alert\":\"Hello World!\",\"badge\":7,\"sound\":\"sound.caf\"}");
AndroidPushBroker.QueueNotification(androidNotifcation);
The issue is though I have used WithDryRun() and upon hooking up request it shows json data with "dry_run": true, but still I receive Notification failed error with reason : "Notification send timed out".
Anybody can tell me what am I missing ?
try to run it without WithDryRun(), and see do you get anything in events like NotificationSent, ChannelException, NotificationFailed or ServiceException.
I am using fusion table APIs to insert/update data in my table. Last week I migrated my API to new version v1 as referred in this sample. But now, when I run the code, the following error displayed.
400 Bad Request
{
"error" : "unauthorized_client"
}
com.google.api.client.auth.oauth2.TokenResponseException: 400 Bad Request
{
"error" : "unauthorized_client"
}
at com.google.api.client.auth.oauth2.TokenResponseException.from(TokenResponseException.java:105)
at com.google.api.client.auth.oauth2.TokenRequest.executeUnparsed(TokenRequest.java:303)
at com.google.api.client.auth.oauth2.TokenRequest.execute(TokenRequest.java:323)
at com.google.api.client.auth.oauth2.Credential.executeRefreshToken(Credential.java:607)
at com.google.api.client.auth.oauth2.Credential.refreshToken(Credential.java:526)
at com.google.api.client.auth.oauth2.Credential.intercept(Credential.java:287)
at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:836)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:412)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:345)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.execute(AbstractGoogleClientRequest.java:463)
at com.prasanna.survey.pushapis.FusionPush.insertData(FusionPush.java:198)
at com.prasanna.survey.pushapis.FusionPush.main(FusionPush.java:96)
Java Result: 1
How to debug this error?
This error typically occurs if you change the client_id of an application.
The reason is, you already have an access token for the Fusion API that's based on the old client_id. When you request a refresh token (as you can see is happening in the stack trace) with the new client_id, you get that very unhelpful error message.
The easiest way to handle this is to clear the existing credential from the system so it has to receive a clean access token. You can do this programatically with the Google API Java Client, or you can just remove the file from your system. On my Ubuntu machine, it is located at ~/.credentials/<api-name>.json.