Docusign OAuth getAccessToken failing for Java app - java

I have a Java application which has been Docusigning away nicely until it broke sometime last week (might have been anytime in the last couple of weeks) .
Nothing has changed on my side, so I suspect some change on the Docusign front.
The symptoms are very puzzling and are as follows :
Sign-in with OAuth works fine up to the stage when it attempts to get the access token, at which point it hangs until it times out. The initial phases (log in, call callback with generated oauth code which then calls the getAccesCode component ) work fine, and here's the kicker - if I plug the exact values from the hanging getAccessToken call into curl and execute it from the same server, it works fine.
Here are the details of the hanging call :
getAccessToken request location='https://account-d.docusign.com/oauth/token'
getAccessToken request body=grant_type=authorization_code&code=<many characters>'
getAccessToken Request header : Authorization:Basic Y2E1ZWM3N2UtMGQ4 + MORE
So it is definitely something to do with the Java libraries, however it is not possible to get a debug trace of the OAuth part on the Docusing server (although I know you can trace the actual API calls by enabling the Docusign logs it does not appear to trace the oauth steps )
What is puzzling is that it was working fine for months. And now works fine with curl, but just hangs in Java. I suspected SSL , but if that were the case why do the initial steps work ?
This is the Java stacktrace , interestingly does not always get dumped (but the hang always happens)
java.net.SocketException: Connection timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
at sun.security.ssl.InputRecord.read(InputRecord.java:480)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927)
at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:884)
at sun.security.ssl.AppInputStream.read(AppInputStream.java:102)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:275)
at java.io.BufferedInputStream.read(BufferedInputStream.java:334)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:687)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:633)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:658)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1323)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:468)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:338)
at org.apache.oltu.oauth2.client.URLConnectionClient.execute(URLConnectionClient.java:98)
As mentioned , running curl against https://account-d.docusign.com/oauth/token with parameters grant_type=authorization_code and the generated code=blah with the appropriate auth header works fine, returning the correct json response.
Any ideas anyone ? How can I trace the Docusign side to find out why it is hanging ? What has changed of late ? New SSL certs ? I'm stumped.

Per Amit and DS Support, DocuSign has ended support for TLS1.0 in Demo from May 29th, 2018 and will soon end the support in PROD as well. Please test the connection on your end if you are using TLS1.0, if yes then you need to upgrade it to TLS1.1+ to again start using DS APIs. I am assuming if you have not done any code changes then this is the issue which you are seeing in your application.

Related

After deploy Google App Engine returns HTTP response code 403

I've done another deploys and all was fine, but after finishing the app, I'm getting this error. And the page request keeps loading.
Do I need to configure something in "IAM"?
Java 11
Standard Environment
h2 DB
Spring boot
The stack trace from Google Cloud:
java.io.IOException: Server returned HTTP response code: 403 for URL: https://clouddebugger.googleapis.com/v2/controller/debuggees/register at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1919) at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1515) at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:250)
at com.google.devtools.cdbg.debuglets.java.GcpHubClient.registerDebuggee (Unknown Source)
I've got new data using Stackdriver debug.
"message": "Stackdriver Debugger API has not been used in project
929024293238 before or it is disabled. Enable it by visiting
https://console.developers.google.com/apis/api/clouddebugger.googleapis.com/overview?project=929024293238
then retry. If you enabled this API recently, wait a few minutes for
the action to propagate to our systems and retry.",
Just a note if somebody else stumbles across this error: I had the same message in Google's App Engine dashboard popping up up to 60 times in a couple of minutes.
Enabling the Stackdriver Debugging API, as linked above, solved it. No more error logs (of that kind) were being produced. The weired thing is that the Stackdriver Debugging API should have been turned on by default for my standard environment.
The log wasn't very informative.
I change the application port from 8000 to 8080.
application.properties:
server.port=${PORT:8080}
Now the app is running fine.

Google Sheet API Update tokens?

For god's sake I'm out of my mind right now.
I can't get to seemingly an extremely easy point, I've travelled through hundreds of web pages, but couldn't succeed in finding an answer.
I've been using Google Sheet API (Java lang), and when I started it was all fine and working. And is still working, but the problem is - I need to change my account. Because of reasons, no other way
I'm copying all the new credentials, doing step-by-step what the Quickstart says, but yet every time I try to get access to the spreadsheet I get this:
Exception in thread "main" com.google.api.client.auth.oauth2.TokenResponseException: 401 Unauthorized
at com.google.api.client.auth.oauth2.TokenResponseException.from(TokenResponseException.java:105)
at com.google.api.client.auth.oauth2.TokenRequest.executeUnparsed(TokenRequest.java:287)
at com.google.api.client.auth.oauth2.TokenRequest.execute(TokenRequest.java:307)
at com.google.api.client.auth.oauth2.Credential.executeRefreshToken(Credential.java:576)
at com.google.api.client.auth.oauth2.Credential.refreshToken(Credential.java:493)
at com.google.api.client.auth.oauth2.Credential.intercept(Credential.java:217)
at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:868)
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)
I've tried deleting tokens folder. Even tried to create a totally new project. Nothing works.
Where does the problem hide? In browsers? What browser? I'm using Safari (which is default), but I've got Chrome on my Mac too.
Please help, I'm desperate, it's deadline today

Rest Assured - Getting Operation Timed Out Error while testing using RestAssured. But The same endpoint working fine in browser

I have an endpoint to be tested using RestAssured. The same endpoint is working fine while opening it in browser/Postman. But, while trying to test the same using RestAssured,
I am getting Operation Timed Out Error.
I had to connect to proxy to make that end point working in browser. used the same proxy in the rest assured also.
Sample Code below:
given().proxy("My_Proxy_URL_HERE",8080).when().get("My_API_URL_Here").then().log().all();
I am getting the response as
"Operation Timed Out" with Status Code 503.
I need your suggestion, what could be the possible issue, how to debug etc. Any suggestion is appreciated. Thanks in advance.
There can be many reasons for this behavior:
The address is just wrong and given there is some load balancer/proxy it can be configured to wait for a certain period of time and then respond with 503 status code.
Note, 503 is not a "request timed out", but "Service Unavailable".
The request url is good, but the request lacks some headers so that the load balancer/proxy won't be able to route the request to the required server.
How to check this? there exist tools that can come handy in this situation:
Check the access logs of the load balancer/proxy and even of your server if its possible - and see the request.
If it doesn't help, try to compare requests coming from rest-assured vs regular request. You can use tools like Burp for example, there are others, or you can even roll your own.
The idea is simple:
Start the "interceptor" on some port of your local computer (say, 9999 for example)
Configure the interceptor to forward all the requests to proxy of your choice (identified by URL - My_Proxy_URL_HERE and port 8080).
Now rest-assured must call localhost:9999 and the request will be intercepted by this tool. You'll be able to inspect its contents - headers, body, http method - everything.
Do the same for browser request and compare.

GWT back-end intercepting/blocking external requests

My company’s web application is using GWT both for front-end and back-end and we’d like to remove GWT from the project. Our current objective would be to make a new login page in Angular2 using the existing GWT back-end.
The main problem we encounter at the moment is that all the requests coming from outside the current GWT front-end seem to be intercepted/blocked and don’t return anything. I’m currently using Postman to make GET requests from the server.
Here is the URL I’m calling : http://localhost:9997/RestServer/api/users/1.
Postman’s response:
« Could not get any response
There was an error connecting to http://localhost:9997/RestServer/api/users/1. »
GWT Development Mode’s console returns an error:
[TRACE] Connection received from 127.0.0.1:60296
[ERROR] Unrecognized command for client; closing connection
com.google.gwt.dev.shell.BrowserChannelException: Invalid message type 71
at com.google.gwt.dev.shell.BrowserChannel$Message.readMessageType(BrowserChannel.java:1135)
at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:248)
at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:222)
at java.lang.Thread.run(Thread.java:745)
Have you got any idea why my requests are intercepted? Why I can't even receive a http response?
If you need more informations to answer just ask for it.
Port 9997 in the old dev mode is not an HTTP server. This is the port on which the legacy browser plugin (unsupported in modern FF and Chrome due to breaking changes in those browsers) would connect to run Java code and enable remote debugging, hotswapping, etc.
Instead, you need to connect to the HTTP port, which is 8888 or 8080 or something like that.

Apns: Connection closed by remote host

I have a Java app, which works with Apple Push Notification Server (APNS). I use lib: JavaPNS.jar for sendings push messages to iDevices.
But, sometimes Push Notification doesn't work, I've found such error:
[16:35:40] Andrew Balakhanov: 2012-10-27 04:00:00,616 WARN
[com.notnoop.apns.internal.ApnsConnectionImpl] Failed to send message
com.notnoop.apns.EnhancedApnsNotification#af310b99... trying again
java.net.SocketException: Connection closed by remote host at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.checkWrite(SSLSocketImpl.java:1339)
at
com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:44)
at java.io.OutputStream.write(OutputStream.java:58) at
com.notnoop.apns.internal.ApnsConnectionImpl.sendMessage(ApnsConnectionImpl.java:161)
at
com.notnoop.apns.internal.ApnsServiceImpl.push(ApnsServiceImpl.java:46)
at
com.notnoop.apns.internal.AbstractApnsService.push(AbstractApnsService.java:52)
at
com.notnoop.apns.internal.ApnsServiceImpl.push(ApnsServiceImpl.java:36)
at com.clinics.core.api.util.APN.sendReminderAlert(APN.java:55) at
com.clinics.core.api.services.schedule.reminder.impl.ReminderSenderMobile.prepareAndSend(ReminderSenderMobile.java:190)
at
com.clinics.core.api.services.schedule.reminder.impl.ReminderSenderMobile.send(ReminderSenderMobile.java:132)
at
com.clinics.core.api.services.schedule.reminder.AbstractReminderFacade.generateAndSendReports(AbstractReminderFacade.java:53)
at
com.clinics.core.api.services.schedule.reminder.ReminderJob.doIt(ReminderJob.java:64)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597) at
org.springframework.util.MethodInvoker.invoke(MethodInvoker.java:273)
at
org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean$MethodInvokingJob.executeInternal(MethodInvokingJobDetailFactoryBean.java:264)
at
org.springframework.scheduling.quartz.QuartzJobBean.execute(QuartzJobBean.java:86)
at org.quartz.core.JobRunShell.run(JobRunShell.java:202) at
org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:525)
Could you please tell me, what the error means? Is it mean, that Apple server banned me, is it mean that I send too many requests to it?
The most likely cause of this error is that you are sending production tokens to the sandbox server or sandbox tokens to the production server.
I got this exact behavior today until I figured out I had signed my app with an Ad Hoc profile, which makes the app use the production push server for generating the token, while my server was talking to the sandbox push server.
This error could also appear when the payload is too long.
You can check by calling PayloadBuilder's isTooLong() function.
PayloadBuilder payload = APNS.newPayload();
// build your payload
if (payload.isTooLong())
{
// your payload is too long, a push() will result in the above exception
}
The problem I was facing was that the instructions I was using to generate my .p12 certificate file were incorrect. I ended up following the instructions from NWPusher and those worked for me.

Categories

Resources