I'm attempting to upload a video from a Java (Spring Boot) application to the Cloudflare servers by pulling the video using Spring's RestTemplate and then using the response InputStream to upload the content.
To upload the video content (InputStream), I'm following the docs at Upload Video File and API docs: Video Upload Using TUS
I've used the recommended official tus-java client; But, when I attempt to upload the video I'm getting a
unexpected status code (400) while uploading chunk
When I debug the tus-java-client, I see the underlying error being thrown by the Cloudflare endpoint is:
{
"result": null,
"success": false,
"errors": [
{
"code": 10004,
"message": "Decoding Error"
}
],
"messages": [
{
"code": 10004,
"message": "invalid character '\\x00' looking for beginning of value"
}
]
}
Is there any solution to this so I can successfully upload the video to Cloudflare (stream service)?
I'm using Java 17 and TUS java client version 0.4.5
The full source code of what I'm trying to do along with the steps to replicate this can be checked at this GitHub repo (but please, to let me know if I should paste it here): https://github.com/lealceldeiro/cloudflareuploader#run-the-app
There's an open question in the Cloudflare community here: https://community.cloudflare.com/t/10004-decoding-error-while-uploading-video-to-stream/471107/1
Related
I'm trying to setup a dev environment for developing with FCM and I'm getting this error.
I'm using the configuration of out-of-box and it is been loaded properly (I've debugged).
I'm working with java 8 and spring 2.2.12 and firebase-admin 7.1.0.
com.google.api.client.http.HttpResponseException: 403 Forbidden
POST https://fcm.googleapis.com/v1/projects/projectt-82004/messages:send
{
"error": {
"code": 403,
"message": "SenderId mismatch",
"status": "PERMISSION_DENIED",
"details": [
{
"#type": "type.googleapis.com/google.firebase.fcm.v1.FcmError",
"errorCode": "SENDER_ID_MISMATCH"
}
]
}
}
What I've tried so far
Create a new project and a new key
There was an old documented error where the services were not activated by default. I've checked the services and all of them are active.
Also, the user appears to have enough privileges.
I've also updated the library to the latest version (it also happened with the previous version)
Am I missing something here?
UPDATE
Same code, later on the following day, without any changes to the code, it started working. So the conclusion was that there was some problem with the service itself.
I am trying to use the Google Cloud Translate API. I generated a JSON file from a service account and set the GOOGLE_APPLICATION_CREDENTIALS to where the JSON file is saved. I then used it in a program like so:
import com.google.cloud.translate.*;
...
Translate translate = TranslateOptions.getDefaultInstance().getService();
Translation translation = translate.translate(message);
But I get the following error
com.google.cloud.translate.TranslateException: Your application has authenticated using end user credentials from the Google Cloud SDK or Google Cloud Shell which are not supported by the translate.googleapis.com. We recommend that most server applications use service accounts instead. For more information about service accounts and how to use them in your application, see https://cloud.google.com/docs/authentication/
at com.google.cloud.translate.spi.v2.HttpTranslateRpc.translate(HttpTranslateRpc.java:61)
at com.google.cloud.translate.spi.v2.HttpTranslateRpc.translate(HttpTranslateRpc.java:144)
at com.google.cloud.translate.TranslateImpl$4.call(TranslateImpl.java:113)
at com.google.cloud.translate.TranslateImpl$4.call(TranslateImpl.java:110)
at com.google.api.gax.retrying.DirectRetryingExecutor.submit(DirectRetryingExecutor.java:89)
at com.google.cloud.RetryHelper.run(RetryHelper.java:74)
at com.google.cloud.RetryHelper.runWithRetries(RetryHelper.java:51)
at com.google.cloud.translate.TranslateImpl.translate(TranslateImpl.java:110)
at com.google.cloud.translate.TranslateImpl.translate(TranslateImpl.java:124)
at app.websockets.Messenger.onMessage(Messenger.java:31)
at org.java_websocket.server.WebSocketServer.onWebsocketMessage(WebSocketServer.java:569)
at org.java_websocket.drafts.Draft_6455.processFrame(Draft_6455.java:709)
at org.java_websocket.WebSocketImpl.decodeFrames(WebSocketImpl.java:367)
at org.java_websocket.WebSocketImpl.decode(WebSocketImpl.java:212)
at org.java_websocket.server.WebSocketServer$WebSocketWorker.run(WebSocketServer.java:925)
Caused by: com.google.api.client.googleapis.json.GoogleJsonResponseException: 403 Forbidden
{
"code" : 403,
"errors" : [ {
"domain" : "usageLimits",
"message" : "Your application has authenticated using end user credentials from the Google Cloud SDK or Google Cloud Shell which are not supported by the translate.googleapis.com. We recommend that most server applications use service accounts instead. For more information about service accounts and how to use them in your application, see https://cloud.google.com/docs/authentication/.",
"reason" : "rateLimitExceeded"
} ],
"message" : "Your application has authenticated using end user credentials from the Google Cloud SDK or Google Cloud Shell which are not supported by the translate.googleapis.com. We recommend that most server applications use service accounts instead. For more information about service accounts and how to use them in your application, see https://cloud.google.com/docs/authentication/.",
"status" : "PERMISSION_DENIED"
}
at com.google.api.client.googleapis.json.GoogleJsonResponseException.from(GoogleJsonResponseException.java:146)
at com.google.api.client.googleapis.services.json.AbstractGoogleJsonClientRequest.newExceptionOnError(AbstractGoogleJsonClientRequest.java:113)
at com.google.api.client.googleapis.services.json.AbstractGoogleJsonClientRequest.newExceptionOnError(AbstractGoogleJsonClientRequest.java:40)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest$1.interceptResponse(AbstractGoogleClientRequest.java:321)
at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:1067)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:419)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:352)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.execute(AbstractGoogleClientRequest.java:469)
at com.google.cloud.translate.spi.v2.HttpTranslateRpc.translate(HttpTranslateRpc.java:130)
... 13 more
Here is my JSON file:
{
"type": "service_account",
"project_id": "ecstatic-motif-220300",
"private_key_id": "keyid",
"private_key": "somekey",
"client_email": "kokosole#ecstatic-motif-220300.iam.gserviceaccount.com",
"client_id": "100208235593900994013",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://oauth2.googleapis.com/token",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
"client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/kokosole%40ecstatic-motif-220300.iam.gserviceaccount.com"
}
Can anyone explain what is going on here? How can I fix it? Google Cloud SDK is not even installed.
You are authenticated as a user, while the API expects a service account, seen that you use Client Libraries with the "import com.google.cloud.translate.*;" statement. You may find related detail in the Setting up authentication paragraph on the "Translation API Client Libraries" page.
I have successfully been able to deploy and run this demo for using conversation-with-discovery.
I have spent the last 2 weeks trying to run the application with my own data, and provide a query on the Chat App localhost that I know should provide results from my data from Watson Discovery, I get the following:
http://localhost:9081/dist/index.html: "Service seems to be down.Please try again
after sometime or Please check the logs." "No response from Watson"
On Terminal Command Line: "10:40:03.549 [Default Executor-thread-79]
INFO com.ibm.watson.apis.conversation_with_discovery.discovery.DiscoveryQuery - Query: searchText:CO2 Absorption
10:40:04.360 [Default Executor-thread-79]
INFO com.ibm.watson.apis.conversation_with_discovery.discovery.DiscoveryClient - Creating Discovery Payload
10:40:04.361 [Default Executor-thread-79]
ERROR com.ibm.watson.apis.conversation_with_discovery.rest.ProxyResource - Exception on Query:null"
Now if I run a query on the Local Chat App that doesn't make sense to Watson Discovery I get the following:
http://localhost:9081/dist/index.html: "Sorry I haven't learned answers to questions like this" " "log_messages": [],
"CEPayload": [
{
"text": "empty",
"textSnippet": "empty",
"confidence": "0.0",
"sourceUrl": "empty",
"title": "No results found"
}
]
},
"input": {
"text": "CO#""
On Terminal Command Line: "10:52:39.614 [Default Executor-thread-228]
INFO com.ibm.watson.apis.conversation_with_discovery.discovery.DiscoveryQuery - Query: searchText:CO#
10:52:40.385 [Default Executor-thread-228]
INFO com.ibm.watson.apis.conversation_with_discovery.discovery.DiscoveryClient - Creating Discovery Payload"
My intuition tells me that something is not right when Discovery API tries to send back a response to the Chat App via the Java application I am using but when I ask something that Discovery cannot answer I get "empty" fields for my Payload, as shown above.
Based on what I have found regarding this type of set up tried the following:
I changed the fields on the Java Application to match with what is shown on discovery as fields on the data schema and on the API
I modified the manifest.yml file: buildpack: liberty-for-java_v3_7-20170118-2046" and "env: JVM: openjdk as suggested on a few forums
I downloaded java-sdk-java-sdk-4.0.0 but am not sure how to update my current Java SDK. Not sure if it's the actual problem so haven't deeply approached this route.
I am running on macOS Sierra version 10.12.6. Perhaps something is incompatible with my OS?
I just need some guidance before I continue down a rabbit hole that holds no solution. Could it be the Java Application or is this an internal Java system issue on my laptop? I have searched forums and seen both situations.
I'm trying to list of all files within Google Drive using Drive API. I've found one API which gives me this list.
When I try to run this API in API explorer it works fine. Give me list of all files
https://www.googleapis.com/drive/v3/files
But when I copy paste url in browser & runs it proving API key, Show me an error.
https://www.googleapis.com/drive/v3/files?key={YOUR_API_KEY}
{
"error": {
"errors": [
{
"domain": "global",
"reason": "insufficientFilePermissions",
"message": "The user does not have sufficient permissions for this file."
}
],
"code": 403,
"message": "The user does not have sufficient permissions for this file."
}
}
I'm pretty new in android. I just want retrieve file list. not search function.
The issue might be your file permission check this documentation for the file permissions -
https://developers.google.com/drive/v3/reference/permissions
Only OAuth 2.0 is supported for Google Drive API.
https://developers.google.com/drive/v3/web/about-auth
I'm trying to get familiar with the Google Drive API using the official Java sample. However, after wasting a few hours and attempting to set the sample up two times, I'm still not able to use it as expected.
Instead of displaying a file's content it throws a 404 error in the FileServlet (/svc path). More specifically, service.files().get(fileId).execute(); seems to return null. I've tried it with different files, different MIME types, directly from Google Drive as well as using the Google File Picker.
I've followed the steps described over at https://developers.google.com/drive/examples/java as closely as possible.
Has anyone been able to get the sample running?
edit:
Here's the log output of the FileServlet when requesting the URL /svc?file_id=0B08R9MrOE-ejZTY2M2I5MjAtYmVjZS00OTkyLWI4ZTEtOTg4OGM3YTIxMWEw (the 404 error is thrown at line 78):
2012-04-26 08:21:36.077
com.google.api.client.http.HttpRequest execute: -------------- REQUEST --------------
GET https://www.googleapis.com/drive/v1/files/0B08R9MrOE-ejZTY2M2I5MjAtYmVjZS00OTkyLWI4ZTEtOTg4OGM3YTIxMWEw
Accept-Encoding: gzip
User-Agent: Google-HTTP-Java-Client/1.8.3-beta (gzip)
D 2012-04-26 08:21:36.263
com.google.api.client.http.HttpResponse <init>: -------------- RESPONSE --------------
403 OK
content-type: application/json; charset=UTF-8
content-encoding: gzip
date: Thu
date: 26 Apr 2012 06:21:36 GMT
expires: Thu
expires: 26 Apr 2012 06:21:36 GMT
cache-control: private
cache-control: max-age=0
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
content-length: 188
server: GSE
x-google-cache-control: remote-fetch
via: HTTP/1.1 GWA
D 2012-04-26 08:21:36.265
com.google.api.client.http.HttpResponse getContent: Response size: 188 bytes
D 2012-04-26 08:21:36.271
com.google.api.client.http.HttpResponse getContent: {
"error": {
"errors": [
{
"domain": "usageLimits",
"reason": "dailyLimitExceededUnreg",
"message": "Daily Limit Exceeded. Please sign up",
"extendedHelp": "https://code.google.com/apis/console"
}
],
"code": 403,
"message": "Daily Limit Exceeded. Please sign up"
}
}
This sounds a lot like "I don't know you" to me, so I have taken another look at my Client ID and Client Secret: I've noticed that there are two Client IDs and Client Secrets being displayed in the API Console, one "Client ID for web applications" and another "Client ID for Drive SDK". I've used the one for web applications previously, so I tried to switch to the one for the Drive SDK. Unfortunately, this doesn't change anything. Same error... :/
As per your logs it seems that your 404 error is caused by a 403 error returned on the request to the Drive API.
Errors from Google APIs usually contains an explanations in their body. In your case:
"error": {
"errors": [
{
"domain": "usageLimits",
"reason": "dailyLimitExceededUnreg",
"message": "Daily Limit Exceeded. Please sign up",
"extendedHelp": "https://code.google.com/apis/console"
}
],
"code": 403,
"message": "Daily Limit Exceeded. Please sign up"
}
}
This one would typically mean that you have not enabled access to the Google Drive API on your Google APIs Console project. In order to do this:
Open your project in the Google APIs Console
Go to the Services section
Enable the Drive SDK and Drive API by clicking the On/Off toggle
Don't forget to configure your app in the Drive SDK section and your OAuth settings in the **API Access" section
This is all described in the Get started > Register an App section of our documentation. You should also make sure that you go through the other sub-sections of Get started.
I eventually managed to get it working. I'm not sure what was the problem before, but here are some tips for those who are facing similar problems:
The "Client ID for web applications" and the "Client ID for Drive SDK" confused me. Unfortunately the documentation doesn't tell you which one to use at which place, but it seems like you only need the "Client ID for web applications".
If you update your Chrome extension or the API console it could take some time until Drive recognizes those changes. For example, changing the OAuth Client ID in the API console could take some time until it takes effect, since everybody's caching. If you are testing your application, deleting cache and cookies helps speed up the process.
Good luck with your applications, and thanks to everybody who helped me!
In my experience, "403 Quota Exceeded" always stems from the HTPP Authorization header not being set.
I used the java OAuth code distributed in Google's dredit sample for a program that goes through the "opens with" flow and likewise recieved the 403 error.
I had to dig into the OAuth code to find the problem, the source of which I haven't seen mentioned elsewhere in regard to the 403 error. Essentially the ExchangeCode method of CredentialMediator assumes there is only one redirect uri and this is the one you are hoping to go to. This wasn't the case for me and resulted in a CodeExchangeException.
To resolve you could massage the list of uris in the client_secrets so the uri you wish to redirect to is first or some such, but if this method could go to any one of a number of uris it will need parameterisation.
I hope this helps someone root out their 403 gremlin.