看起來您正在向該URL發出GET請求。 OAuth2令牌端點僅支持POST請求。此外,參數必須在請求正文中發送,而不是作爲查詢字符串的一部分。使用curl命令行實用程序,這將是這樣的:
curl -X POST -D - https://api.soundcloud.com/oauth2/token -F'client_id=YOUR_CLIENT_ID' \
-F'client_secret=YOUR_CLIENT_SECRET' -F'grant_type=password' \
-F'username=YOUR_USERNAME' -F'password=YOUR_PASSWORD'
從技術上講,我們應該代替指出來發送回一個405一個404的,我會提交錯誤的是,謝謝。
你絕對不想分發你的客戶端憑證。您的客戶端ID和客戶端密鑰將您的應用程序唯一標識爲SoundCloud。如果您要分發這些內容,則任何其他應用程序開發人員都可以使用這些值來創建一個看起來像您的應用程序。如果其中一個應用程序違反了SoundCloud的服務條款,我們將不得不切斷對客戶端ID的訪問,從而禁用您的應用程序。
此外,雖然支持用戶憑證流程,但只有在更受歡迎的授權碼流程不可用時才推薦使用。授權碼流對大多數用戶來說是比較熟悉的。它允許您讓用戶授權訪問您的應用程序,而不需要他們爲您的應用程序提供憑據。不建議使用用戶憑證流的主要原因是通過Facebook Connect註冊的用戶沒有密碼,因此無法將您的應用連接到他們的SoundCloud帳戶。
對於桌面/移動應用程序,您可以在使用自定義協議方案(例如myapp://)的應用程序註冊過程中指定重定向URI,這會將控制權交還給您的應用程序。確切的做法是從平臺變爲平臺。這意味着您不必擁有正在運行的Web服務來調解身份驗證流程。
讓我知道如果您有任何後續問題,我會編輯我的答案來詳細說明。希望有所幫助!
謝謝保羅!我將調查libcurl需要什麼來實現這一點。 關於「祕密」身份證......它是一個開放源碼程序,因此除了發佈它之外別無選擇。當然,應用程序打破Soundcloud TOS是不可能的,因爲經過身份驗證的用戶是罪魁禍首?除了將聲音歸因於應用之外,爲什麼它很重要? 最後,關於授權:我打算使用「授權碼流」,但我不明白它在桌面應用程序的上下文中。它似乎需要第三方服務器作爲某種中介。希望我只是困惑。 – user1313170 2012-04-05 16:49:11
如果您將其作爲開源代碼發佈,則應該將客戶端憑據保留出去,並使應用程序註冊成爲安裝/設置過程的一部分。麻煩的是,你放棄了憑證。舉例來說,如果一個有惡意意圖的開發者想要創建一個可以做一些有害事情的應用程序,他們可以使用您的應用程序憑證並「構成」您的應用程序。用戶會認爲他們正在驗證您的應用程序。底線,共享憑證打破了信任關係。泄露客戶機密的應用幾乎肯定會被停用。 – 2012-04-05 20:42:19
修改我的答案,以包含有關在桌面應用程序中使用Auth Code Flow的詳細信息。還提到了爲什麼不推薦User Cred Flow。另外,如果你發現我的答案有幫助,那麼「接受」它是個好習慣:-)希望有所幫助。如果您有任何其他問題,請告訴我。 – 2012-04-05 20:46:40