Streamanzeige für die Frontpage

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Hab mir das vorhin nochmal etwas durchgelesen. Die redirect_uri gibt einem scheinbar lediglich die Möglichkeit die Authorisierung für den Client auf einer Custom Page zu machen. Sieht dann so aus: justintv.github.io/twitch-js-sdk/example.html also um auf mehr Daten des Nutzers zugreifen zu können. Im FAQ steht dazu nur folgendes:
      If I'm including an OAuth token, do I need to include a Client-ID?
      If you are passing in an OAuth token, we will figure out the Client-ID for you.
      Problem an der Sache ist. Man muss sich halt als User authentifizieren .. und das ist ja nicht was wir auf der Frontpage wollen.

      Naja vielleicht verschliessen sie die API inkrementell und fügen eine Funktion gegen Missbrauch ein. Sie haben ja damit sehr lange gewartet und die client_id war scheinbar schon sehr früh in der API drin aber wurde aber nicht genutzt/verlangt. Wie es aussieht kann man es erstmal so lassen.

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von subarashii ()


    • twiclo
      3d

      Would I be dumb for just leaving the client-ID in my source code for everyone to see? Or should I require everyone to get their own client ID and make my program use that specific ID for requests? What could happen if someones uses my client-ID incorrectly?



      TournyMasterBotTwitch Staff
      3d

      Client-Id is public, client secret is private. You don't need to protect the client id.

      ---

      Also ja, ist ein public key. Wobei ich mich frage, warum ich mir dann selber eine erstellt habe.
      Es könnte ja auch *jemand* einfach eine generische Client-ID erzeugen die alle Leute der Welt nutzen und der Client ist nicht mehr nachvollziehbar und die Twitch API im Endeffekt public.
      Dann könnte man auch Quotas nicht sinnvoll durchsetzen... klaue ich mir halt jeden Tag eine neue Client-ID und den Schaden hat jemand anderes.

      Fänds sinnvoller wenn die API für normale Aufrufe ohne Client-ID ist und nur für interessante Sachen eine Client-ID erfordern.
      Ansonsten würde ich als fauler/schlecht gelaunter Developer einfach komplett Curl auf 300 Streams machen und dann parsen... kostet im Endeffekt nur Twitch mehr CPU und Traffic.

      ---

      Wie dem auch sei, @Phils3r kannst du das gleiche im Forum irgendwie einbinden?
      Vllt als Gitter oben rechts, oder als Menüpunkt/Popup?
    • hlcws schrieb:

      Also ja, ist ein public key. Wobei ich mich frage, warum ich mir dann selber eine erstellt habe.Es könnte ja auch *jemand* einfach eine generische Client-ID erzeugen die alle Leute der Welt nutzen und der Client ist nicht mehr nachvollziehbar und die Twitch API im Endeffekt public.
      Dann könnte man auch Quotas nicht sinnvoll durchsetzen... klaue ich mir halt jeden Tag eine neue Client-ID und den Schaden hat jemand anderes.


      Fänds sinnvoller wenn die API für normale Aufrufe ohne Client-ID ist und nur für interessante Sachen eine Client-ID erfordern.
      Ansonsten würde ich als fauler/schlecht gelaunter Developer einfach komplett Curl auf 300 Streams machen und dann parsen... kostet im Endeffekt nur Twitch mehr CPU und Traffic.
      This :D Es ist bonkers was sie da gerade machen.. aber was solls. Wenn die ID kein Problem ist so be it. Gute Praxis sieht anders aus (oder mir entzieht sich gerade das größere Ziel an der Stelle :dance: )
    • Not meaningless. At its core, it is a tracking mechanism. It allows us to identify and find any offending applications, contact them, see if there is abuse (or an accidentally shipped bug, which happened about a month ago), and help the application get into a good state. It isn't meant to be something we track and immediately swing the banhammer the minute you start hammering the APIs. It is a point of data used to inform our research and outreach.
      aka... einfach mal eingeführt und gucken was passiert.
    • Aww shieet lese jetzt erst alles ab post 21.

      Mir gefällt diese Client-ID Geschichte nicht.

      Ich wäre für eine Serverseitige Php Abfrage, die die Ergebnisse cached und eine Clientseitige Ajax Abfrage, die von dem Cache die neusten Infos pullt.
      Daraus würde größerer Traffic für HE resultieren.
      Summer 2011.
      A Nightmare awaits me.
      I am being recalled to Hardedge Headquaters.
      Do i have to go back to this hell again ?
      JAAAHHHR

    • betz0r
      4d

      I guess @hlcws meant that anybody could use any valid clientID in his hands to make api calls with this clientID in header, lets say an Android app runs without any authentication some api calls clientsided with an 3rd party clientID in header.
      this 3rd party clientID can not be protected from this kind of abuse, and i guerss thats what @hlcws is pointing at.
      Reply


      DallasNChainsTwitch Staff
      4d

      That's how I read it, too and how I framed my response. Specifically the part about seeing if there is abuse. If we see an instance of abuse, we can work with the developer to identify and move forward. The alternative here is that we require an OAuth token for every API call. If it becomes a problem, we will work toward addressing it.

      ---

      Nur leere Phrasen. Aka wenn meine Client-ID abused wird habe ich den Ärger und muss sie am Ende wahrscheinlich neu generieren und meine App neu ausrollen...