there is many methods to pay money in the internet and on of those is PayPal.i'm working on django project which i need to integrate paypal so i use this code her in my views :
from paypal.pro.views import PayPalPro
def buy_it_now(request):
item = {
"amt": "10.00",
"inv": "inventory",
"custom": "tracking",
"cancelurl": "http://...",
"returnurl": "http://..."}
kw = {"item": item,
"payment_template": "payment.html",
"confirm_template": "confirmation.html",
"success_url": "/success/"}
ppp = PayPalPro(**kw)
return ppp(request)
but i get this in console :
PayPal Response:
{'ack': 'Failure',
'build': '5715372',
'correlationid': 'd328871dd352',
'l_errorcode0': '10002',
'l_longmessage0': 'Security header is not valid',
'l_severitycode0': 'Error',
'l_shortmessage0': 'Security error',
'timestamp': '2013-05-03T13:10:14Z',
'version': '54.0'}
and i also chek my test account in paypal sandbox, there is no transaction
A 10002 error typically means that you are either not setting the endpoint correctly, the API credentials are not correct, or you do not have permissions to run the API call on the account that you are trying to.
Check your endpoints to make sure they are correct. Make sure your code reflects the sandbox endpoint if trying to point towards the sandbox, and live if trying to run a transaction on the live site.
Check your API credentials, re copy them over to your code. Make sure you do not have any type of white space before or after your credentials. Also make sure if you are trying to point to the live site that you are passing over your live credentials and not your sandbox credentials, and vise verse. The live credentials and sandbox credentials will not be the same.
If you are trying to process the API call on another account, make sure they have granted 3rd party access permissions to your API in their account. Make sure they have granted the correct permissions to your API username.
Make sure that you are not passing across a variable "SUBJECT" and populating it with an email address. You would only do this if you are trying to run an API on that account, and not your own that your API credentials were generated for. This would be what you used for 3rd party access mentioned in step 3.
Related
I'm trying to setup a VPN connection using a federated login with Google IdP following these instructions.
Previously, I had configured a saml-provider with Google and it worked fine to authenticate users to the AWS console through Google using ARN roles
WHen I setup the VPN connection, it successfully opens the browser and asks me to select my google account, but after selecting the account I'm getting an error message from Google
According to this help section
Verify that the value in the saml:Issuer tag in the SAMLRequest matches the Entity ID value configured in the SAML Service Provider Details section in the Admin console. This value is case-sensitive.
So this is a problem coming from AWS and not from me ? Is Google IdP compatible at all with VPN authentication ? (I found this doc that mentions compatibility with okta)
Edit
Thanks to some of the answers below, I managed to make it work with Google IdP. Here is a screenshot of relevant SAML Google app screens (note that for groups I ended up adding the employees department, but I guess anything else would have worked)
To be able to save an ACS URL starting with http:// in the G Suite interface, use the trick given by teknowlogist: open the inspector > network tab, perform the request to save an URL with https, then right-click copy it as cURL, replace https by http, paste in regular console, and you're good.
I found a workaround to not being able to input http://127.0.0.1:35001 as the ACS URL on the GSuite SAML app page. The Google admin console only does client-side validation for the https requirement, so you can use the Chrome console to monitor the network call made when modifying the ACS URL.
Then, you can copy this as a curl command and change https to http
#Ted Schroeder —
Previous approach (or, plain Google doesn't work)
I just used a reverse proxy:
mitmproxy \
--listen-port 35000 \
--mode 'reverse:http://127.0.0.1:35001' \
--set keep_host_header=true
If you change Google SAML's ACS URL to be https://127.0.0.1:35000 and click "Test SAML Login", Google will take you to https://127.0.0.1:35000, whose traffic will be redirected to http://127.0.0.1:35001. In the browser I get:
Authentication details received, processing details. You may close this window at any time.
However, using the SAML-tracer extension, I found that there was a URL mismatch (https://127.0.0.1:35000 vs. http://127.0.0.1:35001). Seems like the AWS VPN Client is broadcasting its expected URL as being http://127.0.0.1:35001. So this doesn't seem viable.
Current approach (or, Auth0+Google works)
I tried using Auth0 instead, and got it to work! There's a few hoops — for instance, create a new Auth0 application, go to Addons and enable SAML2 Web App, set Application Callback URL to http://127.0.0.1:35001, and then in Settings use the following:
{
"audience": "urn:amazon:webservices:clientvpn",
"mappings": {
"user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
"email": "NameID",
"name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
"given_name": "FirstName",
"family_name": "LastName",
"upn": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn",
"groups": "memberOf"
},
"binding": "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect",
"signResponse": true
}
Then users, if they download the VPN config from AWS and use the AWS VPN Client app, will be taken to an Auth0 login screen where they can login via Google. Voila! (And then for security, you need to add Auth0 Rules to grant only certain users/groups authorization.)
I don't have a full answer yet, but I have the beginnings of one and I actually got past the 403 error above. The key to all this can be found in the AWS Client VPN information here: https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/client-authentication.html
Look for the section entitled "Service provider information for creating an app".
The key is that these are the ACS URL and the Entity ID that need to be used. Unfortunately, G Suite won't let you set the ACS URL to a non-https URL and apparently the AWS Client VPN app won't provide a secure URL for the ACS URL (where the SAML Authenticate response goes).
So, if you set the Entity ID to "urn:amazon:webservices:clientvpn" and have the G Suite SAML app in place according to the instructions, you'll get past the 403. However, since the ACS URL can't be specified you get whatever error message you're likely to get from the ACS URL that the authentication response goes to.
Example scenario
If you set it to https://signon.aws.amazon.com/saml" like you would for AWS Console SSO, you get an error from the AWS sign in that the SAML response was invalid.
And if you set it to https://127.0.0.1:35001 then you get a message from the browser that the "site can't provide a secure connection".
If anybody gets any further with this, I'd love to hear about it. In the meanwhile, I'm going to be looking into non-AWS OpenVPN clients that might actually support G Suite as a SAML IdP.
#alexandergunnarson
Since I don't have the ability to comment (thanks so much for making this easy stackOverflow) I had to edit my answer to get it past the censors.
Unfortunately, we don't have, and probably won't have for some time, G Suite Enterprise because it's too expensive for our startup environment. So OIDP is not a viable option for us now. I figured this would work. Good to know that it does.
I was too having the same issue. In my case, I needed to turn on the two-factor authentication for the account that I was trying to log in with.
I am having a hard time getting this to work by following along with Amazon's Alexa documentation. I'm running aground on Account Linking because I can't figure out how to get Login with Amazon (LWA) to ask for alexa::skills:account_linking scope.
I've included the Amazon API library in my application and set that all up correctly and I'm invoking the process using the (globally available) amazon object as follows (typescript):
const options: any = {};
options.scope = ['profile', 'alexa::skills:account_linking'];
options.scope_data = {
profile : {essential: false}
};
options.response_type = 'code';
const self = this;
amazon.Login.authorize(options, (response) => {
if (!response || !response.code) {
throw { error: response };
}
// ... send the response code to my server
// ... to be exchanged for bearer and refresh tokens
});
What I would expect to happen from that is a popup Amazon login process to be spawned which (1) has the user log in to Amazon, and (2) collects the user's consent to link their Amazon account to my Alexa skill (i.e. linked to my credentialed hosted service), so that we get back (in the browser) an authorization code that we can exchange (on our server) for bearer and refresh tokens to act on behalf of the user.
The problem is, that code above immediately fails and never pops up a process. The message that is thrown says: "An unknown scope was requested". If I remove the 'alexa::skills:account_linking' string from the options.scope array, I get to an Amazon login screen, and if I log in to Amazon, my server does get an authorization code, etc. But no Account Linking has taken place, so I'm stuck.
I've tried to reconcile this documentation (which also talks about including a Skill ID somehow), with this documentation but I'm just not seeing how to make it work. Can anyone please help point me in the right direction about what I'm doing wrong here? It must be something pretty fundamental.
If your goal is to use Login with Amazon for account linking only for the skill and to not store the tokens on your own server, you can set up the skill and Login with Amazon with the below configurations. The advantage of this approach is that you don't need to stand up your own web server to just handle the LwA flow. This approach also handles all the flow out of the box, including refreshing tokens.
If you're using these tokens for another purpose, you may want to look into something like AWS Cognito to simplify the process.
Skill Account Linking Configuration
Replace Your Client ID with the LwA Client ID, replace Your Secret with the LwA Client Secret, and copy your redirect URIs
LwA Configuration
Paste your Alexa redirect URLs here. These will be specific to your vendor account so it's important to have the right ones.
Source: This is what I do for my Aberto Sonorus skill: https://www.amazon.com/WBPhoto-Aberto-Sonorus/dp/B078W199Z3 (edited screenshots attached)
I'm following the docs at https://developers.google.com/photos/library/guides/authentication-authorization, and believe the below code is quite close to correct ...
import requests
# from https://developers.google.com/identity/protocols/OAuth2ForDevices#step-1-request-device-and-user-codes
def get_token(client_id="661666866149-42r2bldb8karc5bv5vltj0suis2fm4up.apps.googleusercontent.com"):
response = requests.post(
'https://accounts.google.com/o/oauth2/device/code',
data={
'client_id': client_id,
'scope': 'https://www.googleapis.com/auth/photoslibrary https://www.googleapis.com/auth/photoslibrary.readonly.appcreateddata https://www.googleapis.com/auth/photoslibrary.sharing'
})
print(response.text)
return response
The above keeps failing with
{
"error": "invalid_scope"
}
<Response [400]>
However, if I change the scope value to just email, that works. I got the value above from google's docs, so I don't know what else to put there.
It looks like you are following the guide for OAuth 2.0 for TV and Limited-Input Device Applications to authorize OAuth user scopes on a TV or similar device.
As outlined on that page, this flow only supports a limited set of scopes. Unfortunately this does not currently include the Google Photos Library API scopes.
There's a feature request open on the issue tracker to add support for this OAuth flow here: https://issuetracker.google.com/113342106 (You can "star" the issue to be notified of any updates.)
(If your flow involves a mobile device and a server component, you might be able to accomplish something similar with Google sign-in by exchanging user credentials between your server and Google Services. You could prompt users to authorize the scope in your app and after exchanging tokens with your server, make API calls that way. You'd have to handle the link between the TV/limited-input device and your app yourself.)
My Current Setup
Google Cloud Endpoints hosted on Google App Engine.
Google Echo Tutorial (https://cloud.google.com/endpoints/docs/frameworks/python/get-started-frameworks-python)
Python local server making requests to the echo API.
The echo tutorial is up and running. I can make calls to open endpoints and the one requiring an API key using a python script on my machine. I have not been able to make an authorized API call with a Google ID token. None of the Google examples have worked so far.
From my understanding, the workflow should be
Use a key file to authorize the service account to generate a JWT.
Use the JWT to generate a Google ID token.
Google Example: https://cloud.google.com/endpoints/docs/openapi/service-account-authentication#using_a_google_id_token (Key File)
The code fails. Function get_id_token() return res['id_token'] fails with no id_token in res.
Has anyone gotten the example to work? Does anyone have an example of making an authorized API call to an Endpoint API with a Google ID token from a service account?
The main issue was generating the JWT and the code that works for me is below. I have yet to find a better way to do this that works. If you know of a better way please submit your answers below or add a comment. The code that generates the Google ID Token from JWT is exactly from Google documentation here (https://github.com/GoogleCloudPlatform/python-docs-samples/blob/master/endpoints/getting-started/clients/service_to_service_google_id_token/main.py) get_id_token function.
def generate_jwt(audience, json_keyfile, service_account_email):
"""Generates a signed JSON Web Token using a Google API Service Account.
https://github.com/GoogleCloudPlatform/python-docs-samples/blob/master/endpoints/getting-started/clients/google-jwt-client.py
"""
# Note: this sample shows how to manually create the JWT for the purposes
# of showing how the authentication works, but you can use
# google.auth.jwt.Credentials to automatically create the JWT.
# http://google-auth.readthedocs.io/en/latest/reference/google.auth.jwt.html#google.auth.jwt.Credentials
signer = google.auth.crypt.RSASigner.from_service_account_file(json_keyfile)
now = int(time.time())
expires = now + 3600 # One hour in seconds
payload = {
'iat': now,
'exp': expires,
'aud': 'https://www.googleapis.com/oauth2/v4/token',
# target_audience must match 'audience' in the security configuration in your
# openapi spec. It can be any string.
'target_audience': audience,
'iss': service_account_email
}
jwt = google.auth.jwt.encode(signer, payload)
return jwt
I am trying to use the Google Contacts API and the Python / GDATA client handlers to access Contacts via OAuth 2.0 for users in the domain. I'm ultimately wanting to create a web service to add contacts for users, but the first step is getting this test working.
I can access my own Contacts just fine if I use the default URI. However, when I pass in the email address to construct the URI for another user, I can't seem to access the other user's Contacts. Here is the code that I'm using:
client.GetContacts(uri=client.GetFeedUri(contact_list=userEmail))
A 403 error is returned when I execute this.
gdata.client.RequestError: Server responded with: 403
Your client does not have permission to get URL /m8/feeds/contacts/<userEmail>/full from this server.
Mostly just trying to understand if what I'm attempting here is even possible. In the Email Settings API, for example, you can get authenticated to the domain and pass in a user's email to list their labels, add filters, etc. So, I would anticipate that the Contacts API would work the same, though handled slightly differently, i.e. modifying the URI, instead of just passing in an argument to the client handler. Please let me know if I am wrong in that presumption.
For authorization, I'm getting the details using flow_from_clientsecrets, then getting the token to authorize the ContactsClient for the domain. Again, I can access my own contacts fine, so authorization seems OK, but I can't access other users' contacts.
client = token.authorize(ContactsClient(domain=domain))
Seems like I'm missing something with respect to accessing other users. Is anybody able to assist me over this hump? Here are some things that I've checked / confirmed:
Contacts API is enabled for the project
Scopes have been authorized for the Client ID in the control panel > Manage 3rd party access
I am a Super Admin in the domain.
Thanks for your time!
I figured out the answer here from another post with exceptional detail:
Domain-Wide Access to Google GDATA APIs
You need to use "Service Account" authentication. For some reason, I was thinking that would only work with the newer discovery-based APIs. But, service account access also works for GDATA APIs. I can access all the Contacts for users in the domain now.