I want to connect to my companies Twinfield data. The steps I've taken so far:
created developer account
created a client (client ID + secret) in the developer portal
No where do I link this / authorize this client to access my companies data? I see the option to request a test-server, but I don't need to - I simply want to query the data (on the production environment related to my organization).
The documentation is not making this any clearer - how do I proceed?
Related
I have been looking for documentation or tutorials which show what to do in order to allow a creator (who already has a connect account (it was created when he first authenticated)) to add the banking information necessary for him to withdraw funds from his connect account (transfer his funds).
How app works:
Creator makes an account like on patreon.
User subscribes to creator like on patreon.
How can I allow the express connected account add his details?
Here are some links I have gatherd but don't seem to contain info on how to:
https://stripe.com/docs/connect/express-accounts
https://stripe.com/docs/connect/charges#types
It depends on what type of Account.
Standard Accounts: https://stripe.com/docs/connect/standard-accounts#create-link
Express Accounts: https://stripe.com/docs/connect/express-accounts#create-link
Custom Accounts: https://stripe.com/docs/connect/connect-onboarding
For express accounts redirect users to stripes onboarding
I emailed them for info before I got this answer. I will include their info here:
I understand you would like to know how a user can input their bank account information on the client-side.
As per in docs Stripe will handle onboarding, account management, and identity verification for your platform, which means you can onboard users very quickly. This is done by using the OAuth connection flow, after this, your user will be able to connect to your platform.
You can test this by trying the sample we have using Rocket Rides. Also, here you will be able to find the demo’s source code.
On the other hand, if you are referring to updating this information after the onboarding, this is done by logging on the Express Dashboard, and you can achieve this by integrating with the Express Dashboard.
Extra info: https://stripe.com/connect/express
This is especially helpful: https://stripe.com/docs/connect/collect-then-transfer-guide
I have built a hyperledger-composer application (angular front-end, connecting to composer-rest-server), from which, so far, authentication is missing.
Here is what I understand:
1.) An identity needs to be issued for each participant in the network
2.) A business network card needs to be created for the identity created in step 1.)
3.) The business network card needs to be added to the wallet of the rest server
4.) steps 1.) and 3.) can be done by calling REST endpoints provided by the REST server
What I don't understand is this:
Let's say the REST server has in its wallet a business network card for "John Doe". The business network card contains the participant ID and the associated identity.
Google OAuth2.0 is used for authentication.
When John Doe wants to login to the hyperledger-composer app, he is redirected to google, where he is asked to type in his google account email + password.
If the business network card contained John Doe's google account email (or his google account password), then a connection could be made between the business network card and the user (John Doe) trying to log in. But the business network card does NOT contain any information from John Doe's Google Account (neither email nor password).
So how can the application know that the user trying to log in has a business network card and is therefore eligible to log in? As far as I can see it, all the application can know is that the user trying to log in has a google account - but this does not mean that he/she also has a business network card and is hence eligible to use the application.
Put differently: I don't understand how OAuth2.0 can help with authentication given that the OAuth2.0 provider does not save any data from the hyperledger-app (such as participant id or identity) and the hyperledger-app does not save any data from the OAuth2.0 provider (such as Facebook user name or Google Account email).
Enabling OAth2.0 merely requires you to login first through your account before accessing the REST server, but does not actually connect to any wallet or participant. So it doesn't have too much use at this current state (in my opinion).
The workaround I've done is building a Node.js app with Passport and adding the desired authentication strategies, then when a user is created through Passport it also creates a participant on the composer-rest-server and links them.
How can I create a new user account with username/password to authenticate against composer-rest-server?
How would I authenticate with this newly created user account against composer-rest-server?
How would I manage the session for that user?
How can I map this user to a network participant?
Can composer-rest-server user be mapped to more then one network participant (i.e. perform different roles)?
Do I need to create a wallet for each composer-rest-server user?
How would I share wallets across number of instances of composer-rest-server?
In Composer, you can model participant types, such as org.acme.Person. You can then create instances of those participant types, such as org.acme.Person#simon, and those instances are stored in participant registries.
You can then issue an identity to an instance of a participant. This process generates an enrolment ID and secret that can be sent to that participant so they can enrol. One identity is linked to one participant, but one participant can have multiple identities.
When a participant enrols using the enrolment ID and secret, an enrolment certificate is generated and placed into their wallet (configured using the keyValStore property in the connection profile). Once the enrolment certificate has been generated, the enrolment secret is made invalid. The secret can be only used one time - it is not a password.
If an enrolment certificate already exists in the wallet, then enrolment secret is not used. We have planned some future changes to make the enrolment secret optional in all APIs and CLIs so you can omit it.
When that participant submits a transaction using that enrolment certificate, the Composer chaincode extracts the enrolment ID from the enrolment certificate, and uses it to look up the participant instance that the identity was issued to. This is the "current participant".
All Composer based access control, using the rules defined in permissions.acl, is based around the current participant.
Currently, the Composer REST server supports a single enrolment ID which is specified on the command line at startup. All REST API calls to the Composer REST server use this enrolment certificate to submit transactions.
There is work being done at the moment to improve this:
https://github.com/hyperledger/composer/issues/142
Please read this GitHub issue in detail. Since this work is still in-progress, there is no user documentation for configuring Composer REST server security.
There are some interesting requirements in your list:
How would I manage the session for that user?
There are API keys, but there is no easy way to retrieve or manage API keys. I have ideas about extending the REST server UI (Swagger UI) to manage API keys, but nothing concrete yet.
Can composer-rest-server user be mapped to more then one network participant (i.e. perform different roles)?
A users wallet can currently contain multiple identities, but only one of them is used by default. The user can choose the default identity by submitting a REST API call. Is that sufficient?
Do I need to create a wallet for each composer-rest-server user?
Each user has their own set of wallets. A default wallet is created when the user logins for the first time. A user can create multiple wallets, but only one of them is used by default. The user can choose the default wallet by submitting a REST API call. Are you looking to share wallets between users?
How would I share wallets across number of instances of composer-rest-server?
You need to use a persistent data store such as MongoDB to persist the wallet data across multiple instances; again, this is work in-progress and not yet documented.
I suggest that since this is in-progress work we move the discussion to the GitHub issue :-)
I am attempting to get get a Ruby on Rails project that uses the Google AdWords API.
What I did so far, following the steps in this guide:
I created an AdWords Manager account.
I created a test account that is part of the AdWords Manager account.
I set up the Ruby client library in my Rails project.
I then attempted to set up OAuth2 authentication with the example code from the guide.
However since the guide was written (and the video version of the guide was made) it seems that the interface has changed. I am able to create a Client ID client_secrets.json-file, or a Service Account .json file. I am able to export these and read the settings from .
I added the required settings, using an OAUTH2_SERVICE_ACCOUNT .json file.
Now, when attempting to connect, I get back the AdwordsAPIException AuthenticationError.NOT_ADS_USER.
I therefore know that the actual authentication works. However, the authorization does not.
How can I turn on AdWords API support for the oAuth credentials from my google accounts? The Google Credentials Console lists many APIs that you can turn on, but the AdWords API is not in there. The AdWords guide does not mention turning on an API at all, and only tells you to create a new Credential.
What is going on here?
The Adwords API does not need to be added to your project in the Google Cloud console (it's always enabled)—as indicated by the error message, the actual problem lies in the fact that your service account does not have access to any Adwords accounts.
As a matter of fact, the only way to use service accounts to authenticate against the Adwords API is when you're also using a G Suite domain (see the corresponding documentation, section "Prerequisites".
If you have a G Suite domain, you'll need to
Enable "G Suite Domain-wide Delegation" on your service account key
Add the project ID of the Google cloud project to your G Suite domain's authorized API client list
Use your service account to impersonate any user from your G suite domain that has Adwords access
As you can see, it's quite an involved process. My recommendation (that is shared by the above article) is to use an OAuth2 installed application flow for any user that has Adwords access. This requires to store the obtained refresh token on your end, but is more flexible (and arguably safer) than a delegation-enabled service account and easier to set up.
I have an account on intuit with 3 companies. When I want to grant access to my dev app for two companies I am only allowed to access the last one that I got access tokens for. So if I connect Company#1 I can access data fro Company#1 but if i connect Company#2 I can only access Company#2 data but not Company#1. If I request OAuth tokens for Company#1 again I can access Company#1 data but not Company#2 and I need way to access data for both companies.
Thank you.
This is a known issue. Intuit Anywhere currently doesnt support multiple company files for the same user, You need a new Oauth Access token to load the blue dot menu for the company who's context you want to show.
update 11/6
This issue will be resolved in a release during the week of November 26th.