registration and signin - GenusDev/genie-portal GitHub Wiki

✔️ Registration and Sign In

screenshot

The Sign-in and registration set-up are intentionally interchangeable. Simplicity guides the design of the site, as we integrate the various components as much as possible.

Process: Using the proposed Data Schema, the user fills in email, password, and must accept bylaws. Errors will display if incorrect. Password must be at least 6 characters. Email must not already exist in the DB. The user must accept bylaws to approve profile. A tentative link to the Bylaws link (To be developed further) can be found here. Upon sign up, an email, password, and current session token are saved to the database. The session token resets each time a user logs out for security reasons. State updates dynamically as you fill in form fields. On submission of their sign up request, an AJAX call with POST request to our database (PostgreSQL) to complete their sign up. When the POST request is made, the user is created through the controller. >>

The model checks the validations to ensure

  • the Email format is correct,
  • the password is present,
  • a session tokens is present
  • the bylaws were confirmed (set to true),

⚔️ [ ] Make “Register” more prominent than “Sign IN” with stylings.

✔️ Confirmation Blurb:

The following is the blurb that will be sent to users upon confirmation of their profile:

Thanks for creating a profile.

This portal creates an interface for acquiring, analyzing and trading equity stakes as genie tokens in the development projects proposed and under development by Genus Development.

At this stage in our development we are only offering equity to people for whom we know directly. By creating a profile you are confirming that you have some direct relationship to one of the key owners and investors involved in the projects under development.

We appreciate your investments and welcome any questions you may have. Please feel free to contact us at [email protected]

✔️ User Sessions Logic

If a signup is validated, the user is logged-in. The session is reset when the user log-outs, turning the session token to null. While logged in the current.user is dispatched to the reducer (React/Redux framework). Once dispatched to reducer, a user can update data as it relates to their use directly. Users are expected to have the same ID and sign=in across all portals. Authorization is executed with react-router-dom, redirecting the user based on the boolean, “loggedIn”. This boolean is held in our Redux store and is determined based on session login or signup.

⚔️ Administrative Sessions Administrators will have a separate designation and their interface will reflect the tools afforded to administrators, specifically the ability to pitch projects.

✔️ Username Display username is a truncated email (only the characters before the ‘@’) as default in order to stream-line the set-up process. Users can change their username later via the navigation bar.

⚠️ **GitHub.com Fallback** ⚠️