Why We create Temporary User Before Actual User

In secure web application with genuine user, we don't create direct object of User at a time of user sign up instead of at the time user sign up on your application we create a temporary User Object in which we store only some fields of user which are taken at a time of sign up. (Example : name , email Id , password,contact no).
We provide option of user verification through email or mobile number.
When user verified himself on your application then we create the Object of User and persist in database with all fields and give his all functionality of Users. (Example : check balance , update profile ,update Information and many more).
Creating a temp object of user and store in database it gives lots of benefit and these are.
  •  Security : no unsecured or unverified user exist.
  •  Fetching Speed : many users only sign up on application not used it so unnecessary user data not store in database.
  •  Safety From Attackers : if any one create a loop of 1000 times and signup through rest API continuously then waste user data  are  not store in actual User table.
It Store in TemporaryUser table so this type of activity will not affected our application.
If we create any Bank application or secure application its most considerable things is existence of verified user. User verification can be done  by either  user email Id or user phone number.
Email Id and phone number is a easiest way of verify any type of user in secure way and this verification process is also provide safety from hackers. 
If hackers try to sign up our application through looping code then it will quit difficult to user (email and phone) verification through  code and hacker continuous signup request not affect our application because we store User object in TemporaryUser Object before verification. 

Comments

Post a Comment

Popular posts from this blog

JIT Compiler

Image
The Just-In-Time (JIT) compiler is a component of the Java Runtime Environment that improves the performance of Java applications at run time. Java programs consists of classes, which contain platform neutral bytecode that can be interpreted by a JVM on many different computer architectures. At run time, the JVM loads the class files, determines the semantics of each individual bytecode, and performs the appropriate computation. The additional processor and memory usage during interpretation means that a Java application performs more slowly than a native application. The JIT compiler helps improve the performance of Java programs by compiling bytecode into native machine code at run time.  Nothing in the JVM affects performance more than the compiler, and choosing a compiler is one of the first decisions made when running a Java application whether you are a Java developer or an end-user. The JIT compiler is enabled by default, and is activated when a Java method is c
Read more

Authentication using One Time Password (OTP)

Image
The point of two-factor authentication is to prevent attackers from getting access to your account. Two-factor authentication requires that two tokens be provided for proof of ownership of the account. The first token is something that we're all familiar with- a username and a password. The second token is a bit more elusive, however. It should be something you have, and only you. No one else should be able to come into possession with the same token. The same should be true for usernames and passwords, but we've seen how easily broken a single-factor authentication system is.  The traditional way of just memorizing the password to validate one’s identity is not enough and web sites and applications are now expecting one to possess email Id or a smartphone to communicate with another short-lived randomized password, One Time Password (OTP) , as one more factor to the authentication. The first approach in the implementation of the two factor authenticati
Read more

JWT to Secure REST API with Spring Boot

Image
JWT Working Flow T o Secure your Rest services and the way to handle users Authentication/Authorization, First Approach is sending basic HTTP auth headers (username/password) for every request, but that would require to keep those credentials in memory and the service would have to check those credentials .So this’s not the best way. This is why REST services typically use a token system. A standard token system returns a 'token' (just a long unique string of random characters, for example a GUID) on successful login. The client in turn then sends this token in every request’s Authorization header. The service, on every request, 'rehydrates' its context by looking up the context on the server side. This context can be stored in a DB, retrieved from a Redis cache or simply stored in memory in a hash table. The downside of this approach is that for every REST method you will need to do this lookup in the database or cache. And then comes JSON Web Tokens, or JWT
Read more