Piece 2: Signup System(Login 3)

Link : github source code

Components

• HAProxy: Acts as the reverse proxy, listening on “/signup” and forwarding requests to the .c2 backend.
• .c2 Backend: A separate C-based backend (distinct from the .c login backend) handling signup logic.
• Redis: Stores signup tracking (select 5) and user data (select 0).

Target

• Allow users to self-sign up for an account with privacy as the highest priority, assigning them level 0 and a 30-day TTL, while preventing bot abuse and ensuring unique usernames.

Requirements (Your Inputs)

1. Endpoint: HAProxy listens on “/signup”, accessible to anyone for self-signup.
2. Backend: Requests are redirected to .c2 (you labeled it .c2 to distinguish it from the login .c backend).
3. IP Limiting: Track user/ip in Redis “select 5” with a TTL of 3600s. If an IP has successfully signed up within 3600s, redirect to an HTML page saying “Your IP has already registered. Multi-register is not allowed.”
4. Username Rules: Allow signup if the username:
   • Starts with a-zA-Z.
   • Contains only a-zA-Z0-9.
   • Is more than 8 characters.
   • Doesn’t already exist.
   • Return a generic “signup failed” error for any failure (no specific reasons like “username exists”).
5. New User Settings: Set TTL to 30 days and level to 0 (no extra privileges).
6. Storage: Save new users to “select 0” (you confirmed this as the user database).
7. Privacy: No email or phone verification—users re-sign up if they lose passwords.
8. Atomicity: Lock username insertion to prevent simultaneous duplicates (you agreed it’s unlikely but worth doing).
9. IP Blocking Logic: 1 signup per IP in 3600s isn’t strict—users should wait if they need another account.
10. CAPTCHA: No Google CAPTCHA; add a self-hosted CAPTCHA replacement for bot protection (you requested this for signup, login, and admin).
11. TTL Expiry: If a new user’s TTL (30 days) expires, delete the account completely, allowing username reuse.
12. Username as Key: Use username as the key in Redis (e.g., for GET/SET or HGET/HSET).

Conceptual Solutions (My Suggestions Integrated with Your Decisions)

1. Flow:

Evolving Web Authentication(login 1)

From Simple Cookies to Secure Sessions

In the early days of web applications, servers used a straightforward approach to identify returning users. When you logged in, the server would issue your browser a cookie - a small piece of data that identified you as an authenticated user.

During subsequent visits, your browser automatically submits this cookie with each request. The server would perform a simple check: “Does this request include a cookie named ‘your_name_session’?” If yes, access granted. This basic system worked well initially.

Finding a Login Protection Solution

For any website, robust login protection is crucial. Existing solutions often fall short of my requirements:

1. Security
2. Dynamic capability
3. Resistance to brute force attacks

I analyzed many options and initially considered Aerospike and ScyllaDB as ideal solutions. However, I abandoned these ideas because they proved too difficult to compile from source on standard Linux systems. I attempted builds on both Debian and Alpine with no success.