I need my customers to pay for their accounts on their own website. Using only the API how do I add access to any domain of my choice to pay using my payment form? I already have everything setup where their user and card are setup on Square's accounts though I'm having issues with the form working on their website domain names.
When submitting the form the part that requests the nonce encounters the following:
Invalid postMessage origin: "https://www.example.com"
Related
Has anyone else had a problem integrating Google's Address Validation API into Magento 2's Avalara Avatax? It's almost as if the API key is restricted. Although it's currently unrestricted. Our shipping and handling/tax amounts are all off. I think it's because the address isn't being validated by Google's new address validation system for Avalara Avatax (Using Ma agento 2 website platform).
Just looked at what I thought the API key was that the developers used and it appears to be unrestricted. Also, I checked the configuration panel on Magento admin and it appears to be correctly set up.
https://developer.avalara.com/api-reference/avatax/rest/v2/methods/Addresses/ResolveAddress/
Google's Address Validation API can be used with API keys or OAuth 2.0 service accounts.
In either case, the API project must be set up with both billing and the Address Validation API itself enabled.
The Address Validation API only supports two types of API key restrictions: IP address and API restrictions. Other types of API key restrictions are not supported.
If all the above checks pass and the Address Validation API still does not accept your API key, I recommend you contact the support team for 1:1 assistance.
I have a main website example.com, develop using Laravel. This website also provide a personal page for subscribed users at example.com/user1, example.com/user2, etc.
Currently, I control the access by URL, by verifying the username in the URL if the user is active or not.
However, I'm planning to give the URL its own domain. I have read about using DNS & htaccess, but it has to be done manually for every single user. I'm planning something that can be control programmatically.
Is there a way to automatically authenticate the google javascript api client, without user interaction?
Something like this:
User loads webpage -> webpage automatically signs in into a predefined user account -> api calls get executed
Basically i want to prevent the popup where you have to select an account and sign in to it. As the account which will be signed in is always the same.
EDIT:
pinoyyid answer looks promising and is what im looking for. But this only works if the user has signed in with an account at least once, if im not mistaken.
Now i dont want to use an account supplied by the user, but a predefined account which i am the owner of and sign this account in.
Im not entirely sure if this is even possible, as i have to provide the password/some authentication code to google and somehow do this in a secure way.
Use Case: The website will create a Youtube Broadcast via the Youtube Data/Livestream API for the specified account.
Yes you can do that. Referring to https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow
there are three pieces of information that will get you where you want to be:-
The OAuth URL can include a login_hint which is the email of your intended user
The OAuth URL can also include prompt=none which will do its work silently
This all needs to run in an iframe because this is based on origins and redirects.
==EDIT==
If the requirement is for a browser client to connect to a Google Account other than that of the browser user, then this is not possible. It's kinda obvious really that to do so would require a credential in the browser which by definition is not a secure environment.
The approach I would take would be to use a service such as Lambda or Google Cloud Functions (or whatever marketing name they have this week) to create a proxy for the corresponding Google API using a credential stored server-side.
I am using the Plaid Link javascript library but I am running into an issue. I want to be able to use both the Auth and Connect products but the Link modal only allows me to show either Auth or Connect but not both. The documentation says to use Auth and then upgrade my token to use Connect. Which is fine I can do that. However the Auth modal will not show any credit only institutions like AmEx. Since I want both to allow for Stripe integration and for pulling in all of a user's transactional data across all institutions, what's the best way to do this?
Currently I am considering showing the different modals in two different flows (add a bank account vs add a transaction history account) but that is not very good UX. Also the IDs assigned by Plaid will be different and have different access tokens so deduping is a nightmare.
Or writing a custom modal that will use the Auth product for institutions with bank accounts (Chase) and the Connect product for credit only institutions (AmEx) but that will likely be a lot of work.
You'll only be able to use the Plaid Link + Stripe ACH integration for institutions that support Auth. I'd recommend initializing Link with Auth as the product and then upgrading to Connect once you have exchanged the Link public token for a Plaid API access token.
To answer the UX question you brought up - you can actually bypass using Link's standard "institution select" view and instead display your own list (you can use the /institutions API endpoints to pull information about supported institutions) using Link's custom integration.
That way, you can show your users a single list of supported institutions. If you initialize Link twice (once with Auth and once with Connect) you can jump directly to the Auth-initialized Link or Connect-initialized Link depending on the user's institution.
I made a members-only site that uses Google oauth2 to authorise users. The site is built with the Laravel framework and Artdarek's oath library.
When the authorization callback comes from Google, I lookup the user record in the DB by email and proceed to the protected page if the record exists, otherwise to a register page.
The problem is some of our members use two Google accounts. One user registered via his primary account (e.ge. a#gmail.com). The next day he returned and mistakenly tried to login with b#gmail.com. Naturally the system showed him the registration page. From that time on each time he visits the site the authentication mechanism sees him using his second (unwanted) set of credentials.
To resolve this one case I instructed him to logout of all accounts (on both sides), clear cookies and start from scratch but this is not a practical solution for all users. In same cases even this measure does not seem to correct the problem.
How can I solve this case? What is the right way to request oauth authentication and get them back from the right account? Can I force Google to ask the user with which account to proceed?
Google will automatically ask the user which account they want on an oauth request if they enable the account chooser.
I have logged into my Google Apps and my Google account, so for me on an oauth request, I get the following prompt:
In order to do the same for your user, they have to click "Stay signed in", but of course this is not advisable for public computers.
Beyond the above, I'm afraid not much can be done. - if they logged in with a#gmail.com at that time, these are the credentials you will receive.
They way I solve this problem is to have a field where the customer can add additional emails, and select one that is primary. I will then inspect against these emails when a request comes in to avoid duplicate user accounts.