How to register USER in my Smart Contract using Solidity?

Question

I can't figure out how do we register user in smart contract and get the userdata when he/she tries to login after register through our website..I didn't see any article regarding this..Kindly enlightened me..

Answer 1

how do we register user in smart contract

You're struggling to find this description because the task is already done for you, depending on what you mean by the process of "registering".

get the userdata when he/she tries to login after register through our website

This is full of hidden assumptions and ambiguities.

• who/what gets the userdata?
• tries to login (to what?)
• register through our website (why is that necessary?)

In my experience, this mode of thinking is normal when experienced developers try to apply centralized, server-based thinking to smart contracts and blockchains.

Here are two questions to help you think it through with more precision:

• From a user perspective:
  • why should a server even exist?
  • should the owners of the server have access to more information than other users?
  • should the owners of the server have more privileges than other users?
  • why?
• In terms of establishing a trustless design, if a server has a special role:
  • what properties of the system are decentralized?
  • what are the limits of the server's privilege and what responsibilities are centralized?
  • why is that important?
  • what are you using the blockchain for that cannot be accomplished with a server-based solution?

As additional food for though, you can think of your requirements in two categories.

• properties that are subject to frequent revision or arbitrary changes
• properties that will be cast in cement as unbreakable laws of your application universe. These are the guarantees that make the system most trustworthy than a centralized system.

A server is generally regarded as a single point of failure if one is aiming for a decentralized, always-on solution. This is sometimes treated as an acceptable defect with limited impact. For example, a user interface served from a domain name, that could, if necessary be delivered by other means without hurting the underlying system. Another example is caching and analytics where the blockchain is the system of record and the offchain datastores could, in theory be replicated by anyone.

Contracts have no inherent need for a login or a registration. Every visitor, new or returning is already authenticated and initialized from the perspective of a smart contract. For example:

mapping(address => User) users;

... where User is a struct with the properties of a user - all reliably initialized to zeroish values. When you say "register" it's important to explain why this default state is unacceptable (there are valid reasons for that) and whether this should be an on-chain or off-chain concern and what, if any, sources of authority are involved.

I have found it illustrative to point out a hidden assumption that often comes up. It is sometimes assumed that the topology is similar to a backend service, like:

User => Website/Server => Blockchain

More commonly, it is:

    User
  /     \
 /       \
Server --- Blockchain

• User gets UI from server
• User signs transactions to contracts
• Server listens to contracts for updates
• Server signs transactions to contracts
• Users listen to contracts
• User sends information to server

When you think about the data flowing around in a triangular topology it can help clarify what goes where and why and the overall choreography. You'll be able to reason about the centralized and decentralized aspects of the design and the inherent assurances (and weaknesses) baked into the design.

Consider an "only authorized users" scenario:

struct User {
  bool isApproved;
}

modifier onlyApproved {
  require(users[msg.sender].isApproved, "You are not registered.")
  _;
}

function doSomething(uint amount) onlyApproved ...

Such a design implies someone does the approving. Maybe the "owner', using the Ownable pattern.

function workWithUsers(address user, bool isApproved) onlyOwner {
  users[user].isApproved = isApproved;
}

That input could indeed come from a server that is gathering info and performing some sort of process, e.g. KYC. The contract design spells out very clearly that there is an external authority that has complete control of which users are allowed to use the contract. Nothing else about the users needs to be in the contract (and visible to the whole world).

Hope it helps.