PROBLEM: I cannot authorize my connection to ASANA.
Breaking my code to the simplist bits. I used: http://onlinecurl.com/ to mimic what I see at
https://asana.com/developers/documentation/getting-started/authentication#sts=API%20Keys
This is my command.
curl --user 'NWE2MDJqUloubnpCUjh0d3gxVmYydW5BeFlJUER0Smw6' https://app.asana.com/api/1.0/users/me
Original : 5a602jRZ.nzBR8twx1Vf2unAxYIPDtJl
I even used https://www.base64encode.org/ to make sure my base64 was correct, which it is.
Response Header
1 HTTP/1.1 401 Unauthorized
2 Server: nginx
3 Date: Sat, 25 Oct 2014 17:58:23 GMT
4 Content-Type: application/json; charset=UTF-8
5 Transfer-Encoding: chunked
6 Connection: keep-alive
7 X-Asana-Content-String-Length: 41
8 Pragma: no-cache
9 Set-Cookie: TooBusyRedirectCount=0
10 Cache-Control: no-store
11 X-Asana-Preferred-Release-Revision: 20141024_201328_7ebcb21240775f3d5e6038b42ade419530485b76
12 X-Robots-Tag: none
Response Body
1{"errors":[{"message":"Not Authorized"}]}
How can I connect to the service with my Authorization???
Since writing this I have reset my aPIKEY
You do not need to base64-encode the username yourself, curl will do that for you. Also, please be careful of sharing your API key on public forums; these are sensitive credentials that should be treated like usernames and passwords! If that is a real API key I advise you reset it immediately (which you can do through the UI where you discovered it).
There needs to be a content Header
Here is what I did in Google Scripts.
In the site : http://onlinecurl.com/
we would need an extra option in headers for content-type
function getTasksFromAsana() {
api_key = "XXXX";
workspace_id = "WORKSPACE-ID";
// set up HTTPS connection
uri = "https://app.asana.com/api/1.0/users/me";
// set up the request
req={};
req = {
"headers":{ 'content-type': 'application/json','authorization': 'Basic ' + api_key }
}
Logger.log('Get Tasks Asana');
var response = UrlFetchApp.fetch(uri,req);
Logger.log(response.getContentText());
}
Related
I'm trying to follow the documentation "https://developers.google.com/accounts/docs/OAuth_ref" to migrate oAuth to oAuth2 but keep getting an error
In the "APIs & auth" - "Credentials" Section in our API developers console we have 1 Client ID for web application set up along with a number of service account client Ids.
The client Ids appear to be in a format xxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.apps.googleusercontent.com for each client ID that is set up.
If I use the exact Id for the 'client ID for web application' in the format [xxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.apps.googleusercontent.com] then I get an error
{
"error" : "invalid_client"
}
If I use the more generic client ID [ xxxxxxxxxxxx.apps.googleusercontent.com
] then I get the following error
{
"error" : "disabled_client",
"error_description" : "The OAuth client was disabled."
}
Here is my post request from Fiddler
POST https://accounts.google.com/o/oauth2/token HTTP/1.1
Authorization: OAuth realm="",oauth_consumer_key="<consumerKey>",oauth_token="<token>",oauth_timestamp="1400680750",oauth_nonce="6637551",oauth_signature_method="HMAC-SHA1",oauth_signature="I%2FCOsR1BrGQHnqTeyhX4GUrKrv8%3D"
Content-Type: application/x-www-form-urlencoded
Host: accounts.google.com
Content-Length: 151
Expect: 100-continue
Connection: Keep-Alive
grant_type=urn:ietf:params:oauth:grant-type:migration:oauth1&client_id=<clientID>.apps.googleusercontent.com&client_secret={<client_secret>}
Here is the base string I use for oauth_signature
POST&https://accounts.google.com/o/oauth2/token&client_id=<clientID>.apps.googleusercontent.com&client_secret=<clientSecret>&grant_type=urn:ietf:params:oauth:grant-type:migration:oauth1&oauth_consumer_key=<consumerKey>&oauth_nonce=2648138&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1400681371&oauth_token=<token>
Here is the response I get from Google
HTTP/1.1 401 Unauthorized
Content-Type: application/json; charset=utf-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Date: Wed, 21 May 2014 13:59:16 GMT
Content-Disposition: attachment; filename="json.txt"; filename*=UTF-8''json.txt
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Server: GSE
Alternate-Protocol: 443:quic
Transfer-Encoding: chunked
5b
{
"error" : "disabled_client",
"error_description" : "The OAuth client was disabled."
}
0
Any suggestions?
Here a related post: https://groups.google.com/forum/#!topic/google-analytics-data-export-api/yveoPwSVzCQ
As for Owen's suggestion, I am pretty sure the error is not related to oauth1 vs oauth2 client type validation but rather to the provided oauth2 credentials (client id and client secret).
It turns out that the POST body that I was sending to google was incorrect.
Originally I had sent
grant_type=urn:ietf:params:oauth:grant-type:migration:oauth1&client_id=<clientID>.apps.googleusercontent.com&client_secret={<client_secret>}
Note the { } around the client_secret. When I removed these then I no longer got the errors.
Now I can pass in the client_id in the format xxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.apps.googleusercontent.com and the client_secret without { } and I get a sucessful response.
The reason for the other error that I had been receiving was that the client id in the format xxxxxxxxxxxx.apps.googleusercontent.com was an old client_id that had been deleted and was no longer visible on the Google Developer console.
I don't know what I do wrong, but everytime I tried to obtain the token (after user authentication of course), the result is always Invalid grant_type parameter or parameter missing
Possibly related to Box API always returns invalid grant_type parameter on obtaining access token
Here is my fiddler result:
POST https://api.box.com/oauth2/token HTTP/1.1
Host: api.box.com
Content-Length: 157
Expect: 100-continue
Connection: Keep-Alive
grant_type=authorization_code&code=nnqtYcoik7cjtHQYyn3Af8uk4LG3rYYh&client_id=[myclientId]&client_secret=[mysecret]
Result:
HTTP/1.1 400 Bad Request
Server: nginx
Date: Thu, 07 Mar 2013 11:18:36 GMT
Content-Type: application/json
Connection: keep-alive
Set-Cookie: box_visitor_id=5138778bf12a01.27393131; expires=Fri, 07-Mar-2014 11:18:35 GMT; path=/; domain=.box.com
Set-Cookie: country_code=US; expires=Mon, 06-May-2013 11:18:36 GMT; path=/
Cache-Control: no-store
Content-Length: 99
{"error":"invalid_request","error_description":"Invalid grant_type parameter or parameter missing"}
Even following the curl example gives the same error. Any help would be appreciated.
Edit: tried with additional redirect_uri params but still the same error
POST https://api.box.com/oauth2/token HTTP/1.1
Content-Type: application/json; charset=UTF-8
Host: api.box.com
Content-Length: 187
Expect: 100-continue
Connection: Keep-Alive
grant_type=authorization_code&code=R3JxS7UPm8Gjc0y7YLj9qxifdzBYzLOZ&client_id=*****&client_secret=*****&redirect_uri=http://localhost
Result:
HTTP/1.1 400 Bad Request
Server: nginx
Date: Sat, 09 Mar 2013 00:46:38 GMT
Content-Type: application/json
Connection: keep-alive
Set-Cookie: box_visitor_id=513a866ec5cfe0.48604831; expires=Sun, 09-Mar-2014 00:46:38 GMT; path=/; domain=.box.com
Set-Cookie: country_code=US; expires=Wed, 08-May-2013 00:46:38 GMT; path=/
Cache-Control: no-store
Content-Length: 99
{"error":"invalid_request","error_description":"Invalid grant_type parameter or parameter missing"}
Looks like Box requires a correct Content-Type: application/x-www-form-urlencoded request header in addition to properly URL encoding the parameters. The same seems to apply to refresh and revoke requests.
Also, per RFC 6749, the redirect_uri is only
REQUIRED, if the "redirect_uri" parameter was included in the authorization request
as described in Section 4.1.1, and their values MUST be identical.
I was facing a similar issue.
The problem is not with Content-Type.
The issue is with the lifecycle of code you receive.
One key aspect not mentioned in most places is that the code you get on redirect lasts only 30 seconds.
To get the access token and refresh token, you have to make the post request in 30 seconds or less.
If you fail to do that, you get the stated error. I found the info here.
Below code worked for me. Keep in mind, the 30-second rule.
import requests
url = 'https://api.box.com/oauth2/token'
data = [
('grant_type', 'authorization_code'),
('client_id', 'YOUR_CLIENT_ID'),
('client_secret', 'YOUR_CLIENT_SECRET'),
('code', 'XXXXXX'),
]
response = requests.post(url, data=data)
print(response.content)
Hope that helps.
You are missing the redirect URI parameter. Try:
POST https://api.box.com/oauth2/token HTTP/1.1
Host: api.box.com
Content-Length: 157
Expect: 100-continue
Connection: Keep-Alive
grant_type=authorization_code&code=nnqtYcoik7cjtHQYyn3Af8uk4LG3rYYh&client_id=[myclientId]&client_secret=[mysecret]&redirect_uri=[your-redirect-uri]
I have also face same issue implementing oauth2. I have add Content-Type: application/x-www-form-urlencoded. When I add content-type my issue solved.
Check and add valid content-type.
Not sure who might need this in the future but be sure you're sending a POST request to get the access token and not trying to retrieve it by using GET or if you're testing- pasting in the address bar won't work, you need to send a POST request with the data in the BODY and not as query parameter.
Also the code usually lasts for a few seconds, so you need to use it as soon as its sent back.
I am using JBoss 7.1 and have secured my web application with Basic authentication but I want only the first call to require the Basic authentication header, sequent calls should use the jsessionid for authentication. How to accomplish this?
So far I have created a rest servlet enforcing the creation of a session with a call to request.getSession()
#Path("/rest/HelloWorld")
public class HelloWorld {
#GET()
#Produces("text/plain")
public String sayHello(#Context HttpServletResponse response,
#Context HttpServletRequest request) {
HttpSession session = request.getSession();
return "Hello World! " + request.getUserPrincipal().getName();
}
My idea was that any other calls should only require the jsessionid cookie, but when looking in fiddler I see that the first call is behaving as expected. First you get a 401 and the client is re-sending including the basic authorization header and a jsessionid is returned. On the second call the jsessionid cookie is included but I still get an 401 that triggers the client to re-send the Basic authorization header.
This is the returned headers from the successful authenticated first call.
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 01:00:00 CET
Set-Cookie: JSESSIONID=AFDFl2etiUNkn-mpM+DXr3KE; Path=/Test
Content-Type: text/plain
Content-Length: 18
Date: Tue, 29 Jan 2013 09:12:48 GMT
Hello World! test1
when I make a second call the jsessionid is included
GET /Test/index.html HTTP/1.1
Host: cwl-rickard:8080
Cookie: JSESSIONID=AFDFl2etiUNkn-mpM+DXr3KE
and I am getting a 401 enforcing the client to re-send the request including the basic authorization header.
HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 01:00:00 CET
WWW-Authenticate: Basic realm="ApplicationRealm"
Content-Type: text/html;charset=utf-8
Content-Length: 958
Date: Tue, 29 Jan 2013 09:12:48 GMT
Any ideas what I am missing.
In trying to upload a scorm package via the REST API the upload is not working.
PUT /d2l/api/lr/(D2LVERSION: version)/objects/
http://docs.valence.desire2learn.com/res/lor.html
We are always refused based on 403 permission.
Are there any settings I should look at? Also looking for a trace of this working.
As long as the account you are authenticated with can perform the function in the web UI it is expected that the API will also function.
If you are getting keys back from the login process but this call is failing you could try a basic call from the sample such as "whoami". If that works your keys are correct.
If the keys are correct and some GET calls are working, you may need to pass a different method to the signing call in the sdk. (The method is part of the signature).
Here is an example of a working trace. 403 errors often have a body that will provide additional information. Note the security parameters are: x_a,x_b,x_c,x_d,x_t parameters on the call.
PUT http://smihai-7:44459/d2l/api/LR/1.0/objects/?repositoryId=1&x_t=1339183935&x_a=L2Hd9WvDTcyiyu5n2AEgpg&x_c=tfJFhSUaczOeOGqDFPXPq8NSBPj2sOhz4U3RacqWRMY&x_b=TestToken&x_d=BEl7kdCcrjenkpBt9ri5dkt4bdEgCo6xfZDWIpkKctA HTTP/1.1
Accept: application/json, application/xml, text/json, text/x-json, text/javascript, text/xml
User-Agent: RestSharp 101.3.0.0
Host: smihai-7:44459
Content-Type: multipart/form-data; boundary=-----------------------------28947758029299
Content-Length: 1203
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
-------------------------------28947758029299
Content-Disposition: form-data; name="Resource"; filename="Hello World Module.zip"
Content-Type: application/zip
PK???u?h?]G?g???????????Hello World Topic.htmlM??
?#??A??wwo?xH+???h????b
[o+ ????oD??RYW9u??????}J,?q
d2?[!%E|Crj?Wo{34??Xg??s???L?3??+??/?????*??W?W3?Fyb w?>?cR?Zrf?*???b??PK???u?h?N2?T??n?????imsmanifest.xml?V??0?#?Q??m#TI?.b ?XF??5?????k,?$~???6I??Vt??s?=g?x???%7)??J?i4 P?f\???????????DR?W`]?(?WL???g??d???s?,.&i?q????r??jT?kI??E?C?fsmd6-?q??G? .?f?i??4???!??v\???o?7$\jH%
??K??~P??m?`E?¥a)?C????v???6????#???U~?????x???[fe?.?3????~W???;B_?,???V#B?HE???:??q?e???s??_E? 1wK??<R????T??.9YE??SkP`?????*UT??3???j??#'??#2?;?e_c?#g.????}?p?>?c??????\?
????~,u????\s?M*L?U???E??
??????Kzp\E?X#?%\p???\??R
X-????%??C??????7?|??/&?=???h????l?\?\???????P???s??))??Td??K?????{?Y?+????v?gTN??h$?
?E'E?aB?UD????PK-????u?h?]G?g?????????????????????????Hello World Topic.htmlPK-????u?h?N2?T??n???????????????????imsmanifest.xmlPK??????????E????
-------------------------------28947758029299--
And the response is like this:
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store
Pragma: no-cache
Content-Length: 69
Content-Type: application/json; charset=UTF-8
Expires: -1
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
X-XSS-Protection: 0
Date: Fri, 08 Jun 2012 19:32:22 GMT
{"IdentId":4,"Version":1,"ExecutionMessage":null,"ExecutionStatus":0}
Trying for hours to get a request token using Google OAuthGetRequestToken but it always returns "signature_invalid".
For a test I use the oAuth Playground to successfully request the token. Here are the results:
Signature base string
GET&https%3A%2F%2Fwww.google.com%2Faccounts%2FOAuthGetRequestToken&oauth_callback%3Dhttp%253A%252F%252Fgooglecodesamples.com%252Foauth_playground%252Findex.php%26oauth_consumer_key%3Dwww.embeddedanalytics.com%26oauth_nonce%3D56aa884162ed21815a0406725c79cf79%26oauth_signature_method%3DRSA-SHA1%26oauth_timestamp%3D1321417095%26oauth_version%3D1.0%26scope%3Dhttps%253A%252F%252Fwww.google.com%252Fanalytics%252Ffeeds%252F
Request/Response
GET /accounts/OAuthGetRequestToken?scope=https%3A%2F%2Fwww.google.com%2Fanalytics%2Ffeeds%2F HTTP/1.1
Host: www.google.com
Accept: */*
Authorization: OAuth oauth_version="1.0", oauth_nonce="56aa884162ed21815a0406725c79cf79", oauth_timestamp="1321417095", oauth_consumer_key="www.embeddedanalytics.com", oauth_callback="http%3A%2F%2Fgooglecodesamples.com%2Foauth_playground%2Findex.php", oauth_signature_method="RSA-SHA1", oauth_signature="qRtorIaSFaQdOXW1u6eMQlY9LT2j7ThG5kgkcD6rDcW4MIvzluslFgYRNTuRvnaruraNpItjojtgsrK9deYRKoHBGOlU27SsWy6jECxKczcSECl3cVAcjk7dvbywFMDkgi1ZhTZ5Q%2BFoD60HoVQUYnGUbOO0jPXI48LfkiA5ZN4%3D"
HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Date: Wed, 16 Nov 2011 04:18:15 GMT
Expires: Wed, 16 Nov 2011 04:18:15 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Length: 118
Server: GSE
oauth_token=4%2FmO86qZzixayI2NoUc-hewC--D53R&oauth_token_secret=r0PReF9D83w1d6uP0nyQQm9c&oauth_callback_confirmed=true
I am using Fiddler to trace my calls. It returns the Signature base string:
GET&https%3A%2F%2Fwww.google.com%2Faccounts%2FOAuthGetRequestToken&oauth_callback%3Dhttp%253A%252F%252Fgooglecodesamples.com%252Foauth_playground%252Findex.php%26oauth_consumer_key%3Dwww.embeddedanalytics.com%26oauth_nonce%3Dl9Jydzjyzt2fJfM3ltY5yrxxYy2uh1U7%26oauth_signature_method%3DRSA-SHA1%26oauth_timestamp%3D1321417107%26oauth_version%3D1.0%26scope%3Dhttps%253A%252F%252Fwww.google.com%252Fanalytics%252Ffeeds%252F
Aside from the oauth_timestamp and oauth_nonce (which should be different), the base string are pretty much identical.
Anyone know what I am doing wrong?
Update 11/20/2011 Thinking it might be something wrong with my RSA-SHA signing, I have since tried HMAC-SHA. It gives the same results. I thought it might be beneficial to include the Fiddler results (I added carriage returns to have it format better).
GET https://www.google.com/accounts/OAuthGetRequestToken?
scope=https%3A%2F%2Fwww.google.com%2Fanalytics%2Ffeeds%2F HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: OAuth oauth_version="1.0",
oauth_nonce="7C4C900EAACC9C7B62E399A91B81D8DC",
oauth_timestamp="1321845418",
oauth_consumer_key="www.embeddedanalytics.com",
oauth_signature_method="HMAC-SHA1",
oauth_signature="ows%2BbFTNSR8jVZo53rGBB8%2BfwFM%3D"
Host: www.google.com
Accept: */*
Accept-Encoding: identity
Response
HTTP/1.1 400 Bad Request
Content-Type: text/plain; charset=UTF-8
Date: Mon, 21 Nov 2011 03:16:57 GMT
Expires: Mon, 21 Nov 2011 03:16:57 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Length: 358
Server: GSE
signature_invalid
base_string:GET&https%3A%2F%2Fwww.google.com%2Faccounts%2FOAuthGetRequestToken
&oauth_consumer_key%3Dwww.embeddedanalytics.com
%26oauth_nonce%3D7C4C900EAACC9C7B62E399A91B81D8DC
%26oauth_signature_method%3DHMAC-SHA1
%26oauth_timestamp%3D1321845418
%26oauth_version%3D1.0
%26scope%3Dhttps%253A%252F%252Fwww.google.com%252Fanalytics%252Ffeeds%252F
Update 11/24/2011 - I want to add more information based on the answers from #Meysam and #Bob Aman. First, my domain is properly registered with Google. I have been using AuthSub for quite some time now with Target URL path prefix set to http://www.embeddedanalytics.com/authsubsuccess.html. Now when I go to the Manage Domains section it states my oAuth consumer key is www.embeddedanalytics.com. Now perhaps this could be a problem. In the Registration for Web-Based Applications document it states:
If you're using the OAuth interface, this URL (the "Target URL path prefix") must match the value of the oauth_consumer_key parameter
In my case I have a target URL different from my oauth_consumer_key. Could this be a problem? I use www.embeddedanalytics.com as the consumer_key in the playground and it works. I don't want to mess with the target URL because it is currently being used with my AuthSub authorizations.
I assume you have not registered your application domain with Google. Therefore, whatever consumer secret you are using to sign your request (in HMAC-SHA1 method) will be denied unless you provide anonymous as your oauth_consumer_key and consumer secret. This way, Google will recognize you as an unregistered application and will successfully return you a Request Token.
If you use the HMAC-SHA1 method, the Consumer Secret and Token Secret will be used to sign your requests. These two secret parameters are known both to your application, and Google, and act like a secret key in a symmetric encryption algorithm.
In order to use RSA-SHA1 method however, you should have already uploaded your Public Key to the server (Google Server) during the registration process of your application. After that, you will use your Private Key to sign your OAuth requests. In your case, since you have not registered your application, Google is not aware of your Public Key, and therefore using RSA-SHA1 method to sign your requests with an unknown Private Key is of no use.
The first method is usually preferred over the RSA-SHA1 method for performance reasons. (symmetric encryption is faster than asymmetric one)
So this is the way I could successfully get a Request Token in the OAuth Playground:
Set 'oauth_consumer_key' to anonymous (unless you have
registered your application and have a real Consumer Key)
Set 'consumer secret' to anonymous (unless you have registered your
application and have a real Consumer Secret)
Choose https://www.google.com/analytics/feeds/ as the scope of request.
Press 'Request token' button
Result:
GET /accounts/OAuthGetRequestToken?scope=https%3A%2F%2Fwww.google.com%2Fanalytics%2Ffeeds%2F HTTP/1.1
Host: www.google.com
Accept: */*
Authorization: OAuth oauth_version="1.0", oauth_nonce="116d4df85e784f51cf40f0bc3a967883", oauth_timestamp="1322083727", oauth_consumer_key="anonymous", oauth_callback="http%3A%2F%2Fwww.googlecodesamples.com%2Foauth_playground%2Findex.php", oauth_signature_method="HMAC-SHA1", oauth_signature="vVxpbtHlTR%2BJ1yT%2BYS1HOvRzhOs%3D"
HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Date: Wed, 23 Nov 2011 21:28:47 GMT
Expires: Wed, 23 Nov 2011 21:28:47 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Length: 118
Server: GSE
oauth_token=4%2F7E_YtZFHuKFPbuAGuCzyj2AsHcha&oauth_token_secret=NHZBJCj2BPxR2HQZhCTwdq2A&oauth_callback_confirmed=true
Now that you have acquired oauth_token and oauth_token_secret, you can press Authorize button. This will redirect you to the login page of Google (if you are not signed in) and then to the page you grant access to the application. By granting access, you will get back to the callback url in the playground with a verifier code. Pressing 'Access token' button, will get you the access token:
GET /accounts/OAuthGetAccessToken HTTP/1.1
Host: www.google.com
Accept: */*
Authorization: OAuth oauth_version="1.0", oauth_nonce="c222a88cc9f027430b239f4cc6f3f154", oauth_timestamp="1322084080", oauth_consumer_key="anonymous", oauth_verifier="TA6vWcDJC51A9YwMNfmUzmUQ", oauth_token="4%2F7E_YtZFHuKFPbuAGuCzyj2AsHcha", oauth_signature_method="HMAC-SHA1", oauth_signature="q9M%2BjeHNxB2ONPd1DPMn6GriUC8%3D"
HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Date: Wed, 23 Nov 2011 21:34:40 GMT
Expires: Wed, 23 Nov 2011 21:34:40 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Length: 103
Server: GSE
oauth_token=1%2Fxy49iwSQEcqSDbo3cKO-UuPLqvt9qKFit9vaLqR6P-M&oauth_token_secret=IJWB1CVSQfYJJPrf9jXv6SS8
*Note: One time, I got the signature_invalid response too, even though I had entered anonymous credentials. But after trying again and pressing 'Request token' button one or two more times I made it. I think this should be due to how nonce and timestamp parameters work to sign the request. This could be the cause of problem. Read this article for more info.
Further reading:
Managing the OAuth key and secret
Registration for Web-Based Applications
Googler here. Haven't fielded OAuth 1 questions in a long time because everyone's moving to OAuth 2 (and you should too) but I'll try to go through the usual suspects on invalid signature errors:
Your server's clock may be wrong. There's a timestamp component and it needs to match ours pretty closely. Try updating your clock against one of the major reference time servers. This happens, but it's an uncommon issue.
Depending on how low-level the OAuth client you're using is, you may have forgotten to supply part of the key used to generate the signature. The key has two pieces, colon-separated, IIRC. In some parts of the protocol, only one half is needed, but for other parts of the protocol, you need both. I've seen cases where someone kept supplying only the first half when both were needed. Actually, I think I made this mistake myself a couple times.
Probably not an issue in your case, because you haven't even gotten past the request token, but OAuth 1 requires you to sign the URI query parameters. Failure to do this will cause the signature base strings to mismatch, thus causing the signature to be invalid.
By far the most common issue is improper encoding. This usually gets expressed as signatures that work sometimes, but fail other times, because sometimes you get lucky and nothing needs to get encoded. I suspect this is what #Meysam ran into based on his comment that he pressed the button a few more times and suddenly it worked.
By the way, if you have to use OAuth 1, you should be using HMAC-SHA1 unless you've got a really good reason to do RSA-SHA1.