Jump to content
Sign in to follow this  
Guest mrdavidlaing

How do I debug a (401) Unauthorized error?

Recommended Posts

Guest mrdavidlaing

I’m trying to logon using the following code:

var ctx = new ApiClient(new Uri(apiUrl));
ctx.LogIn(userName, password);

But getting the following error:

05/01/2011 12:16:27 [DEBUG] CityIndex.JsonClient.ThrottedRequestQueue - Dispatched #1 : https://ciapip******************.co.uk/TradingApi/session 
05/01/2011 12:16:28 [DEBUG] CityIndex.JsonClient.ThrottedRequestQueue - Recieved #1 : https://ciapip******************.co.uk/TradingApi/session 
05/01/2011 12:16:30 [DEBUG] CityIndex.JsonClient.ThrottedRequestQueue - Waiting: 00:00:01.5070000 to send https://ciapip******************.co.uk/TradingApi/session
05/01/2011 12:16:32 [DEBUG] CityIndex.JsonClient.ThrottedRequestQueue - Waiting: 00:00:01.5680000 to send https://ciapip******************.co.uk/TradingApi/session

System.Net.WebException: The remote server returned an error: (401) Unauthorized.
at System.Net.HttpWebRequest.BeginGetResponse(AsyncCallback callback, Object state)
at CityIndex.JsonClient.ThrottedRequestQueue.ProcessQueue(Object ignored) in ThrottedRequestQueue.cs: line 217
at System.Threading.ExecutionContext.runTryCode(Object userData)
at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
at System.Threading._TimerCallback.PerformTimerCallback(Object state)

What best steps to debug this issue?

Is there a way to get further details of exactly what the requests / response header/body is?

Can I get a more verbose error message?

Share this post


Link to post

Is there a way to get further details of exactly what the requests / response header/body is?

One tooling agnostic option would be a web debugging proxy for request / response interception and introspection: a common and excellent choice is Fiddler (.NET / freeware), but commercial offerings do exist as well of course, with Charles (Java / shareware) being the top most choice on my evaluation list currently.

Using Fiddler is pretty straight forward with the following three common scenarios:

Share this post


Link to post
Guest mrdavidlaing

 

Is there a way to get further details of exactly what the requests / response header/body is?

One tooling agnostic option would be a web debugging proxy for request / response interception and introspection: a common and excellent choice is Fiddler (.NET / freeware), but commercial offerings do exist as well of course, with Charles (Java / shareware) being the top most choice on my evaluation list currently.

Using Fiddler is pretty straight forward with the following three common scenarios:

 

What do you guys think to having the client libraries have a “extra verbose” mode that gives similar info to what you’d get from fiddler.

Share this post


Link to post

 

Is there a way to get further details of exactly what the requests / response header/body is?

One tooling agnostic option would be a web debugging proxy for request / response interception and introspection: a common and excellent choice is Fiddler (.NET / freeware), but commercial offerings do exist as well of course, with Charles (Java / shareware) being the top most choice on my evaluation list currently.

Using Fiddler is pretty straight forward with the following three common scenarios:

 

@mrdavidlaing – verbose logging options are a very effective debugging and monitoring aid, but granular instrumentation (ideally at runtime) is crucial in this case, i.e. you want to be able to specify verbosity and facility in order to restrict logging output regarding the amount of information desired for the task at hand (otherwise one can easily miss the forest for the trees …) – given other answers it looks like this is taking care of already :)

Share this post


Link to post
Guest mrdavidlaing

 

Is there a way to get further details of exactly what the requests / response header/body is?

One tooling agnostic option would be a web debugging proxy for request / response interception and introspection: a common and excellent choice is Fiddler (.NET / freeware), but commercial offerings do exist as well of course, with Charles (Java / shareware) being the top most choice on my evaluation list currently.

Using Fiddler is pretty straight forward with the following three common scenarios:

 

1

Its worth noting that using a web debugging proxy changes the behaviour of the streaming protion of the CIAPI.CS client. Specifically, since Fiddler breaks long running HTTP connections, streaming falls back to polling rather than long running HTTP connection.

Share this post


Link to post

With regards to C# JsonClient, it is simple matter of the programmer neglecting to log the data. Whoever hired that monkey should be fired along with the monkey. ;–)

Created issue: https://github.com/cityindex/CIAPI.CS/issues/issue/1

Well, the programmer in charge seems to be well prepared for all things logging at least: I noticed a commit regarding Common.Logging a couple of days ago already – excellent choice for .NET clients :)

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×