I am a bit stuck in authenticating my app and get an access token, when following this instructions: http://developers.flattr.net/v2/
Step 1, Authenticate works fine. I get back the code, and my app is listed in my Settings/Applications with the correct scope.
Then I try to get the access token via the following curl command:
curl -v --user MY_KEY:MY_SECRET -H "Content-Type: application/json"\
-X POST -d '{"grant_type": "authorization_code",\
"redirect_uri": "http://localhost/", "code": "MY_CODE"}'\
https://flattr.com/oauth/token
Unfortunately I always get "invalid_request"
< HTTP/1.1 400 Bad Request
< Strict-Transport-Security: max-age=500
< Set-Cookie: PHPSESSID=d9972s9r5a7t4p0ch4chc4dqh2; path=/; domain=.flattr.com; HttpOnly
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store
< Pragma: no-cache
< Content-Type: application/json; charset=utf-8
< Content-Length: 291
< Connection: close
< Date: Wed, 16 Nov 2011 22:38:30 GMT
< Server: lighttpd
<
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
{"error":"invalid_request","error_description":"The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats a parameter, includes multiple credentials, utilizes more than one mechanism for authenticating the client, or is otherwise malformed."}
Thanks!
I found a bug in the process and it is now smashed. Should be working smooth if you try the request again!
Related
I would like to automate chrome extension deployment and followed this guide for the most part: https://developer.chrome.com/webstore/using_webstore_api. I created a project in my developer console, activated the Chrome Web Store API. Next step is creating the right credentials. There are three different ones, when i let google help me choose it tells me that API-key is just fine to use for this API, so i did.
My question: How can i use this API-key to make API calls? I tried to include the key in the params as pointed out in the docs but that doesn't work. If this is the wrong approach i really don't understand, that these sort of authentication is suggested by the developer console.
As i try to automate things on a build server without using chrome or some other browser i cannot really use OAuth credentials.
curl \
-H "x-goog-api-version: 2" \
-H "Content-Length: 0" \
-H "Expect:" \
-X GET \
-v \
"https://www.googleapis.com/chromewebstore/v1.1/items/ITEM_ID?projection=draft&key=API_KEY"
results in
https://www.googleapis.com/chromewebstore/v1.1/items/ITEM_ID\?projection\=draft\&key\=API_KEY
* Trying 172.217.17.234...
* Connected to www.googleapis.com (172.217.17.234) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: *.googleapis.com
* Server certificate: Google Internet Authority G2
* Server certificate: GeoTrust Global CA
> GET /chromewebstore/v1.1/items/ITEM_ID?projection=draft&key=API_KEY HTTP/1.1
> Host: www.googleapis.com
> User-Agent: curl/7.43.0
> Accept: */*
> x-goog-api-version: 2
> Content-Length: 0
>
< HTTP/1.1 401 Unauthorized
< Vary: X-Origin
< WWW-Authenticate: Bearer realm="https://accounts.google.com/"
< Content-Type: application/json; charset=UTF-8
< Date: Thu, 15 Sep 2016 14:14:18 GMT
< Expires: Thu, 15 Sep 2016 14:14:18 GMT
< Cache-Control: private, max-age=0
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< Server: GSE
< Alt-Svc: quic=":443"; ma=2592000; v="36,35,34,33,32"
< Accept-Ranges: none
< Vary: Origin,Accept-Encoding
< Transfer-Encoding: chunked
<
* Connection #0 to host www.googleapis.com left intact
{"error":{"errors":[{"domain":"global","reason":"required","message":"Login Required","locationType":"header","location":"Authorization"}],"code":401,"message":"Login Required"}}
I also tried to set it as header but neither of these worked.
Per my understanding:
the Accept header is used by HTTP clients to tell the server what content types they'll accept. The server will then send back a response, which will include a Content-Type header telling the client what the content type of the returned content actually is.
With this understanding, I tried the following:
curl -X GET -H "Accept: application/xml" http://www.google.com -v
* About to connect() to www.google.com port 80 (#0)
* Trying 173.194.33.81...
* connected
* Connected to www.google.com (173.194.33.81) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8y zlib/1.2.5
> Host: www.google.com
> Accept: application/xml
>
< HTTP/1.1 200 OK
< Date: Tue, 02 Sep 2014 17:58:05 GMT
< Expires: -1
< Cache-Control: private, max-age=0
< Content-Type: text/html; charset=ISO-8859-1
< Set-Cookie: PREF=ID=5c30672b67a74789:FF=0:TM=1409680685:LM=1409680685:S=PsGclk3vR4HWjann; expires=Thu, 01-Sep-2016 17:58:05 GMT; path=/; domain=.google.com
< Set-Cookie: NID=67=rPuxpwUu5UNuapzCdbD5iwVyjjC9TzP_Ado29h3ucjEq4A_2qkSM4nQM3RO02rfyuHmrh-hvmwmgFCmOvISttFfHv06f8ay4_6Gl4pXRjqxihNhJSGbvujjDRzaSibfy; expires=Wed, 04-Mar-2015 17:58:05 GMT; path=/; domain=.google.com; HttpOnly
< P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
< Server: gws
< X-XSS-Protection: 1; mode=block
< X-Frame-Options: SAMEORIGIN
< Alternate-Protocol: 80:quic
< Transfer-Encoding: chunked
<
<!doctype html><html itemscope="" itemtype="http://schema.org/WebPage" lang="en"><
As you can notice in the response, I am sent Content-Type: text/html; charset=ISO-8859-1 which is not what I asked for?
why does a different representation (HTML in this case) is sent, although I asked for xml?
Thanks
From RFC 2616:
If an Accept header field is present,
and if the server cannot send a response which is acceptable
according to the combined Accept field value, then the server SHOULD
send a 406 (not acceptable) response.
Here, "should" means that Google aren't actually obliged to throw a 406 error. But since you're receiving an HTML response, it has effectively the same meaning.
By registering your application you can increase your rate limit for GitHub's API from 60 to 5000 requests[1]. You don't have to use OAuth and can simply pass you're client ID and secret in the URL to have GitHub recognize your application[2]. But when I curl the rate limit check:
curl -i https://api.github.com/ratelimit?client_id=xxx&client_secret=yyy
The following is returned:
HTTP/1.1 200 OK
Server: GitHub.com
Date: Sat, 13 Jul 2013 01:53:50 GMT
Content-Type: application/json; charset=utf-8
Status: 200 OK
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 51
X-RateLimit-Reset: 1373683093
X-GitHub-Media-Type: github.beta
X-Content-Type-Options: nosniff
Content-Length: 55
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: ETag, Link, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes
Access-Control-Allow-Origin: *
ETag: "[redacted]"
Cache-Control: max-age=0, private, must-revalidate
Vary: Accept-Encoding
{"rate":{"limit":60,"remaining":51,"reset":1373683093}}
Does anyone know what I'm doing wrong? Do I really have to use the full OAuth?
Putting the URL in quotes when running the command fixed the problem.
It's worth noting that you can also register "Personal Access Tokens" from the Applications menu option inside GitHub. This gives you a token with the increased 5,000 API calls/hour without having to do the OAuth dance.
I'm planning on using CouchDB's built-in cookie authentication for my app (note that this isn't a CouchApp, I'm using a web server between my client and db).
So when a user first logs in with their credentials:
Credentials are sent to CouchDB from web client via web server
CouchDB authenticates credentials and returns a Set-Cookie header
This header is sent to the web client and means that all subsequent requests for database operations just pass on the Cookie header to CouchDB via the web server.
Whilst I've been able to ascertain that:
You can keep using [the cookie] token for 10 minutes by default. After 10 minutes you need to authenticate your user again. The token lifetime can be configured with the timeout (in seconds) setting in the couch_httpd_auth configuration section.
It isn't clear to me if this 10 minute period is (or can be set to be) a sliding window.
By this I mean; if the user continues to use the application for the whole 10 minutes (sending the cookie along on each request), will the cookie automatically be re-set (in a similar way to FormsAuthentication cookies in .NET) until a period of in-activity for 10 minutes?
References used
http://guide.couchdb.org/draft/security.html#cookies
http://wiki.apache.org/couchdb/Security_Features_Overview
For a browser, the (configurable) 10-minute period is a sliding window. Every time CouchDB responds to a request, it will update the cookie to a new value, effectively refreshing the login.
For a client, you must remember to reset the cookie value when you see a Set-Cookie header (or pass it through to your own client in your case).
For example, I have a short timeout (30 seconds):
$ curl http://admin:admin#localhost:5984/_config/couch_httpd_auth/timeout
"30"
Next I will:
Log in
Wait a little while
Check my session with the cookie, before the timeout
Wait for the timeout
Check my session with the cookie again, after the timeout
(Quickly) check my session with the new cookie CouchDB set in step 3
Notice that the first confirmation has {"name":"me"} (I am logged in); the second has {"name":null} (I am logged out); but the third has {"name":"me"} again (I am still logged in due to using the updated cookie).
$ curl -X POST -i localhost:5984/_session -d name=me -d password=secret
HTTP/1.1 200 OK
Set-Cookie: AuthSession=bWU6NEY5QjQ3QTA6Ao6zetUZUxkno37ULd2qdRRjmsc; Version=1; Path=/; HttpOnly
Server: CouchDB/1.2.0 (Erlang OTP/R15B)
Date: Sat, 28 Apr 2012 01:28:00 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 35
Cache-Control: must-revalidate
{"ok":true,"name":"me","roles":[]}
$ sleep 20
$ curl -i localhost:5984/_session -H Cookie:AuthSession=bWU6NEY5QjQ3QTA6Ao6zetUZUxkno37ULd2qdRRjmsc
HTTP/1.1 200 OK
Set-Cookie: AuthSession=bWU6NEY5QjQ3QkM6WonDdsAdO8p7QUlLWCZQXVAfcvU; Version=1; Path=/; HttpOnly
Server: CouchDB/1.2.0 (Erlang OTP/R15B)
Date: Sat, 28 Apr 2012 01:28:28 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 165
Cache-Control: must-revalidate
{"ok":true,"userCtx":{"name":"me","roles":[]},"info":{"authentication_db":"_users","authentication_handlers":["oauth","cookie","default"],"authenticated":"cookie"}}
$ sleep 10
$ curl -i localhost:5984/_session -H Cookie:AuthSession=bWU6NEY5QjQ3QTA6Ao6zetUZUxkno37ULd2qdRRjmsc
HTTP/1.1 200 OK
Server: CouchDB/1.2.0 (Erlang OTP/R15B)
Date: Sat, 28 Apr 2012 01:28:43 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 140
Cache-Control: must-revalidate
{"ok":true,"userCtx":{"name":null,"roles":[]},"info":{"authentication_db":"_users","authentication_handlers":["oauth","cookie","default"]}}
$ curl -i localhost:5984/_session -H Cookie:AuthSession=bWU6NEY5QjQ3QkM6WonDdsAdO8p7QUlLWCZQXVAfcvU
HTTP/1.1 200 OK
Set-Cookie: AuthSession=bWU6NEY5QjQ3RDA69pqrNVd-ClZ7_v4SkcghdZRRhCs; Version=1; Path=/; HttpOnly
Server: CouchDB/1.2.0 (Erlang OTP/R15B)
Date: Sat, 28 Apr 2012 01:28:48 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 165
Cache-Control: must-revalidate
{"ok":true,"userCtx":{"name":"me","roles":[]},"info":{"authentication_db":"_users","authentication_handlers":["oauth","cookie","default"],"authenticated":"cookie"}}
In CouchDB 1.2.0 and later, you can set _config/couch_httpd_auth/allow_persistent_cookies to "true" and it makes things easier to see. The cookie will have an obvious "Expires" flag which you can see is always set to the current time plus your timeout value.
I'm building a JSON API on top of devise in order to be able to communicate from mobile devices.
So far so good, I am able to create a user account, to get an auth_token. But when I am trying to perform a PUT request, I get some problems , for example the update action for the user. The behavior is really stange, and I can't figure out what is wrong.
curl -i -H "Accept: application/json" 'http://localhost:3000/users' -X PUT -d 'auth_token=A830ALUv7ztTdSfl3qxFgi13BJpEf6VzNYe4yk8rEhVxbYYlOc0YMtTGMxkz&user[name]=plop'
Returns
HTTP/1.1 401 Unauthorized
Connection: close
Date: Wed, 02 Mar 2011 06:41:29 GMT
Content-Type: application/json; charset=utf-8
Cache-Control: no-cache
X-UA-Compatible: IE=Edge
X-Runtime: 0.157513
Transfer-Encoding: chunked
{"error":"You need to sign in or sign up before continuing."}
On the logs on the server i get this .... Really strange.
Started PUT "/users" for 127.0.0.1 at 2011-03-01 22:41:29 -0800
Processing by Users::RegistrationsController#update as JSON
Parameters: {"auth_token"=>"A830ALUv7ztTdSfl3qxFgi13BJpEf6VzNYe4yk8rEhVxbYYlOc0YMtTGMxkz", "user"=>{"name"=>"plop"}}
Completed in 1ms
Whereas if I modify just the name of the post value from user to users form example, the request works
HTTP/1.1 200 OK
Connection: close
Date: Wed, 02 Mar 2011 06:43:30 GMT
Content-Type: application/json; charset=utf-8
ETag: "5e1311709931861e469ce2c8a3b2d0e6"
Cache-Control: max-age=0, private, must-revalidate
X-UA-Compatible: IE=Edge
Set-Cookie: _u_session=BAh7CEkiGXdhcmRlbi51c2VyLnVzZXIua2V5BjoGRVRbCEkiCVVzZXIGOwBGWwZvOhNCU09OOjpPYmplY3RJZAY6CkBkYXRhWxFpUGGaQG%2FaX1pAfhpAaRpAexpAGkAaQ1JIiIkMmEkMTAkMDVBeDczV29UdVFEZHQxZ1JjN0NXdQY7AFRJjW9uRGlzcGF0Y2g6OkZsYXNoOjpGbGFzaEhhc2h7BjoLbm90aWNlSSIrWW91IHVwZGF0ZWQgeW91ciBhY2NvdW50IHN1Y2Nlc3NmdWxseS4GOwBUBjoKQHVzZWRvOghTZXQGOgpAaGFzaHsASSIPc2Vzc2lvbl9pZAY7AEYiJTcyNmIyZjJiODZhOTBiNjUwZDlhZmIwMzA5MTRkMTlm--0e15953fd7edecb0e08255349c4e55f1eddc8d81; path=/; HttpOnly
X-Runtime: 0.162436
Transfer-Encoding: chunked
{"redirect":"/","status":"ok"}
I precise that, even without my code(For the API) I can't perform this request !!!!
Thanks for your help !
I don't believe that Devise handles JSON calls, there is an open issue on github that is scheduled for the 1.3 release to address this problem.