barrywood78 / Coinbase.AdvancedTrade

Coinbase Advanced Trade API Wrapper
8 stars 1 forks source link

Websocket (or other) authentication example #3

Closed Lumaswell closed 8 months ago

Lumaswell commented 8 months ago

I'm using the API to access the websocket, but I can't get past the authentication step. I've applied the API Key Name and Secret as outlined in the coinbase code samples here and the internal test/example code from github. I'm guessing either the layout they used (with newlines etc) doesn't jive with csharp or the code handles it differently, but I haven't been able to follow along and find where the string is assembled. Could someone provide an example with a false or deleted key (maybe in the readme) for those of us who aren't expert level coders?

barrywood78 commented 8 months ago

@Lumaswell

In this API wrapper, check out this example in the candles websocket test application.

My API key and secret are stored in a Windows environment variable as per the source code and just ran without issue. Make sure your API key has the appropriate permissions.

image

Lumaswell commented 8 months ago

Yah, I did the same thing. Just to check, according to the coinbase api documentation, you're supposed to use name and secret (and coinbase help said the same thing when I reached out to them). I was using the ticker test as my example but I'll try the candle and report back.

barrywood78 commented 8 months ago

@Lumaswell Just tested the ticker websocket and it's working fine: image

The code in the test application I wrote is using user environment variables. Maybe you set up system ones? Any case, you can just try hardcoding your API key and secret into the code here instead of using the environment variables as a test.
image

I don't believe there to be any issues with this code, most likely just your configuration on using the API key and secret and/or permissions you've assigned to it. Like I said, try hardcoding your API key/secret into your code instead of trying to use environment variables, maybe that will help.

Lumaswell commented 8 months ago

@barrywood78

So I've tried all your suggestions (and quite a few besides) and I've learned a few things. The error I'm receiving is specifically

Raw message received at 1/6/2024 3:53:28 PM: {"type":"error","message":"authentication failure"}

I thought this was the generic response, but after browsing threads I found out it's actually not. If there's an IP whitelist error it returns a specific IP error, if there's a key problem it returns Invalid credentials, etc. So I don't think it's a key issue anymore.

Other threads point to this being a problem with the generation of the signature. It seems evenly split between people who got the order wrong, and people who got the timestamp wrong. Since yours works for you, I'm guessing it's not the order issue. Is it possible this is because we're in different time zones? Or using different versions of C#?

Looking at it I just realized the timestamp coming in on the error is also wrong(+5 hours). I'm guessing there's a relative or absolute problem with the timestamping. I'm gonna see if I can hunt it down. Thanks.

barrywood78 commented 8 months ago

@Lumaswell What I can tell you is that when you have the wrong API keys in this example I just ran on the Ticker websocket, you'll get the same "authentication failure" error you're getting as per below: image image

This is a screenshot of it working correctly: image

The time zone it's returning is 5 hours ahead of my time zone as well as I'm in Ontario Canada even when it's working properly. (Raw message received at 2024-01-06 4:34:27 PM). This isn't my time so not sure if it's coinbase servers or not. What I do know is that I've had others use this API wrapper without issue once their keys and permissions are setup properly within Coinbase.

Regarding different time zones, that wouldn't make a difference as there's no time zones hard coded into the code. RE: C# versions, this wrapper is targeted to .NET 7.0 as a minimum. In Github here, you have access to the whole solution so if you're not already, you can open the solution in Visual Studio and check out all the test projects.

When I wrote this, it took me a while to get my API keys and permissions set up properly before it would even work. Good luck with everything.

Lumaswell commented 8 months ago

@barrywood78

Yah, your time coding was impeccable. I'm just going to have to keep trying different keys and permissions until I get things working. Thanks for helping out on this. +5 is UTC vs Eastern btw, that was the reason. If you want the returns to reflect local time you can just drop the utc on the message received timestamp. I'll post once I get things figured out, thanks again.

Lumaswell commented 8 months ago

So after reaching out on the forums someone pointed out your code is using the legacy api keys from coinbase.com. I failed to recognize the difference. If you try to create an API key from the advanced trade site it takes you to the cloud.coinbase.com to create the key. According to the forums and the help from advanced trade this is the correct thing to do so that's what I've been doing. Once I created a legacy API key on coinbase.com it worked fine. Going forward you may want to implement the newer keys as they are supposed to deprecate the legacy ones at some point. Thanks for the all the help!

barrywood78 commented 8 months ago

@Lumaswell Thanks for bringing this to my attention. This didn't exist when I first wrote the API wrapper. It was just API Keys (which are now Legacy API Keys) and OAuth. Coinbase seems to be actively making updates to their API lately which is nice. When I have some time, I'll see if I can add support for these newer API keys while keeping the older ones working as well.

Thanks again!

barrywood78 commented 8 months ago

@Lumaswell Hi, since you brought this new "Cloud API Trading Keys" to my attention, I wanted to let you know that I just updated the code in Github and in Nuget to use both Legacy and the newer Cloud API Trading Keys. The constructor for the client now takes an optional ApiKeyType (default is Legacy to avoid breaking changes).

Thanks again! Barry