The Restricted Access Pattern in Solidity

The Restricted Access Pattern in Solidity

The Restricted Access to a Contract is a common practice. By default, a contract state is read-only, unless it is specified as public. We can restrict who can modify the contract's state or call a contract's functions using modifiers.

For a better understanding of restricted access pattern we will build a contract with modified restricted access with the following common write outs:

  • onlyBy - only the mentioned caller can call this function
  • onlyAfter - called after certain time period.
  • costs - call this function only if certain value is provided.

We will create a contract called RestrictedAccess with two variables owner and creationTime, and we are going to initialize them. We will set the owner to be the owner of the contract (msg.sender) and for the creationTime we are going to use a global variable (block.timestamp).

No alt text provided for this image

Now, let's create a function that can change the owner of the contract and name it changeOwner. The function will take an address as an argument and call it _owner, and It should return owner = _owner.

No alt text provided for this image

What if we want to restrict the address of the changeOwner function? We don't want anyone to be able to change the owner address. We only want the current owner to change the owner's address. To do this we can use a modifier - onlyBy. We will name it onlyBy and it will take as input an address. The modifier have a requirement that the msg.sender should be equal to the input of the _account. If it fails, then we can write a statement "Sender not authorized!"

No alt text provided for this image

The onlyBy modifier requiring the only person with this modification that's going to be able to do whatever they want to do has to be msg.sender has to equal that for whatever the account is. If it is not coming from the current caller, then it is going to fail.

In order to add our modification we have to take onlyBy and add it to our changeOwner function, and if we want to restrict the access of onlyBy to the owner, then we can add the owner address.

No alt text provided for this image

This should work for the owner, because we sent the owner to the msg.sender. Next, let's test this. We deployed our contract on the first account. Now, let's move to the second account, copy and paste it in the changeOwner and run the function. We can see in the console that it doesn't work, we got an error - "Sender not authorized!"

No alt text provided for this image

It was not worked because we sent from the second account, not from msg.sender. If we do the same thing, we keep the same second account in function (changeOwner), but we switch back to our first account and and run changeOwner again we will se a successful transaction in the console - we have successfully changed the account now.

No alt text provided for this image

Now, if we try again, it is not going to work anymore immediately, because the msg.sender was changed to the second account and we are still in the first account which is not longer the owner. If we will switch to the second account and repeat, it will work.

No alt text provided for this image

Excellent! That is the onlyBy - a common pattern in #solidity for restricted access. Let's move forward and take a look at the onlyAfter modifier.

We will use the same contract. First of all we will write a function that can disown the current owner. Let's say we only want the owner to be able to delete himself, we don't want other people to be able to do this. After this we will use the onlyAfter modifier to set a time period for the function until it will run.

No alt text provided for this image

Now let's allow this function (disown) to be executed after a certain period of time (for example 3 weeks) from the moment of contract creation (we have a variable called creationTime which gives us the current time of the creation). For doing this we will create a new modifier (onlyAfter) which will take an uint as input and name it _time. For the require we will write that block.timestamp should be >= the amount of _time, otherwise, if it doesn't run, we will receive the message 'Function was called too early!'.

No alt text provided for this image

After creating this modifier, we need to add our 3 weeks for the function disown to be able to disown the owner. For doing this we need to write onlyAfter(creationTime + 3 weeks) in our disown function.

No alt text provided for this image

Let's deploy. You can see that if we try to disown, we are going to see that "Function was called too early!"

No alt text provided for this image

To see what will happen after the set time period we will change to 5 seconds and redeploy the contract.

No alt text provided for this image

Now it works!

An finally, let's see what the costs restriction! We will create a modifier called costs which takes an _amount parameter and require that msg.value is greater than or equal to the amount. If the msg.value is not greater than or equal to the amount, then return a string that says "Not enough Ether provided!".

No alt text provided for this image

Next we will write a payable function called forceOwnerChange which takes an address called _newOwner. The function needs 200 Ether to set the owner to the contract to the new owner of the address.

No alt text provided for this image

Congratulations! We covered all three restricted access modifiers.

I uploaded this code to my?GitHub account.

See you in the next articles about #smartcontracts , #solidity , #remix , #blockchaindeveloper #blockchaineducation #bitcointechnology #ethereumblockchain .

Ion Platon

要查看或添加评论,请登录

Ion Platon的更多文章

  • Storage vs Memory in Solidity

    Storage vs Memory in Solidity

    Understanding the storage and memory is not always intuitive. Having a good understanding of storage versus memory is…

  • What is Mapping in Solidity?

    What is Mapping in Solidity?

    If you are coming from other programming languages, then is good to know that the solidity mapping is similar to a…

  • Struct and Enum in Solidity

    Struct and Enum in Solidity

    A struct is a collection of key->value pairs similar to a mapping, but the values can have different types. Structs…

  • What are Libraries in Solidity?

    What are Libraries in Solidity?

    Libraries are similar to Contracts, but are mainly intended for reuse. A Library contains functions which other…

  • What are Interfaces in Solidity?

    What are Interfaces in Solidity?

    Interfaces are similar to abstract contracts and are created using interface keyword. There are some characteristics…

  • What is Inheritance in Solidity?

    What is Inheritance in Solidity?

    Let's take a closer inspection at Inheritance in Solidity. Inheritance is an advanced concept in #solidity and also in…

  • Build First Cryptocurrency in Testnet using Solidity and Remix

    Build First Cryptocurrency in Testnet using Solidity and Remix

    Creating own currency is a great way not only to solidify our coding or solidify our knowledge of building of smart…

  • The Fallback Functions in Solidity. How gas costs work in Smart Contracts.

    The Fallback Functions in Solidity. How gas costs work in Smart Contracts.

    Let's take a look at Fallback Functions in solidity. We are going to open our eyes and become a little bit more…

  • Bytes vs Strings in Solidity

    Bytes vs Strings in Solidity

    Strings are values that are made up of ordered sequences of characters, such as "hello world!" A string can contain any…

  • Loops in Solidity

    Loops in Solidity

    Looping is a type of functionality in coding, which is very handy. Loops allow you to iterate through data and take…

社区洞察

其他会员也浏览了