We tested our web application successfully using a sandbox REST API account (and test credentials).
When we wanted to put the application into production (using REST API live credentials visible on the same PayPal web site where the sandbox/text credentials were shown), we received an error from the production PayPal server on a live credit-card transaciton:
Error code : 401 with response : Server returned HTTP response code: 401 for URL: https://api.paypal.com/v1/payments/payment
We have a Business Account that is not yet 100% verified (75% verified at the moment), so we are not sure if this is caused by some technical issue or the fact that the account is not yet 100% verified.
PayPal web site is quite confusing and the process of moving the app from test to production is not clearly explained. It seems that they are migrating from some old web sites to new ones and the user is prompted to login multiple times, redirected to different URL-s... E.g. we can see our application test and live credentials on the developer.paypal.com, but not on apps.paypal.com where no apps are listed, even though the same user is logged in (owner of the business account)???
For future readers, you have to use Live Credentials, on https://developer.paypal.com go to My apps and in App details there is a link at a bottom of the page :
Click on that link and you will see live credentials.
You now click on your sandbox application and then click live at the top of the screen to get your live credentials.
For the PayPal REST api use the credentials provided on developer.paypal.com (new version of PayPal dev experience). Live calls require the account to be vetted which includes fully verified.
Related
I'm trying to follow the instructions here which tell me to create credentials via the instructions here, which as step 6 tells me 'Click the user type for your app. If you're running a Quickstart, select Internal.'
On the page in question, 'Internal' is greyed out, and tells me I can't select it because I'm not a Google Workspace user. Going to Google Workspace, it tells me I need a domain name for 'my business'. Since I don't have a business, or any domain that would have anything to do with this project (I just want to push some personal data from the command line to a sheet), I don't seem to be able to proceed. Is the Google Sheets API just not available for such use?
If you don't have a Workspace account but you don't want to publish your app publicly (and go through the associated review by Google), you can set the app to External and test the app instead of publishing it.
In order to do that, just add yourself as Test user when setting the OAuth consent screen, and leave the Publishing status on Testing, don't change it to In production:
Testing
Projects configured with a publishing status of Testing are limited to up to 100 test users listed in the OAuth consent screen. A test user consumes a project's test user quota once added to the project.
Google will display a warning message before allowing a specified test user to authorize scopes requested by your project's OAuth clients. The warning message confirms the user has test access to your project but should consider the risks associated with granting access to their data to an unverified app.
Authorizations by a test user will expire seven days from the time of consent. If your OAuth client requests an offline access type and receives a refresh token, that token will also expire.
Reference:
Publishing status: Testing
Unfortunately, that means that the authorization lasts only for 7 days. Which means that I have to keep creating new projects every 7 days, which is untenable. Here is the excerpt from the "Setting up your OAuth consent screen" page on the Google support site.
Authorizations by a test user will expire seven days from the time of consent. If your OAuth client requests an offline access type and receives a refresh token, that token will also expire.
Background / Context:
Take any out of box ASP.NET Core template with user logins enabled. You may use external login providers google, facebook, msft etc. as well. Alternatively, just clone this sample web application: https://github.com/dotnet-architecture/eShopOnWeb
Test:
Login to the test website created. (test user name we used : neel)
Record any authorized web request using Fiddler or web developer tools etc. We recorded /basket request of eShopOnWeb sample website which shows personalized shopping cart of the logged in user.
Logout.
Close browser.
Open website in guest mode. (do not login). You may choose a different browser altogether.
Replay step 2. (This uses exact same headers containing cookies, token etc.)
Observation:
This successfully returns shopping cart items of the user neel.
I am faced with two questions:
Is this a login related vulnerability? I think it is!! Shouldn't the token expire (session destroy) with logout?
If this is a vulnerability, how to fix it? Anti-forgery token comes built in with Identity, but it doesn't seem to help.
I have a web application setup to handle webhook requests from an Actions-on-Google/Dialogflow application using the Google Assistant. Users don't need to sign-in to a google account in order to use my web application and I'd prefer to keep it that way, so that users can sign in with any email address.
I also want my users to be able to interact with my application using the Google Assistant, and be able to access personal/contextual data via the assistant (i.e. when a speaker says, "what's on my shopping list", the web app needs to be able to know what my means).
Currently, I have this working by using my web app to issue a unique short code to my user (in the web app UI) and then with an intent on the Assistant where the speaker says "My code is 1-2-3-4" and then my web app can identify the user from then on (by saving the userId from the webhook request to whatever user got the short code 1234 and then using that userId to lookup the user on each subsequent request.)
My question is, is there a better way to do this? Ideally, in my web app, I'd like to have something like an "Authorize Google Assistant" button, which would then link the user's google account to their web-app account, so that the conversation on the Assistant is seamless.
Has anyone done this before?
Thanks
This is the perfect use case for Account Linking with the Google Assistant.
From your users' perspective, they will start to use your Action. If they're doing so through a speaker and they haven't linked the account yet, they'll be directed to a mobile device to do so. On a mobile device, they'll be redirected to a page on your website where they will been to authenticate themselves and authorize your server to let them in through the Assistant. Once they have done so, they won't need to log in again, the accounts will be linked, and they'll be able to use the voice Action without further obstruction.
From your perspective as a developer, you'll need to setup an OAuth2 server (I suggest the code flow). That login process I mentioned is the first step in the OAuth dance, and will end up with you issuing a code to Google. They will then exchange this code for an Auth Token (with a limited lifetime) and a Refresh Token (which does not expire). They will periodically use the Refresh Token to get new, valid, Auth Tokens for this user. When the user issues a voice command, the Auth Token will be passed as a field in the JSON to your fulfillment server, and you can use this to verify who the user is and that they are authorized to use your service.
I have an App Engine Standard project for API.AI fulfilment webhook. Users interact with my app through chat (Google Assistant) only—no Web interface. In summary, the app is a chat backend.
My app requires user's email to send updates. I read that I need account linking.
Based on this answer in SO, this is exactly what I did:
In GCP console → APIs & services → Credentials, I created new
OAuth 2.0 client ID, with Authorized redirect URI: https://oauth-redirect.googleusercontent.com/r/[my-project-id].
In Actions on Google console → Account linking, I chose Authorization code with:
Client ID and Client secret copied from previous step
Authorization URL: https://accounts.google.com/o/oauth2/v2/auth
Token URL: https://www.googleapis.com/oauth2/v4/token
Scopes: profile and email (initially I put fully namespaced, e.g. https://www.googleapis.com/auth/userinfo.email but somehow it got "shortened")
Testing instructions: A dummy Google account I created
In API.AI console → Integrations → Google Assistant, Sign in required for welcome intent is ticked.
The whole setup kinda works. Here's how it goes in the simulator:
Typed, "Talk to [my app]"
Received response, with login URL in the debug tab
Copy pasted the URL, login successful, redirected to Google home page
Back to simulator, typed: Talk to [my app]
Connected (auth code is passed in webhook calls, and my app can query user's email)
Two issues:
Why do I need to type Talk to [my app] twice?
My submission is rejected because "Your provided testing instructions either did not work correctly or were not substantial enough. Please ensure that you are providing everything needed for us to test your app, and that all credentials you provide work correctly."
Where did I do wrong?
EDIT: I tried using Android 6, it says "It looks like your [project] account is not linked yet," and there's a button to link. Upon clicking, it shows Google Account selector, but clicking it doesn't do anything (and no request to my server).
Is there a way to test with the Twilio Connect App? You can only authorize an app that is not a free trial account by logging in which authorizes the production account. You do not get a chance to authorize a test account. Because of that any calls you try to make with the Connect App test credentials fail because your test credentials are not authorized to use the other production account. Does anyone know of any workarounds for this?
Public Disclosure:
Never have I tried any of the two suggestions given by Twillio, neither have I tried to actually implement them in my account.
Option 1: Create A New Account - Stay In Trial:
You said:
"...You can only authorize an app that is not a free trial account by
logging in which authorizes the production account"
This negates a fully-written suggestion in Twillio's site. From Twillio's help-center:
Test credentials only provide a way for you to "pretend" sending a
message or making a phone call ... If you are looking for end-to-end
testing without being charged, we recommend that you create a separate
Twilio account and stay in the trial mode to take advantage of the
trial credits.
Option 2: Using Your Test Credentials In Production Enviroment:
You said:
"...Because of that any calls you try to make with the Connect App test
credentials fail because your test credentials are not authorized to
use the other production account"
This seems strange, as in production, your test credentials will work - although just for specific services. From Twillio's docs:
Supported Resources
Your test credentials can currently be used to interact with the
following three resources:
Buying phone numbers:
POST /2010-04-01/Accounts/{TestAccountSid}/IncomingPhoneNumbers
Sending SMS messages:
POST /2010-04-01/Accounts/{TestAccountSid}/Messages
Making calls:
POST /2010-04-01/Accounts/{TestAccountSid}/Calls
Requests to any other resource with test credentials will receive a 403 Forbidden
response. In the future, we may enable these resources for testing as
well.
Hope this helps a bit. Nevertheless, tell us what you came up with in your different trial and errors.
Good luck!
The answer is no you cannot. The account has to be authorized through the Connect App and Connect App will not authorize trial accounts. When it authorizes a non trial account, it creates a sub account for that account only viewed through their API. The Api does not return the Test Account Id for the sub account so there is no way to figure out what the Test Account SID would be.
Because the account you want to "test" with has to be a production account you will be charged. I talked to Twilio Support about this and they acknowledged what I ran into and gave me a credit to my account to play around with. I would not expect that for everyone but hopefully this will be resolved soon.