I have Ethereum account (#/Eth).
I use TestRPC and Truffle
0xb1c38c605b8468cea3fc51e204098659c666b8b9/41.86142259999994
0x7c6b249c8b721845df50d60c3a6eda75db36212a/41.86142259999994
0x2d8e958af078aba822a73d6bac8b1d116d5769fa/41.86142259999994
0x24c236cb31704b5a20c39ff165543ce9a058924a/41.86142259999994
I want transfert Ether from 1° account to the 2° account.
I try :
web3.eth.sendTransaction({from: '0xb1c38c605b8468cea3fc51e204098659c666b8b9', to: '0x7c6b249c8b721845df50d60c3a6eda75db36212a', value: web3.toWei(3, "ether")})
But all account are debited :'( Why ?
0xb1c38c605b8468cea3fc51e204098659c666b8b9 38.86142259999992
0x7c6b249c8b721845df50d60c3a6eda75db36212a 38.86142259999992
0x2d8e958af078aba822a73d6bac8b1d116d5769fa 38.86142259999992
0x24c236cb31704b5a20c39ff165543ce9a058924a 38.86142259999992
Related
I have this account:
#[derive(Accounts)]
pub struct SignupEmployee<'info> {
#[account(init, payer = company_account, space = 8 + 32 + 32)]
pub employee_account: Account<'info, EmployeeState>,
#[account(mut)]
pub company_account: Signer<'info>,
#[account(mut)]
pub authority: Signer<'info>,
pub system_program: Program<'info, System>,
}
And this test function
const employeeAccount = anchor.web3.Keypair.generate();
await program.rpc.signupEmployee({
accounts: {
authority: provider.wallet.publicKey,
companyAccount: companyAccount.publicKey,
employeeAccount: employeeAccount.publicKey,
systemProgram: SystemProgram.programId,
},
signers: [employeeAccount, companyAccount],
});
What I want to achieve is to make the company pay for the employee signup.
Basically on my system I will have both the keys of the company and the keys of the employee.
The employee will signup with his key and the company would have to pay for the transaction.
I see that the signers is an array, so I imagine that I can enter both, the company and the employee accounts.
How can I achieve this?
The Transaction object in the solana web3 package has a feePayer field which you are supposed to set to the public key of the account you wish to pay for the transaction. Then that account needs to also sign the transaction.
Feel free to look into the documentation for the Transaction class here
in your instruction you already assigning company_account as payer for the new account initialisation, so i'm assuming that you are wondering how to pay gas fee with the same account. You could use program.instruction.signupEmployee which will output transaction instruction that you could add to the custom transaction where you can specify a gas fee payer. This way you would need to sign and send transaction using your custom code.
Question same as the title, i want to know if a role and assume a role that can assume another role.
Example:
Role A. A Role that is trusted by an external account and it a policy that can assume any role
Role B. This role is assumed by A and it also has a policy that can assume Role C.
Role C. This role has policy that can access S3 bucket for example.
Yes, you can make roles that assume roles. The process is called Role chaining:
Role chaining occurs when you use a role to assume a second role through the AWS CLI or API.
The key thing to remember about this is that once A assumes B, all permissions of A are lost temporary, and the effective permissions are of the role B. So the permissions of roles A, B and C do not add up.
Idea of Role Chaining:
You get the session of every Role in the Chain, then pass each one to the other, until you reach to final Role, which you will pass to it the final session(session of the role before it) and get the Client you want as s3, iam on the final_target_account.
Scenarios for making Account-Cross-Origin using Role Chaining:
if you have three accounts(main_acc --> second_acc --> third_acc), and you are in your main account and you want to reach to the third account, but you cannot do so, only if you assume a role in the second account(cuz the second account is in the trust-relationship inside the role of the third account) to be able to reach to the third account role, that will give you permissions to do whatever you want to on the third account.
You need to have control on the child accounts under an organization account (which is in a control-tower and acts as the main control-tower account 'payer-account'), to be able to create any resources or infra-structure inside them, here you can assume the role of the Oragnization_main_account(payer), then from there assume the role inside the child_account, then do what you want directly on each child account in the organization.
-Note: There is a Role created by default from AWS side on the child_organization_accounts called AWSControlTowerExecution, please refer to AWS Docs.
How to Role Chaining using AWS Boto3 API:
def get_role_client_credentials(session,
session_name,
role_arn,
external_id=""):
client = session.client('sts')
if external_id:
assumed_role = client.assume_role(RoleArn=role_arn,
RoleSessionName=session_name,
ExternalId=external_id)
else:
assumed_role = client.assume_role(RoleArn=role_arn,
RoleSessionName=session_name)
return assumed_role['Credentials']
def get_assumed_client(session,
client_name,
role_arn,
session_name,
region,
external_id=""):
credentials = get_role_client_credentials(session=session,
session_name=session_name,
role_arn=role_arn,
external_id=external_id)
return session.client(client_name,
region_name=region,
aws_access_key_id=credentials['AccessKeyId'],
aws_secret_access_key=credentials['SecretAccessKey'],
aws_session_token=credentials['SessionToken'])
#### Role Chaining ######
def get_role_session_credentials(session,
session_name,
role_arn,
external_id=""):
client = session.client('sts')
if external_id:
assumed_role = client.assume_role(RoleArn=role_arn,
RoleSessionName=session_name,
ExternalId=external_id)
else:
assumed_role = client.assume_role(RoleArn=role_arn,
RoleSessionName=session_name)
return assumed_role['Credentials']
def get_assumed_role_session(session,
role_arn,
session_name,
region,
external_id=""):
credentials = get_role_session_credentials(session,
session_name=session_name,
role_arn=role_arn,
external_id=external_id)
return boto3.session.Session(
region_name=region,
aws_access_key_id=credentials['AccessKeyId'],
aws_secret_access_key=credentials['SecretAccessKey'],
aws_session_token=credentials['SessionToken']
)
- Use the Above helper Functions This way:
role_A_arn = f"arn:aws:iam::{second_target_account_id}:role/RoleA"
assumed_Role_A_session = get_assumed_role_session(session, role_A_arn,
default_session_name, region, external_id="")
role_B_arn = f"arn:aws:iam::{third_target_account_id}:role/RoleB"
assumed_Role_B_client = get_assumed_client(assumed_Role_A_session, 's3', role_B_arn, different_session_name, region, external_id="")
assumed_Role_B_client.create_bucket(Bucket='testing-bucket',
CreateBucketConfiguration={
'LocationConstraint': f'{region}'
})
I have User and Buyer participants on the network. Generally, the buyers cannot READ the user's data but I want to make GrantAccess and RevokeAccess transactions so the Users to have the option to grant and revoke the READ access from Buyers
I haven't been able to find anything on how to do this, would appreciate any help.
You would run a 'tx_GrantAccess' transaction that firstly, updates a particular BUYER's record (eg. id buyer123 - a participant modeled with a field called access, which is set to true by this transaction).
I can use a condition match (as a boolean) on the target BUYER records (resources) and if the BUYER, say buyer123 (ie that's accessing the business network) has access=true then he can READ the USER records.
Transaction rule (needed by User to access the transaction classes)
rule rule_1 {
description: "grant access to User, for the 2 x Transactions themselves"
participant: "org.acme.example.User"
operation: CREATE
resource: "org.acme.example.tx_*"
action: ALLOW
}
User Access rule:
rule rule_2 {
description: "if granted access, allow READ of User by buyer"
participant(m): "org.acme.example.Buyer"
operation: READ
resource(v): "org.acme.example.User"
condition: (m.access)
action: ALLOW
}
where Buyer has a field (eg.
participant Buyer identified by id {
o String id
o Boolean access default=false
}
and your transaction tx_GrantAccess has a function that will set access to true on a particular Buyer's record and tx_RevokeAccess will set it to false etc.
I use amazon-product-api NPM.
var amazon = require('amazon-product-api');
var client = amazon.createClient({
awsId: "aws ID",
awsSecret: "aws Secret",
awsTag: "aws Tag"
});
What is awsTag?
It is Associate Tag
An AssociateTag is an alphanumeric token distributed by Amazon that
uniquely identifies an Associate. Amazon uses this ID to credit an
Associate for a sale. The AssociateTag parameter becomes part of the
PurchaseURL, which is the URL used to purchase the items in a remote
shopping cart
.
I am using Django app djStripe to work integrate Stripe into my Django app to allow users to subscribe to plans and pay using Stripe.
I want to have a zero dollar plan but create a Stripe customer account so in future using can just change subscription from zero to a paid plan, and then they will be asked for their credit card info.
This is acceptable in Stripe and according to Stripe a zero dollar subscription does not ask for credit card though it does create customer. However, djStripe does ask for credit card with a zero dollar plan.
djStripe readthedocs does hint at custom plans being the solution but I am need help to determine if
a) that is indeed the way and
b) if yes to a), then how to implement.
I've setup the plan in my app's Settings.py as follows:
DJSTRIPE_PLANS = {
"starter": {
"stripe_plan_id": "starter",
"name": "Starter",
"description": "Starter subscription.",
"statement_descriptor": "Starter co",
"price": 0, # $0
"currency": "usd",
"interval": "year",
"trial_period_days": 0,
"team_size": 2,
"image_count": 1000
}
}
I haven't customized any of the standard djStripe subscription process.
First of all add trail period in the plan, because without a trial period stripe tries to charge the customer for that it requires a credit card info. Subscribe to customer.subscription.trial_will_end stripe will send this webhook three days before the trial expires and on that event update trail for customer.