I am trying to build a PayPal sandbox platform with JavaScript, but unfortunately I did not find any working (at least for me) content from PayPal for setting up a platform app with vanilla JavaScript.
I used this PayPal guide to integrate the following code:
<!-- Replace "test" with your own sandbox Business account app client ID -->
<script src="https://www.paypal.com/sdk/js?client-id=test¤cy=USD"></script>
<!-- Set up a container element for the button -->
<div id="paypal-button-container"></div>
<script>
paypal.Buttons({
// Sets up the transaction when a payment button is clicked
createOrder: (data, actions) => {
return actions.order.create({
purchase_units: [{
amount: {
value: '77.44' // Can also reference a variable or function
}
}]
});
},
// Finalize the transaction after payer approval
onApprove: (data, actions) => {
return actions.order.capture().then(function(orderData) {
// Successful capture! For dev/demo purposes:
console.log('Capture result', orderData, JSON.stringify(orderData, null, 2));
const transaction = orderData.purchase_units[0].payments.captures[0];
alert(`Transaction ${transaction.status}: ${transaction.id}\n\nSee console for all available details`);
// When ready to go live, remove the alert and show a success message within this page. For example:
// const element = document.getElementById('paypal-button-container');
// element.innerHTML = '<h3>Thank you for your payment!</h3>';
// Or go to another URL: actions.redirect('thank_you.html');
});
}
}).render('#paypal-button-container');
</script>
It was working for "simple" payment, when I directly put in the client id of the person receiving the money, but I would like to use this as some kind of platform/marketplace, where different people offer stuff and receive their money directly...
I found this configuration guide to referre to an merchant within the platform and changed
<script src="https://www.paypal.com/sdk/js?client-id=test¤cy=USD"></script>
to
<script src="https://www.paypal.com/sdk/js?client-id=YOUR_CLIENT_ID&merchant-id=XXX"></script>
and I used the client sandbox id of the platform (create with PayPal) and added the id of the account, which should receive the money. But since then the payment process is not working anymore and I receive a bunch of errors:
POST https://www.sandbox.paypal.com/v2/checkout/orders/1N412585WU345820U/capture 403
Here and according to PayPal API responsesit says, that my platform needs approval, but according to the info box inside my PayPal platform app it says, that sandbox apps do not need approval to run:
POST https://www.sandbox.paypal.com/smart/api/order/1N412585WU345820U/capture 500
According to PayPal API responses this seems to be a PayPal side error, but I believe in my case it could be solved within the "main problem" (whatever it is...)
Uncaught Error: Api: /smart/api/order/1N412585WU345820U/capture returned status code: 500 (Corr ID: 3d42a7056c067)
According to PayPal API responses this seems to be an internal server error by PayPal as well
It still could be that I am using the false JavaScript snippet to integrate a PayPay Platform, but so far I found nothing different, that appeared to me to suit better...
Update I 13.04.
This is the exact code block I am currently trying to get to work:
<script src="https://www.paypal.com/sdk/js?client-id=ARoShWzmlqdngxfJ31ly7ZADrsyWU3Fa3fhlOJF0mJXdpIaZ5z99R7VkQuMEb_4Z_azlHfuo7Mk4k5qK&merchant-id=<?= $paypal ?>¤cy=EUR"></script>
<div id="paypal-button-container"></div>
<script>
paypal.Buttons({
createOrder: (data, actions) => {
return actions.order.create({
purchase_units: [{
amount: {
value: '<?= $amount ?>' // Can also reference a variable or function
}
}]
});
},
onApprove: (data, actions) => {
return actions.order.capture().then(function(orderData) {
console.log('Capture result', orderData, JSON.stringify(orderData, null, 2));
const transaction = orderData.purchase_units[0].payments.captures[0];
actions.redirect('http://localhost/exit.php');
});
}
}).render('#paypal-button-container');
</script>
I fetch the PHP variables from my database, where all information is stored. Also tried to add the IDs manually instead of PHP variables, but did not change anything.
BTW: If I click the PayPal-Button to pay, the second window to log into PayPal opens up and I can log in with one of my sandbox accounts, also the price is currect. Just after trying to complete the payment I am not forwarded to http://localhost/exit.php, but receive the below erros instead.
Here is an image of all the logs, which appear. Just recognized a time out error as the first error, but not sure, if this triggers the problem:
Update II 13.04.
As mentioned in this comment I tried to onboard the sellers via the Partner Referrals API using this sample from PayPal. I first created an access token and then wanted to generate a singup link with this access token. But instead of the desired response I receive an INVALID_REQUEST message inside my command prompt while trying to generate the singup link:
{"name":"INVALID_REQUEST","message":"Request is not well-formed, syntactically incorrect, or violates schema.","debug_id":"b54a8fd49ab4c","information_link":"","details":[{"issue":"INVALID_PARAMETER_SYNTAX","description":"Referral data is not a valid json object."}],"links":[]}* Connection #0 to host api-m.sandbox.paypal.com left intact
I search on Google, but did not really find helpful responses. Also the information_link-field is unfortunately empty.
This was my request:
curl -v -X POST https://api-m.sandbox.paypal.com/v2/customer/partner-referrals \ -H "Content-Type: application/json" \ -H "Authorization: Bearer A21AAJAr6XCnxUwsXGpH_Hv55XrrDh-wct-FnmSFQzFrY4mNHatkD--IaHXlUSOUBipsItfdxb56S371AdrEK7gFmcHEXEiJA" \ -d '{"tracking_id": "PayPal-ID","operations": [{"operation": "API_INTEGRATION", "api_integration_preference": {"rest_api_integration": {"integration_method": "PAYPAL","integration_type": "THIRD_PARTY","third_party_details": {"features": ["PAYMENT","REFUND"]}}}}],"products": ["EXPRESS_CHECKOUT"],"legal_consents": [{"type": "SHARE_DATA_CONSENT","granted": true}]}'
And here is the response I got:
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying 151.101.1.35:443...
* Connected to api-m.sandbox.paypal.com (151.101.1.35) port 443 (#0)
* schannel: disabled automatic use of client certificate
* schannel: ALPN, offering http/1.1
* schannel: ALPN, server accepted to use http/1.1
> POST /v2/customer/partner-referrals HTTP/1.1
> Host: api-m.sandbox.paypal.com
> User-Agent: curl/7.79.1
> Accept: */*
> Content-Type: application/json
> Authorization: Bearer A21AAJAr6XCnxUwsXGpH_Hv55XrrDh-wct-FnmSFQzFrY4mNHatkD--IaHXlUSOUBipsItfdxb56S371AdrEK7gFmcHEXEiJA
> Content-Length: 14
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 400 Bad Request
< Connection: keep-alive
< Content-Length: 278
< Content-Type: application/json;charset=utf-8
< Server: nginx/1.18.0 (Ubuntu)
< Cache-Control: max-age=0, no-cache, no-store, must-revalidate
< Etag: W/"116-GOos19pXDvjfMGG/lkQZOQx3ysM"
< Paypal-Debug-Id: b54a8fd49ab4c
< Set-Cookie: ts_c=vr%3D2321e53c1800a609769dd99dffff68d4%26vt%3D2321e53c1800a609769dd99dffff68d5; Domain=.paypal.com; Path=/; Expires=Sun, 13 Apr 2025 07:00:42 GMT; Secure; SameSite=None; HttpOnly
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< Accept-Ranges: bytes
< Via: 1.1 varnish, 1.1 varnish
< Edge-Control: max-age=0
< Date: Wed, 13 Apr 2022 13:34:25 GMT
< X-Served-By: cache-fra19126-FRA, cache-muc13976-MUC
< X-Cache: MISS, MISS
< X-Cache-Hits: 0, 0
< X-Timer: S1649856865.498776,VS0,VE171
<
{"name":"INVALID_REQUEST","message":"Request is not well-formed, syntactically incorrect, or violates schema.","debug_id":"b54a8fd49ab4c","information_link":"","details":[{"issue":"INVALID_PARAMETER_SYNTAX","description":"Referral data is not a valid json object."}],"links":[]}* Connection #0 to host api-m.sandbox.paypal.com left intact
Note: Unnecessary use of -X or --request, POST is already inferred.
* Could not resolve host: \
* Closing connection 1
curl: (6) Could not resolve host: \
Note: Unnecessary use of -X or --request, POST is already inferred.
* Could not resolve host: \
* Closing connection 2
curl: (6) Could not resolve host: \
Note: Unnecessary use of -X or --request, POST is already inferred.
* Could not resolve host: \
* Closing connection 3
curl: (6) Could not resolve host: \
Note: Unnecessary use of -X or --request, POST is already inferred.
* Closing connection -1
curl: (3) URL using bad/illegal format or missing URL
curl: (3) bad range specification in URL position 2:
[{operation:
^
Solution
Had to onboard seller first like Preston PHX mentioned in the comments using the cUrl commands from the PayPal documentation. My code from Update II 13.04. was correct. It just happend, that it got cut off inside the command prompt. So using Postman solved the issue and everything is now working!
The 500 error is not relevant, and only occurring because of a fallback attempt after the 403.
The reason for the 403 may be various, but if you are including a merchant-id on the SDK line then there should also be a payee object with a merchant_id key with that value in the order creation. See the orders create API reference for details.
Ensure the REST APP with the client-id you are using has the appropriate permissions. Changes to permissions may take up to 9 hours if the existing access token is cached, but you can also create a new app.
Related
I have got Apache2 Installed and Python working.
I am having a problem though. I have two pages.
One a Python Page and the other an Html Page with JQuery
Can someone please tell me how I can get my ajax post to work correctly.
<html>
<head>
</head>
<body>
<script>
$(function()
{
alert('Im going to start processing');
$.ajax({
url: "saveList.py",
type: "post",
data: {'param':{"hello":"world"}},
dataType: "application/json",
success : function(response)
{
alert(response);
}
});
});
</script>
</body>
</html>
And the Python Code
import sys
import json
def index(req):
result = {'success':'true','message':'The Command Completed Successfully'};
data = sys.stdin.read();
myjson = json.loads(data);
return str(myjson);
OK, let's move to your updated question.
First, you should pass Ajax data property in string representation. Then, since you mix dataType and contentType properties, change dataType value to "json":
$.ajax({
url: "saveList.py",
type: "post",
data: JSON.stringify({'param':{"hello":"world"}}),
dataType: "json",
success: function(response) {
alert(response);
}
});
Finally, modify your code a bit to work with JSON request as follows:
#!/usr/bin/python
import sys, json
result = {'success':'true','message':'The Command Completed Successfully'};
myjson = json.load(sys.stdin)
# Do something with 'myjson' object
print 'Content-Type: application/json\n\n'
print json.dumps(result) # or "json.dump(result, sys.stdout)"
As a result, in the success handler of Ajax request you will receive object with success and message properties.
You should read json data like this:
#!/usr/bin/env python3
import os
import sys
import json
content_len = int(os.environ["CONTENT_LENGTH"])
req_body = sys.stdin.read(content_len)
my_dict = json.loads(req_body)
With the following code, you can run into problems:
myjson = json.load(sys.stdin)
or written less succinctly:
requ_body = sys.stdin.read()
my_dict = json.load(requ_body)
That does work for me when my cgi script is on an apache server, but you can't count on that working in general--as I found out when my cgi script was on another server. According to the cgi spec:
RFC 3875 CGI Version 1.1 October 2004
4.2. Request Message-Body
Request data is accessed by the script in a system-defined method;
unless defined otherwise, this will be by reading the 'standard
input' file descriptor or file handle.
Request-Data = [ request-body ] [ extension-data ]
request-body = <CONTENT_LENGTH>OCTET
extension-data = *OCTET
A request-body is supplied with the request if the CONTENT_LENGTH is
not NULL. The server MUST make at least that many bytes available
for the script to read. The server MAY signal an end-of-file
condition after CONTENT_LENGTH bytes have been read or it MAY supply
extension data. Therefore, the script MUST NOT attempt to read more
than CONTENT_LENGTH bytes, even if more data is available. However,
it is not obliged to read any of the data.
The key line is:
the script MUST NOT attempt to read more
than CONTENT_LENGTH bytes, even if more data is available.
Apparently, apache sends an eof signal to the cgi script immediately after sending the request body to the cgi script, which causes sys.stdin.read() to return. But according to the cgi spec, a server is not required to send an eof signal after the body of the request, and I found that my cgi script was hanging on sys.stdin.read()--when my script was on another server, which eventually caused a timeout error.
Therefore, in order to read in json data in the general case, you should do this:
content_len = int(os.environ["CONTENT_LENGTH"])
req_body = sys.stdin.read(content_len)
my_dict = json.loads(req_body)
The server sets a bunch of environment variables for cgi scripts, which contain header information, one of which is CONTENT_LENGTH.
Here is what a failed curl request looked like when I used myjson = json.load(sys.stdin):
-v verbose output
-H specify one header
--data implicitly specifies a POST request
Note that curl automatically calculates a Content-Length header
for you.
~$ curl -v \
> -H 'Content-Type: application/json' \
> --data '{"a": 1, "b": 2}' \
> http://localhost:65451/cgi-bin/1.py
* Trying ::1...
* TCP_NODELAY set
* Connection failed
* connect to ::1 port 65451 failed: Connection refused
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 65451 (#0)
> POST /cgi-bin/1.py HTTP/1.1
> Host: localhost:65451
> User-Agent: curl/7.58.0
> Accept: */*
> Content-Type: application/json
> Content-Length: 16
>
* upload completely sent off: 16 out of 16 bytes
=== hung here for about 5 seconds ====
< HTTP/1.1 504 Gateway Time-out
< Date: Thu, 08 Mar 2018 17:53:30 GMT
< Content-Type: text/html
< Server: inets/6.4.5
* no chunk, no close, no size. Assume close to signal end
<
* Closing connection 0
Adding a little bit to the great #7stud's answer
I had some problems with content length when reading unicode which I fixed by reading from buffer:
content_length = int(os.environ["CONTENT_LENGTH"])
data = sys.stdin.buffer.read(content_length).decode('utf-8')
What is my Problem:
I'm making an vue3 app where the login and registration should be done over back4app.
So i initialize the connection as early as possible with the code below:
Parse.initialize(
config.back4app_applicationId,
config.back4app_clientKey
)
Parse.serverURL = config.back4app_url
After this code ran there is a successful health request to the back4app-Servers
And here is the code used for sign Up:
const parseUser = new Parse.User()
parseUser.set("username", userData.username)
parseUser.set("email", userData.email)
parseUser.set("password", userData.password)
try {
await parseUser.signUp()
} catch (error) {
console.error("error: ", error)
}
When the code runs the site is sending an request to the back4app server. Respon below
Response-body:
unauthorized
Response-headers:
access-control-allow-credentials: true
access-control-allow-headers: DNT, Keep-Alive, User-Agent, X-Requested-With, If-Modified-Since, Cache-Control, Content-Type, X-Application-ID, X-Access-Token, X-Parse-Master-Key, X-Parse-REST-API-Key, X-Parse-Javascript-Key, X-Parse-Application-Id, X-Parse-Client-Version, X-Parse-Session-Token, X-Requested-With, X-Parse-Revocable-Session, X-CSRF-Token, X-Apollo-Tracing, X-Parse-Client-Key, X-Parse-Installation-Id
access-control-allow-methods: GET, HEAD, OPTIONS, POST, PUT, DELETE
access-control-allow-origin: https://localhost:3000
access-control-expose-headers: X-Parse-Job-Status-Id
access-control-max-age: 1728000
content-length: 24
date: Wed, 28 Jul 2021 10:23:10 GMT
server: nginx/1.18.0 (Ubuntu)
via: 1.1 7fcb41b117930690c299be9cec4a977a.cloudfront.net (CloudFront)
x-amz-cf-id: AX6MG8omTAxfGPQUHUR4SkRnWW9gp33_kqJHXgEFv9eIATnI1muxyA==
x-amz-cf-pop: FRA6-C1
x-cache: Error from cloudfront
x-powered-by: Express
What have i tried:
I tried to run the code on a different PC
run the code on a site where the domain has a (not self-signed) HTTPS certificate
giving parse the master key on initiation of my application
different browsers
searching for solution in back4app and parse docs
Changing the public class level permissions for the Userclass
Hopefully i supplied all necessary information for the problem. I'm pretty lost what could be the error here and I'm very grateful for every answer.
The Error was me using the clientkey instead of the javascriptkey.
Thanks to #DaviMacêdo for providing the answer.
As you might know, RFC 6265 indicates that it is allowed to have multiple headers with the Set-Cookie name.
However, Fetch API doesn't allow to do that because all the methods exposed by its Headers interface (including get(), set(), append(), entries() and all the rest) have been implemented to merge the values of all the headers with the same name into a single header separated by commas.
For example, if we do this:
var headers = new Headers();
headers.append('content-type', 'text/plain');
headers.append('set-cookie', 'test1=v; Max-Age=0');
headers.append('set-cookie', 'test2=v; Max-Age=0');
headers.append('set-cookie', 'test3=v; Max-Age=0');
and then we try to read the set-cookie values using get('set-cookie'), or by iterating the headers variable using entries(), we get this:
'set-cookie' : test1=v; Max-Age=0, test2=v; Max-Age=0, test3=v; Max-Age=0
Please notice that the same wrong behaviour also happens if we try to read or manipulate an existing response object having multiple headers with the same name (i.e. created by other frameworks that arguably support such allowed behavior): in other words, it seems like the Fetch API is completely unable to properly deal with such scenario.
Now, while this behavior is desired for some headers, such as Accept, the Set-Cookie header is not parsed correctly by most browsers (including Chrome and Firefox), thus resulting in cookies not being correctly set.
Is that a known bug? If that's the case, is there an usable workaround that can be used to overcome this?
This is a known "issue" with the standard. It's actually the first note of the Fetch API standard in the Headers section:
Unlike a header list, a Headers object cannot represent more than one Set-Cookie header. In a way this is problematic as unlike all other headers Set-Cookie headers cannot be combined, but since Set-Cookie headers are not exposed to client-side JavaScript this is deemed an acceptable compromise. Implementations could chose the more efficient Headers object representation even for a header list, as long as they also support an associated data structure for Set-Cookie headers.
You can read more or even raise your own issue in the spec's repo.
There are already a few issues discussing the Set-Cookie case at length though:
https://github.com/whatwg/fetch/issues/973
https://github.com/whatwg/fetch/issues/506
https://github.com/whatwg/fetch/issues/189
https://lists.w3.org/Archives/Public/www-archive/2016Jan/thread.html
You mentioned using workarounds, but this really depends on your use-case.
The note mentions using a secondary structure to handle those.
If you really want to store those cookies in a Headers object, you could add custom headers to store them:
new Headers([
['X-MyOwn-Set-Cookie-1', 'cookie1=value1'],
['X-MyOwn-Set-Cookie-2', 'cookie2=value2']
]);
Obviously, this is not an acceptable solution for the standard, but maybe your practical considerations might be in line with such a compromise.
As pointed out by this note and #Barmar in the comments, you usually use Set-Cookie from the server, not the front-end.
For instance, there's no problem setting multiple Set-Cookie with express:
test.js
const express = require('express');
const app = express();
const cookies = [
{ key: 'cookie1', value: 'value1' },
{ key: 'cookie2', value: 'value2' },
];
app.get('*', (req, res) => {
console.log(req.url);
for (const { key, value } of cookies) {
res.cookie(key, value, { expires: new Date(Date.now() + 1000 * 60), httpOnly: true });
}
res.status(200).send('Success');
});
app.listen(3000, () => console.log(`Listening on http://localhost:3000/`));
Terminal 1
$ node test.js
Listening on http://localhost:3000/
Terminal 2
$ curl -v http://localhost:3000/
[...]
< HTTP/1.1 200 OK
< X-Powered-By: Express
< Set-Cookie: cookie1=value1; Path=/; Expires=Tue, 04 Aug 2020 19:45:53 GMT; HttpOnly
< Set-Cookie: cookie2=value2; Path=/; Expires=Tue, 04 Aug 2020 19:45:53 GMT; HttpOnly
< Content-Type: text/html; charset=utf-8
[...]
I was wondering if anyone knew how to handle redirects with the Request npm from sites such as bitly or tribal or Twitter's t.co URLs. For example, if I have web page that I want to scrape with the Request npm and the link I have to get to that page is a bity or shortened URL that is going to redirect me, how do I handle those redirects?
I found that the Request npm has a "followRedirect" options set to true by default. If I set that to false I can get the next link that the page will redirect me to by scraping that page that is returned, but that isn't the best because I don't know how many redirects I am going to have to go through.
Right now I am getting a 500 error. When I have "followRedirect" set to true. When I have "followRedirect" set to false, I can get each redirect page. Again, I don't know how many redirect pages I will have to go through. Code is below:
var options = {
followRedirect: false
};
request('http://t.co/gJ74UfmH4i', options, function(err, response, body){
// when options are set I get the redirect page
// when options are not set I get a 500
});
At first, you need to get the last redirect url, using followAllRedirects: true parameter
request('http://t.co/gJ74UfmH4i', {
method: 'HEAD',
followAllRedirects: true
}, function(err, response, body) {
var url = response.request.href
})
>
The second part is making request to final url, with some browser-like headers
request(url, {
headers: {
"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.46 Safari/537.36"
},
}, function(err, response, body) {
//here is your body
})
The Request package follows HTTP 3xx redirects by default but the URL you are using is returning an HTTP 200 with a META REFRESH style of redirect. I'm not sure if Request supports this particular style of redirect so you may need to parse the response and follow it manually.
GET http://t.co/gJ74UfmH4i HTTP/1.1
HTTP/1.1 200 OK
cache-control: private,max-age=300
content-length: 208
content-type: text/html; charset=utf-8
date: Fri, 28 Aug 2015 16:28:59 GMT
expires: Fri, 28 Aug 2015 16:33:59 GMT
server: tsa_b
set-cookie: muc=b0a729d6-9a30-466c-9cd9-57306369613f; Expires=Wed, 09 Aug 2017 16:28:59 GMT; Domain=t.co
x-connection-hash: 28133ba91da8c83d45afa434e12f8a72
x-response-time: 9
x-xss-protection: 1; mode=block
<noscript><META http-equiv="refresh" content="0;URL=http://nyti.ms/1EmZJhP"></noscript><title>http://nyti.ms/1EmZJhP</title><script>window.opener = null; location.replace("http:\/\/nyti.ms\/1EmZJhP")</script>
One possible route to understanding the issue would be to use a function for followRedirect to see if you can find out where it's failing.
From the README:
followRedirect - follow HTTP 3xx responses as redirects (default: true). This property can also be implemented as function which gets response object as a single argument and should return true if redirects should continue or false otherwise.
I am using JS to access the rdio plugin. I am using the following for Oauth http://code.google.com/chrome/extensions/tut_oauth.html.
I am able to get the signed token etc. However, when ever I try to send a signedRequest at http://api.rdio.com/1/, I receive 401, un-authorized error.
X-Mashery-Error-Code:ERR_401_INVALID_SIGNATURE
X-Mashery-Responder:mashery-web4.LAX
This is what I am trying to send:
var url = 'http://api.rdio.com/1/';
var request = {
'method': 'POST',
'headers': {
'Content-Type': 'application/x-www-form-urlencoded'
},
'parameters': {
'alt': 'json',
'method':'currentUser'
},
'body': 'Data to send'
};
bgPage.oauth.sendSignedRequest(url, mycallback, request);
I receive the following error in console.
Request URL:http://api.rdio.com/1/?alt=json&method=currentUser&oauth_consumer_key=yv8ehzehdv55**********&oauth_nonce=******&oauth_signature=**********&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1305190893&oauth_token=us6myp99p4qc86umea9p8fp*****************
Request Method:POST
Status Code:401 Unauthorized
Request Headers
Accept:*/*
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Content-Length:12
Content-Type:application/x-www-form-urlencoded
Cookie:__qca=P0-158278476-1296771701175; r=eyJfdSI6IDE5MjY1LCAiX2UiOiAzMTU1NjkyNn0.SvN8xd7rIuLzTp7hxqi4eJEdvu8; __utmz=225830489.1305153361.198.18.utmcsr=rdioquiz.ianloic.com|utmccn=(referral)|utmcmd=referral|utmcct=/; __utma=225830489.281668250.1296676147.1305184513.1305187119.201; __utmc=225830489
Host:api.rdio.com
Origin:chrome-extension://oiojbkkpmcgmpnjkhjmaggajckamjkap
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_6) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.65 Safari/534.24
Query String Parameters
alt:json
method:currentUser
oauth_consumer_key:yv8ehzehdv55pbb74ss9dt23
oauth_nonce:BQF0x
oauth_signature:KttF************tRO 8PL yjPF2Ktk=
oauth_signature_method:HMAC-SHA1
oauth_timestamp:1305190893
oauth_token:us6myp99p4qc86umea9p8fphbgq4dxdd76txvyn***********
Form Data
Data to send:
Response Headers
Accept-Ranges:bytes
Content-Length:30
Content-Type:text/xml
Date:Thu, 12 May 2011 09:01:33 GMT
Server:Mashery Proxy
X-Mashery-Error-Code:ERR_401_INVALID_SIGNATURE
X-Mashery-Responder:mashery-web4.LAX
*I am just trying to mimic what's mentioned here. Its an Oauth library(http://code.google.com/chrome/extensions/tut_oauth.html) from Google to make Chrome extension development easy.
They have an Oauth sample code to get your document list etc. http://code.google.com/chrome/extensions/samples.html#4e35caa9742fb82dbd628892d23a781614f6eff6
I think I am not able to get past send a POST requestto the rdio API. It gives an un-authorized error.*
We found a similar issue with the same service (rdio) and method ("currentUser").
What ended up working was:
(1) make sure you have method=currentUser in the POST body; I'm not sure from the above curl output if that is the case.
And, this is the bit that actually fixed the issue:
(2) we had to also add the method name to the signature itself.
FYI we used this library: https://oauth.googlecode.com/svn/code/javascript/
But the tricky part, as you are seeing, was figuring out how to seed the method in that library that creates the signature. Without the 'method=currentUser' being part of the signature, we experienced the same error condition.
Check your timezone, date, and time on your computer. If any one of these is wrong, OAuth will fail.