I am sure that a contract address can be deterministically created using msg.sender and nonce.I read that they used RLPEncoding in python https://ethereum.stackexchange.com/questions/760/how-is-the-address-of-an-ethereum-contract-computed/47083#47083. But I am unsure how to do that in solidity.
function createAddress(address creator, bytes nonce) public returns(address conractAdd) {
//SomeBody help me writing this part
}
new contract address depends on the current address of the contract and nonce of the contract that you are creating based on shared link. nonce is counter maintained internally by a contract referring to the number of contracts
created by it but unfortunately it is not available within the contract. So you cannot create address without nonce.
Even though, contract creating address depends on the parent contract address and the nonce of the contract, there must be other variables that creates the contract address. because, if you want to create two separate contract's address in same contract. contract address will be same and it is likely that nonce of the contracts that you are creating might be same as well, because nonce is essentially just a scalar number. In this case you would be creating same contract addresses.
Related
I am new to sipp and network concepts i got a contact header
"Fin Tax" <sip:b2fdfc58-b7f2-a482-572c-8dbc1aae24#10.195.1.41:5060>;+
"ip.instance="urn:uuid:00000000-0000-0000-0000-34db8dc64>";+
u.sip!devicename="ATA34DBFD8DC64"4DBFD18DC64";+u.sip!model.cc.co.com="681"
Can you explain this contact paramerter i know the first part uri but what are next parameters
First parameter is +sip.instance (the double quote after + in the example above is a typo for sure), which is defined by IETF, it can be found in SIP Outbound (RFC5626) and GRUU (RFC5627):
https://www.rfc-editor.org/rfc/rfc5626
https://www.rfc-editor.org/rfc/rfc5627
Its purpose is to identify uniquely a device, independent of contact address (which can change in case of roaming around wifi hotspots or 4G/5G networks) or multiple connections, but contact addresses can also overlap when devices are located in private networks using same IP range.
Usually its value is build using a UUID (universally unique identifier), which should reduce the risk of duplicate values for users with multiple devices. Its uniqueness allows SIP Registrar Server to identify what contact record to update or remove when processing REGISTER requests from the same device.
The next two parameters prefixed with +u.sip! seem to be custom parameters set by the sending SIP UA. They look like specific to some CISCO equipment, probably a gateway. In general, SIP specifications tell that custom parameters can be ignored by receiving UA, if it does not know how to interpret them.
I have an SaaS application in the pipeworks.
One of the things that has me a bit confused is the best way to manage the stable of Austalian suburb and state data across multiple databases (this applies to any country as each country has a list like this).
For example in Australia you have Australian Postcode list that links all the postcodes to the suburbs and you can use that to create a dropdown for state, suburb and postcode etc.
An example of the CSV of australian postcodes can be found HERE.
So you can upload a csv file for example but the problem remains..
Whats the best way to hold this data.. its common to all databases where you have a person, client, employee etc..
Do you replcate it in each database? Is there a better way than having redundant stores of data..
Best way to implement it..
There are several options and considerations I would look at for this problem. Some considerations:
Number of address rows expected
Whether a client database is concerned with prefill/validated international addresses
Whether the client system is web connected or can operate in isolation
Are these databases/systems hosted by you or distributed to individual clients? (SaaS implies "Web" and "Hosted by You" to points 3 & 4)
How critical address integrity is.
For smaller systems, a simple option for address systems is to de-normalize the address data (state, postcode, suburb) and consider using a central lookup database/service, either under your own control or a third party. The denormalized address table would contain the text fields for the State, Postcode, Suburb etc. rather than FK values (stateId, suburbId, etc.) This avoids needing to store lookup tables in every client DB, just one Lookup DB or leave that to a 3rd party service.
The advantage of a third-party lookup is that keeping it up to date with new areas and changes is handled for you. Third party services would require a web connection, and you have to factor in the risk of their service being down or a web connection being unavailable. Larger systems with millions of addresses might benefit from normalizing the address table, so the "cost" of replicating suitable address lookup tables might be worthwhile. You can still a central service to look up addresses, then resolve whether the client DB already has a StateId, SuburbId etc. for the respective state/suburb for that post-code before inserting one if necessary. (Cutting down the number of rows each client DB needs to address values that are actually used)
In that last example you might have lookup tables for State and Suburb linked to PostCodes, linked to Country. Country would default to the target, maybe be an optional selection for international addresses. The user provides a post code to the service which returns suburbs, they select a suburb. The address validation service could go as far as to validate the street address. When you're happy an address is "valid" and ready to be saved, you search your local State, Suburb, (even Street) tables for matches for that PostCode, if found use those FKs, otherwise insert new entries and link the FK.
Using a separate service, or services would be my consideration especially if you need to support validating/storing international addresses. For instance if the client is in Australia but regularly has address information for New Zealand. Storing entire address validation tables could get rather large if clients could be resolving addresses for many countries. (I.e. European countries and neighbours) You can write a Façade service to support different 3rd party address validation providers and/or homemade implementations with a standard interface.
If a system has to operate in isolation of an internet connection then you'll probably be stuck with each database having one or more local data sources to resolve address information.
Data integrity of address information is a separate concern you might want to consider. In some systems you need to validate that an address is recognized and don't want to allow invalid combinations or detect unexpected changes. Services that validate a particular address can provide unique IDs for an address that you can store as part of your address information. (These often tie into geocoordinate solutions where you want to quickly direct a map service to a particular location) Alternatively, if you successfully look up an address then validate that the address information is valid, even if just the country, post code, and suburb, you can create and store a hash of those values to check for tampering. (I.e. someone or some system changed a field to make the address invalid, the combined address won't match the stored hash) Addresses can be checked before use and flagged if not valid.
When a Cardano address is entered for payment, Daedalus identifies it as a valid address immediately. Even if there is a single character change, it shows it as an invalid address. Were are these addresses stored and how it is identified as a valid address.
There are two verification mechanisms, giving a certain level of certainty it's a valid address.
First, the wallet software can check it's valid address discrimination: Cardano Shelley mainnet addresses start with addr...
Second, the address - being a bech32 encoded string - has a checksum. This checksum for the given string length is not fully bulletproof but in almost all cases allows an instant offline validation for the given address.
I want to generate addresses in the code of my application and then make transactions from these addresses. To sign transactions - I need some waves on this accounts. But how can I get the address, knowing only it's seed?
A first question would be to ask what progamming language are you using?
My favorite is pywaves.
In pywaves it is as easy to create a address from your seed by executing following code:
myAddress = pw.Address(seed='put your seed here')
This library knows how to convert the seed into an address object. From there you can execute actions on the object. If you want to get your address back as a string you can use:
myAddress.address
There are also other library's like wavesJ or similar javascript/C++/.. library's, however I don't have a lot off experience with those.
There are some restful apis, as follows:
api/v1/billing/invoices/{invoiceNumber}
api/v1/billing/transactions/{transactionNumber}
And, each invoice or transaction belong to a specific account.
When implementing the restful apis, we must meet: Each account can only view their own invoice or transaction.
How should we isolate the data in restful apis?
Of course, we can pass the account number to the api, such as:
api/v1//billing/invoices/{invoiceNumber}?accoutNumber=XXX
api/v1/billing/{accountNumber}/invoices/{invoiceNumber}
But the Invoice Number has been able to uniquely identify a resource. So I do not want the problem to be complicated.
Is there any other way to solve this problem?
You are mixing a lot of things here.
This is not a REST problem, this is a security problem. More precisely, it's a OWASP top 10 2013 Insecure direct object vulnerability.
Let's make it simple: you have a URL like this
.../superSensitiveStuff/1
and you want to prevent the owner of "1" from accessing to ".../superSensitiveStuff/2"
To the best of my knowledge, there are three ways of dealing with this issue:
enforcing integrity in request URLs. This strategy does not apply to all cases, it only works in those scenarios where the client issues a request to a resource previously communicated by the server. In this case, the server may add a query param like this
.../superSensitiveStuff/1?sec=HMAC(.../superSensitiveStuff/1)
where HMAC is a cryptographic HASH function. If the parameter is missing, the server will drop the request and if it's there the server will be able to verify that it's exactly the authorized URL because the HMAC value guarantees its integrity(for additional infos, hit the link above).
using unpredictable references. The problem here is that a user can guess another id. "uhmm... I have the resource number 1, let me check whether the resource number 2 exists". If you drop sequences and move to long random number this is very hard to do. The resource will become
.../superSensitiveStuff/195A23FR3548...32OT465
This is good because it's effective and cheap.
exploiting a mixed RBAC-ABAC approach. RBAC stands for Role Based Access Control and this is what you are using. The leading A of the second acronym stands for Attribute. This means that access is provided on the basis of a user role and an attribute. In this case is the userId, since it must be authenticated for accessing private resources. In few words, when a user requests a specific .../superSensitiveStuff resource it is loaded from the repository when you have the ownership information for that resource. It could be a DB, for example, and your SuperSensitiveStuff java business model could be like this
public class SuperSensitiveStuff {
private String userId;
private String secretStuff;
...
}
now, in your controller you can do the following
String principal = getPrincipal(); //you request the logged userId
SuperSensitiveStuff resource = myService.load(id); //you load the resource using the {id} in the request path
if (resource.getUserId.equals(principal))
return resource //200 ok, this is an authorized access
else
throw new EvilAttemptException() //401 unauthorized, cheater detected