Zum Inhalt springen

API "end_datetime" -> Rückmeldung: "ungültige Anfrage" (C#)


blackbt17

Empfohlene Beiträge

Hallo zusammen!

 

Ich habe mit mit C# und der Bitcoin.de Trading API ein Tool geschrieben, welches Transaktionen ausführen soll.

Das ganze klappt wunderbar, sowohl für kaufen als auch für verkaufen.

Ich verwende bis jetzt die Parameter: max_amount, min_amount, new_order_for_remaining_amount, price und mode.

 

Wenn ich nun den Parameter end_datetime einfüge, dann bekomme ich immer die Meldung

 Ungültige Anforderung

 Invalid Signature

 

Obwohl ich nichts anderes mache als vorher.

Konkret heißt das: folgender POST-String klappt:

 

url_encoded_query_string = "max_amount=" + t_amount + "&min_amount=" + t_amount + "&new_order_for_remaining_amount=1&price=" + t_price + "&type=" + mode;    //Schritt 2

 

und folgender Code klappt nicht:

 

url_encoded_query_string = "end_datetime=" + "2017-09-30T23:45:00+02:00" + "&max_amount=" + t_amount + "&min_amount=" + t_amount + "&new_order_for_remaining_amount=1&price=" + t_price + "&type=" + mode;    //Schritt 2

 

 

Ich bin jetzt soweit, dass ich weiß, dass mit dem Doppelpunkt etwas nicht stimmt. Und das scheint auch logisch zu sein.

Nur weiß ich nicht, wie ich den String umformatieren muss, damit ich diesen mit der API ausführen kann.

 

Wenn ich nur den String "2017-09-30T23:45:00+02:00" mit URLEncode umformatiere, dann klappt es auch nicht. Es wird ja auch die Signature anhand dieses Strings berechnet.

 

Hat in der Hinsicht jemand Erfahrung? Oder klappt einfach der Parameter "end_datetime" bei der API nicht?

 

Gruß,

Michael

 
 
Link zu diesem Kommentar
Auf anderen Seiten teilen

also bei mir klappt das und sieht so aus (python):
end_datetime = str(time.strftime("%Y-%m-%dT%X+02:00", time.localtime(time.time()+90*24*60*60))) # 90 tage

Das sollte dem Beispielformat in der Doku "2015-01-20T15:00:00+02:00" entsprechen.

 

Allerdings sieht deins eig auch richtig aus...

Ich kenn mich mit Encoding usw leider nicht aus, aber am Beginn meines Skriptes steht:
# coding: utf8
Ob das damit was zu tun hat, weiß ich nicht :D Bin eig kein Programmierer xD

Link zu diesem Kommentar
Auf anderen Seiten teilen

"2017-09-30T23:45:00+02:00" fuehrt zu einem Datumswechsel.

Versuch doch mal "2017-09-30T21:45:00+02:00" - eventuell hast Du einen Bug in der API gefunden?

 

Edit: Eventuell ist die Zeitspanne auch etwas lang gewaehlt - versuch doch mal "2017-09-10T23:45:00+02:00"

Bearbeitet von Jokin
Link zu diesem Kommentar
Auf anderen Seiten teilen

Danke erstmal.

Das mit dem Datumswechsel habe ich nicht bedacht... Hilft aber leider nicht.

 

@Serpens66:

Muss ich die Post-Parameter nicht mit HTML-Encode oder so behandeln, damit der Doppelpunkt html-tauglich wird? Denn eigentlich darf der nicht so übergeben werden, lese ich auf sämtliche Seiten.

Nur dann stellt sich die Frage, ob ich das Codieren vor der MD5-Berechnung mache oder erst danach?  :mellow:

Kannst du mal Posten, wie du die Anfrage an den Server schickst? Änderst du an dem String vor dem Absenden noch etwas?

Link zu diesem Kommentar
Auf anderen Seiten teilen

Online habe ich meinen Code nicht. Ich habe mich an ein Beispiel angelehnt, das ich auf den Microsoft-Seiten und in Foren gefunden habe.

Wie gesagt, es klappt alles, außer im String kommt ein Doppelpunkt oder ein "+" vor...

            webRequest = WebRequest.Create(url);
            webRequest.Method = mode;
            webRequest.Timeout = 20000;
           
            if (mode == "POST") webRequest.ContentLength = Encoding.UTF8.GetCharCount( post_data_;
            webRequest.ContentType = "application/x-www-form-urlencoded; charset=utf-8";
            webRequest.Headers.Add("X-API-KEY", api_key);
            webRequest.Headers.Add("X-API-NONCE", nonce.ToString());
            webRequest.Headers.Add("X-API-SIGNATURE", hmac);
            
            if (mode == "POST")
            {
                Stream st;
                
                st = webRequest.GetRequestStream();
                st.Write(post_data_b, 0, post_data_b.Length);
                st.Close();


            }

In deinem Python Beispiel werden die Daten als JSON übergeben. Kann ich das anstatt "application/x-www-form-urlencoded" auch tun? Dann müsste aber bitcoin.de das Format aktzepieren und ich müsste die Schreibweise "param1=wert1&param2=wert2" ändern in JSON-Format, oder? Der Rest kann ja dann gleich bleiben.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Problem gefunden:

Wenn ich als end_datetime nur angebe: "2015-01-20T15" bekomme ich die Meldung, dass das Zeitformat nicht stimmt.

Sobald ich aber den ersten Doppelpunkt mit reinnehme, dann kommt die Meldung "invalid signature".

Das heißt dann für mich, es gibt ein Problem mit den Sonderzeichen.

Mittlerweile habe ich alles URLEncodiert, damit daran nichts hapert... nur an was liegt es dann? Ich versuche in der Zwischenzeit weiter...

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 10 Monate später...
Am 30.8.2017 um 21:12 schrieb blackbt17:

Mittlerweile habe ich alles URLEncodiert, damit daran nichts hapert... nur an was liegt es dann? Ich versuche in der Zwischenzeit weiter...

Hi hallo blackbt17!

Auch wenn die "Zwischenzeit" schon etwas länger zu dauern scheint ;)

Aber - hast du das Problem lösen können?!

Beste Grüße

Peter

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 1 Monat später...
Am 7.8.2018 um 18:26 schrieb wilson76:

Wenn ich es richtig im Kopf habe, dann müssen die Query Parameter im Raw Format signiert werden, aber der Request mit URL encoded Zeichen

Ja, das stimmt soweit, so du mit "Raw Format" ganz normalen "Text" meinst. Parameter kann ich auch ganz normal übergeben, aber egal welches Datumsformat ich nutze, ich bekomme immer eine Fehlermeldung, dass das endDate-Format nicht gültig sei ....

Beste Grüße

Peter

 

PS: Sorry, dass ich erst heute antworte, aber ich hab keine Mailbenachrichtigung erhalten -.-

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 3 Monate später...
Zitat

 

Ich habe mit mit C# und der Bitcoin.de Trading API ein Tool geschrieben, welches Transaktionen ausführen soll.

Das ganze klappt wunderbar, sowohl für kaufen als auch für verkaufen.

 

Cool. Das Tool würde mich auch interessieren, damit ich das Rad nicht neu erfinden muss. Programmierer sind bekanntlich faul  ;).

Würdest du das Tool evtl. weitergeben?

 

Wahrscheinlich ist das Problem inzwischen gelöst... aber ich schreib' trotzdem mal was mir dazu einfällt:

Zitat

url_encoded_query_string = "max_amount=" + t_amount + "&min_amount=" + t_amount + "&new_order_for_remaining_amount=1&price=" + t_price + "&type=" + mode;

Ich bin jetzt soweit, dass ich weiß, dass mit dem Doppelpunkt etwas nicht stimmt. Und das scheint auch logisch zu sein.

Nur weiß ich nicht, wie ich den String umformatieren muss, damit ich diesen mit der API ausführen kann.

Der String ist tatsächlich nicht URL-encoded und klar: es dürfen keine Sonderzeichen wie ":" enthalten sein.

In C# müsste es ja so gehen:

Zitat

System.Web.HttpUtility.UrlEncode(stringToEncode);

Ohne System.Web geht es wohl auch

Zitat

Wenn ich nur den String "2017-09-30T23:45:00+02:00" mit URLEncode umformatiere, dann klappt es auch nicht. Es wird ja auch die Signature anhand dieses Strings berechnet.

Leider kenne ich die API (noch) nicht. Vermutlich muss aber der ganze String URL-encoded werden und die Signatur vorher.

Das erste was die API wohl macht, ist URL-decoden. Dann liegt wieder der ursprüngliche String mit den Sonderzeichen vor, und der sollte dann ja auch zur Signatur passen.

Aber wie gesagt ist das nur eine Vermutung.

Bearbeitet von Herr Coiner
Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 1 Jahr später...

Hallo,

ich krame diesen alten Beitrag mal raus, da ich mit der aktuellste API version ebenfalls dieses Problem habe. CreateOrder funktioniert ohne end_datetime einwandfrei, mit end_datetime kommt Invalid Signature.

So wie ich diesen Beitrag hier lese wurde dazu nie eine Lösung gefunden? Aus meiner Sicht ist das ein Bug, denn auch ich halte mich komplett an die Beschreibung der API Doku:

1. Ich baue den Parameterstring zusammen, die Werte werden dabei  einzeln URL encoded, also z.b.

end_datetime=2020-08-28T23%3a00%3a00%2b02%3a00&max_amount_currency_to_trade=0.00629844&min_amount_currency_to_trade=0.00629844&price=9526.17&type=buy

2. Ich sende alle post Parameter als x-www-form-urlencoded, das Bitcoin Api Log sagt:

POST-Parameter:

 
{
   "end_datetime":"2020-08-28T23:00:00+02:00",
   "max_amount_currency_to_trade":"0.00629844",
   "min_amount_currency_to_trade":"0.00629844",
   "price":"9526.17",
   "type":"buy"
}

Body:

{
   "errors":[
      {
         "message":"Invalid signature",
         "code":5
      }
   ],
   "credits":14
}

Da das ganze ohne end_datetime funktioniert, muss also hier der Fehler liegen. Lesen Leute von bitcoin.de dieses Forum, kann das wirklich sein, dass dieser bug seit > 2 Jahren vorhanden ist?

Danke + Grüße Casiopaya

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 29 Minuten schrieb casiopaya:

Hallo,

ich krame diesen alten Beitrag mal raus, da ich mit der aktuellste API version ebenfalls dieses Problem habe. CreateOrder funktioniert ohne end_datetime einwandfrei, mit end_datetime kommt Invalid Signature.

Da das ganze ohne end_datetime funktioniert, muss also hier der Fehler liegen. Lesen Leute von bitcoin.de dieses Forum, kann das wirklich sein, dass dieser bug seit > 2 Jahren vorhanden ist?

Danke + Grüße Casiopaya

Hallo Casiopaya,

ich bin den Umschwung auf die neue API noch nicht gegangen - das steht noch auf meiner Wenn-Ich-Mal-Zu-Komme-ToDo-Liste. Ich kann dir unmittelbar also nicht weiter helfen. 

Ich erinnere mich aber, dass ich für verschiedene Endpunkte mit "verschiedenen" Datumsformaten Erfolg hatte. Aus dem Kopf bekomme ich das grad nicht mehr genau hin, aber so dunkel habe ich in Erinnerung, dass ich - der Doku widersprechend! - dates mal so oder mal so übergeben musste:

2020-08-28T23:00:00+02:00
2020-08-28T23:00:00Z

Vielleicht hilft dir das weiter?

 

Es gibt einige Stellen in der API an den ich vermute, dass die von unterschiedlichen Leuten mit unterschiedlichen Informationen programmiert wurden - zumindest in den älteren Versionen ;)

 

Beste Grüße

Peter

Bearbeitet von cocoahead
Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich bin auch noch nicht überall bei der neusten Version.. 

Bei der Meldung war meistens das Problem (bei mir), dass der Parameter bei der Signaturberechnung gefehlt hat oder die Reihenfolge der Parameter nicht gepasst hat. 

Bearbeitet von fox42
Link zu diesem Kommentar
Auf anderen Seiten teilen

Hallo!

vor 30 Minuten schrieb cocoahead:

Und mit meinem Edit?


2020-08-28T23:00:00+02:00

2020-08-28T23:00:00Z

leider nein

vor 10 Minuten schrieb fox42:

Bei der Meldung war meistens das Problem (bei mir), dass der Parameter bei der Signaturberechnung gefehlt hat oder die Reihenfolge der Parameter nicht gepasst hat. 

Da es ohne end_datetime funktioniert, und das eindeutig der erste parameter ist ("e") kann ich beides ausschließen

 

Irgendwie verstehe ich euch aber so, dass bei euch ein CREATEORDER  mit end_datetime funktioniert? Das haut mich echt um 🙂

Das Problem bei Datumsangaben habe ich übrigens nur bei POST. GET (z.b. showMyTrades mit date_start) funktioniert auch bei mir.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 13 Minuten schrieb casiopaya:

Irgendwie verstehe ich euch aber so, dass bei euch ein CREATEORDER  mit end_datetime funktioniert? Das haut mich echt um 🙂

Ja, zumindest hat es das mit APIv2.

vor 13 Minuten schrieb casiopaya:

Das Problem bei Datumsangaben habe ich übrigens nur bei POST. GET (z.b. showMyTrades mit date_start) funktioniert auch bei mir.

Wie gesagt, es gibt einige starke Abweichungen innerhalb der API, wie was encodet/formatiert sein muss. Daher meine Vermutung "zwei Leute haben aneinander vorbei gearbeitet".

 

Beste Grüße

Peter

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ha, doch schon v4 bei mir..

postParams = "end_datetime=" + URLEncoder.encode(OutputFormat.dateFormatRFC3339.format(cal.getTime()), StandardCharsets.UTF_8.toString()) + "&"  + postParams;

 

Schau mal nach, ob das bei dir URL encoded ist. (und auch, ob alle Post Parameter in die Signatur einfließen)

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 47 Minuten schrieb fox42:

Schau mal nach, ob das bei dir URL encoded ist. (und auch, ob alle Post Parameter in die Signatur einfließen)

+ (NSDateFormatter *)dateFormatterEncodePostRFC3339 {
    static dispatch_once_t pred;
    static NSDateFormatter *sRFC3339DateFormatter = nil;
    dispatch_once(&pred, ^{
        sRFC3339DateFormatter            = [[NSDateFormatter alloc] init];
        sRFC3339DateFormatter.locale     = [NSLocale localeWithLocaleIdentifier:@"en_US_POSIX"];
        sRFC3339DateFormatter.dateFormat = @"yyyy-MM-dd'T'HH:mm:ssZZZZZ";
    });

    return sRFC3339DateFormatter;
}

Diesen DateFormatter nutze ich für das endDate bei CreateOrder. Da fällt dann ein String der Form "2020-07-30T09:45:00Z" raus.

Und alle Parameter wandern in die Signatur.

Aber: Das ist APIv2 und funktioniert nicht mehr!

Bearbeitet von cocoahead
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 11 Stunden schrieb fox42:

Bei mir:


2020-07-30T12:00:59+02:00
2020-07-30T12%3A00%3A59%2B02%3A00

Oben der RFC3339 und unten dann URLEncoded, wie es in den Parametern steht.

Kannst du es mal mit 

2020-07-30T12:00:00Z

probieren?

Davon ab: Ich glaube, die Zeit muss immer auf 15 Minuten aligned sein. 12:00:59 ging nicht, 12:00:00 oder 12:15:00 dagegen schon.

Beste Grüße

Peter

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 1 Stunde schrieb cocoahead:

Davon ab: Ich glaube, die Zeit muss immer auf 15 Minuten aligned sein. 12:00:59 ging nicht, 12:00:00 oder 12:15:00 dagegen schon.

Jop, stimmt. Beispiel oben von mir war mit aktueller Uhrzeit nur um das Format zu zeigen :)

2020-07-31 01:15:40,575 INFO  [APIRequester] - Calling create order: https://api.bitcoin.de/v4/btceur/orders with params: end_datetime=2020-08-02T12%3A00%3A00Z&[...]
2020-07-31 01:15:41,534 INFO  [APIRequester] - Server Response: 422
2020-07-31 01:15:41,535 ERROR [APIRequester] - {"errors":[{"message":"Value for field >end_datetime","code":24,"field":"end_datetime"}],"credits":29}

Geht also nicht.. Mal mit +01:00 statt Z:

2020-07-31 01:18:20,978 INFO  [APIRequester] - Calling create order: https://api.bitcoin.de/v4/btceur/orders with params: end_datetime=2020-08-02T12%3A00%3A00%2B01%3A00&[...]
2020-07-31 01:18:21,738 INFO  [APIRequester] - Server Response: 422
2020-07-31 01:18:21,739 ERROR [APIRequester] - {"errors":[{"message":"Express trade is temporary not available","code":56,"field":"payment_option"}],"credits":16}
2020-07-31 01:18:21,740 ERROR [APIRequester] - Server returned HTTP response code: 422 for URL: https://api.bitcoin.de/v4/btceur/orders

Jau.. und jetzt kein Express-Handel.. Mjau. Morgen schau ich noch mal..

Link zu diesem Kommentar
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde Dich hier an.

Jetzt anmelden
×
×
  • Neu erstellen...

Wichtige Information

Wir haben Cookies auf Deinem Gerät platziert. Das hilft uns diese Webseite zu verbessern. Du kannst die Cookie-Einstellungen anpassen, andernfalls gehen wir davon aus, dass Du damit einverstanden bist, weiterzumachen.