I'm developing a wordpress plugin, which obtains certain product info from the Lightspeed Retail API. I followed the steps in the documentation here http://developers.lightspeedhq.com/retail/authentication/access-token/
I have the Client ID and Client Secret, but I dont have the Temporary Token, I am stuck at this point, I am sure I'm missing some procedure here, can you help me?
This is the current code I use based on the API documentation:
...
$tokenURL = "https://cloud.lightspeedapp.com/oauth/access_token.php";
$postFields = [
'client_id' => 'XXXXXXXXXXXXX',
'client_secret' => 'XXXXXXXXXXXXX',
'code' => 'Temporary Token',
'grant_type' => 'authorization_code'
];
...
The temporary token is returned if you follow the instructions here.
You need to start using this URL:
https://cloud.lightspeedapp.com/oauth/authorize.php?response_type=code&client_id={client_id}&scope={scope}&state={state}
which will return after your app is accepted with a code/temporary token.
Related
I am using JSON Web Token to authenticate the user in my application. Using https://jwt.io documentation, I use the jwt token to authenticate the user.
$tokenData = array(
"jti" => $tokenId,
"iat" => $issuedAt,
"exp" => $expire,
"user" => $user
);
$jwt = JWT::encode($tokenData, $secretKey, 'HS512');
But the problem is when one user can not login from multiple devices at the same time, it gives an error since the first login token get invaidated. Is there a way to handle this issue. Thanks in advance.
We are processing payments on behalf of third parties using SetExpressCheckout. It appears to work correctly even though the third party has not granted us permissions. Are we doing it correctly?
From what I have understood, in order to process payment for a third party the third party should go to Tools > API credentials > Grant API Permission in their PayPal account and grant permission to our API username to Use Express Checkout to process payments. However, we have noticed two issues with this:
If the third-party PayPal account is just a personal account (not a business account) then there is no option to grant API permissions
Even if the non-business third-party PayPal account doesn't grant this permission we are still able to take payment into their account.
So the question is, is it actually necessary for a third party to grant us this permission in order for us to be able to process payments which are crediting their PayPal accounts?
In case you need more information, here is a cut-down version of the PHP code we are using to start the SetExpressCheckout request. We are specifying the third-party using the SUBJECT parameter of the request, this parameter is filled in with the email address of the third-party's PayPal account.
// Parameters for SetExpressCheckout
$requestParams = array(
'METHOD' => 'SetExpressCheckout',
'VERSION' => $this->_version,
'PAYMENTREQUEST_0_DESC' => "Order number",
'PAYMENTREQUEST_0_AMT' => 10,
'PAYMENTREQUEST_0_CURRENCYCODE' = 'EUR',
'PAYMENTREQUEST_0_ITEMAMT' => 10,
'RETURNURL' => "http://SUCCESS_URL_TO_RETURN_TO",
'CANCELURL' => "http://FAILURE_URL_TO_RETURN_TO",
'USER' => 'OUR_API_USERNAME',
'PWD' => 'OUR_API_PASSWORD',
'SIGNATURE' => 'OUR_API_SIGNATURE',
'SUBJECT' => 'THIRD_PARTY_EMAIL'
);
// Options for curl
$curlOptions = array (
CURLOPT_URL => 'https://api-3t.paypal.com/nvp',
CURLOPT_VERBOSE => 1,
CURLOPT_SSL_VERIFYPEER => true,
CURLOPT_SSL_VERIFYHOST => 2,
CURLOPT_CAINFO => 'cacert.pem', //CA cert file
CURLOPT_RETURNTRANSFER => 1,
CURLOPT_POST => 1,
CURLOPT_POSTFIELDS => http_build_query($requestParams)
);
// Send the curl request
$ch = curl_init();
curl_setopt_array($ch,$curlOptions);
$response = curl_exec($ch);
// Handle possible errors
if (curl_errno($ch)) {
//Handle errors
} else {
// Handle success
}
curl_close($ch);
If third-party accounts are not required to grant us permission then we can simplify setup of PayPal by simply asking for their PayPal account's email address, and not have to bother them with granting permissions.
Many thanks for any information you can give.
There are two ways to make API calls on behalf of others. 1) Grant API permissions from merchant PayPal account to API caller OR 2) Use SUBJECT NVP variable with the merchant PayPal account email address('SUBJECT' => 'THIRD_PARTY_EMAIL').
So you can make the API calls on behalf of the merchant just by using the SUBJECT NVP variable with merchant PayPal account email address, here the merchant no need to grant API permissions to you.
"Api execution successful. No data found for the API."
I am a customer of yodlee using live API .
In /jsonsdk/SiteAccountManagement/getAllSiteAccounts, i am passing both valid cobSessionToken, userSessionToken but it is returning "Api execution successful. No data found for the API." as response.
Shall i know what is wrong in my input.
I am using PHP - REST API.
GET_ALL_SITE_ACCOUNTS = /jsonsdk/SiteAccountManagement/getAllSiteAccounts
$config = array(
"url" => Yodlee\ConfigInc\serviceBaseUrl.Yodlee\ConfigInc\GET_ALL_SITE_ACCOUNTS,
"parameters" => array(
"cobSessionToken" => $cobSessionToken,
"userSessionToken" => $userSessionToken,
)
);
$response_to_request = Yodlee\restClient::Post($config["url"], $config["parameters"]);
so my $response_to_request variable returning "Api execution successful. No data found for the API."
There is nothing wrong with your input. Your user doesn't have any data present in Yodlee's data base and hence this response is returned. You need to first add a site using bank credentials and then you will have data through these APIs.
Please refer to Quick Start guide for more help.
I need to be able to use the API for SugarCRM to exchange information with several other applications. I found the api docs, and some good articles with sample code. The end result of my code is to send this command:
http://localhost/sugarcrm/service/v2/rest.php?method=login&input_type=json&response_type=json&rest_data={%22user_name%22:%22rest%22,%22password%22:%2265e8800b5c6800aad896f888b2a62afc%22,%22version%22:%22.01%22}
Which produces this error
{"name":"Invalid Login","number":10,"description":"Login attempt failed please check the username and password"}null
I have googled the error and found several others with this issue, but no solution.
I think the proper REST string would be like:
method=login&input_type=json&response_type=json&rest_data={"user_auth": {"user_name":"user","password":"somemd5hash","version":"1.0"},"application_name":"RestTest"}
(should be url-encoded then of course)
For me, I needed to use something along the lines of:
method=login&input_type=JSON&response_type=JSON&rest_data=$REST_DATA
The REST data is:
{
user_auth => {
user_name => $USERNAME,
password => $PW,
version => "1.2"
},
application => "foo"
}
(URL encoded)
URL : http://mycrmurl.com/service/v4/rest.php
Request Data - in POST method
method=login&input_type=JSON&response_type=JSON&rest_data={"user_auth":{"user_name":"username","password":"md5password","version":"1.0"},"application_name":"RestTest"}
Response from WS:
{"id":"someID","module_name":"Users","name_value_list":{"user_id":{"name":"user_id","value":"1"},"user_name":{"name":"user_name","value":"username"},"user_language":{"name":"user_language","value":"en_us"},"user_currency_id":{"name":"user_currency_id","value":"-99"},"user_is_admin":{"name":"user_is_admin","value":true},"user_default_team_id":{"name":"user_default_team_id","value":null},"user_default_dateformat":{"name":"user_default_dateformat","value":"m/d/Y"},"user_default_timeformat":{"name":"user_default_timeformat","value":"h:ia"},"user_number_seperator":{"name":"user_number_seperator","value":","},"user_decimal_seperator":{"name":"user_decimal_seperator","value":"."},"mobile_max_list_entries":{"name":"mobile_max_list_entries","value":null},"mobile_max_subpanel_entries":{"name":"mobile_max_subpanel_entries","value":null},"user_currency_name":{"name":"user_currency_name","value":"US Dollars"}}}
Ok Im having more luck with G'oogle's federated log in, I'm at the point where you get the following params back from Google.
[openid_ns] => http://specs.openid.net/auth/2.0
[openid_mode] => id_res
[openid_op_endpoint] => https://www.google.com/accounts/o8/ud
[openid_response_nonce] => 2010-01-02T14:58:22ZvP-t8tJXqGWaPw
[openid_return_to] => http://localhost/blablabla/index.php?c=google
[openid_assoc_handle] => AOQobUdTUUFVqQ9PeC9r19-rHOlEg_xvFmiIUahkmhNQ7Blrh14w2-eb
[openid_signed] => op_endpoint,claimed_id,identity,return_to,response_nonce,assoc_handle,ns.ext1,ext1.mode,ext1.type.firstname,ext1.value.firstname,ext1.type.email,ext1.value.email,ext1.type.lastname,ext1.value.lastname
[openid_sig] => tUZtUtVcvOfrodpPEx4bItcxVME=
[openid_identity] => https://www.google.com/accounts/o8/id?id=xxxxxxxxxxxxxxxxxx
[openid_claimed_id] => https://www.google.com/accounts/o8/id?id=xxxxxxxxxxxxxxxxxx
[openid_ns_ext1] => http://openid.net/srv/ax/1.0
[openid_ext1_mode] => fetch_response
[openid_ext1_type_firstname] => http://axschema.org/namePerson/first
[openid_ext1_value_firstname] => myName
[openid_ext1_type_email] => http://axschema.org/contact/email
[openid_ext1_value_email] => user#gmail.com
[openid_ext1_type_lastname] => http://axschema.org/namePerson/last
[openid_ext1_value_lastname] => MySurname
The only thing I need to do now is sign it and' If I understand this correctly google is giving me a clue with [openid_signed]
ie: string those params together and then creating the hash out of the concatenated strin the should equal [openid_sig] => tUZtUtVcvOfrodpPEx4bItcxVME=
But Im sure there is more to the signature generating formula - anyone know what it is since I cant find it in Google's documentation anywhere?
You can use JanRain's RPX-Now for the same. It has a much simpler and allows almost all OpenID providers. https://rpxnow.com/
Google Federated Login is, with a few minor changes, OpenID. Rather than looking for docs on Google Federated Login's signature protocol, look for information on what how to generate a signature and how to verify the signature.
Even if you don't want to use the JanRain code, you could still get some answers to these questions by looking at the code. For instance, the verify function on line 1320 of /Auth/OpenID/Server.php seems to be where the code for verifying the signature starts.