Visitor Gate Pass System

☰

Gate Pass Status

Gate Pass History

Register Visitor

Visitor First Name: Visitor Last Name: Mobile Number: Company Name: Company Address: Place: Email ID: ID Type: ID Number: Visitor Category: Photo (Choose file or take photo):

Choose File

Take Photo

🔍 Search Existing Visitors

Enter search terms above to find existing visitors

Edit Visitor Information

Search Visitor (by any keyword):

Create New Gate Pass

User Management

Personal & Corporate Information

First Name: Last Name: Email: Password: Mobile Number: Employee ID: Office Address:

Home address same as office

Home Address:

Role & Access Permissions

Department: Access Level:

Location Information

Country: Site/Office Code: Physical Location:

🔍 Search Existing Users

Employee ID	Name	Email	Role	Access Level	Country	Site Code	Department	Mobile	Actions

Advanced Analytics Dashboard

Total Visitors

All time

Currently In

Active now

Total Out

Completed visits

Approved - Waiting

Ready to enter

Pending - My Approval

Awaiting my decision

Rejected

Declined requests

Visitor Journey

Time Analysis

Avg. Visit Time --

Longest Visit --

Peak Hour --

Company Insights

Frequency Patterns

Saved Searches

Download & Upload

Download Reports

Export complete gate pass data including visitor information, timing, and approval details.

Bulk Upload Users

Upload multiple users at once using a CSV file. Download the template first to see the required format.

Choose CSV File:

Organization Management

Existing Organizations

System Documentation

Gate Pass Management System

Company:	Starengts Technologies
System Name:	Gate Pass Management System
Version:	1.0.0
Document Type:	IT Governance & Technical Documentation
Last Updated:
Prepared For:	IT Governance Review & Audit
Contact:	support@starengts.com

Confidential: This document contains proprietary and confidential information of Starengts Technologies. Distribution is restricted to authorized personnel only.

Section 1: Data Access & Integration
Section 2: Security Architecture & Authentication
Section 3: System Lifecycle & Maintenance
Section 4: Technology Architecture & Infrastructure

Section 1: Data Access & Integration

1.1 Database Schema & Structure

The system uses MySQL/MariaDB (version 11.8.2) with a comprehensive relational database schema.

Database Name: starengts_gatepass
Database Server: 192.168.1.43:3306
Connection Pool: 10 concurrent connections
Character Set: UTF8MB4 (full Unicode support)

Core Database Tables (20+ tables)

Table Name	Purpose	Key Fields	Records (Approx.)
`users`	User authentication & authorization	id, username, email, password, role, org_id	Active: 50-100
`visitors`	Visitor master data	id, firstName, lastName, email, mobileNumber, idType, idNumber	Active: 1000+
`gatepasses`	Gate pass records (entry/exit)	id, visitor_id, entry_time, exit_time, status, qr_code	Monthly: 500-1000
`organizations`	Multi-tenancy organization data	id, org_name, max_users, expiry_date, created_by	Active: 5-10
`audit_log`	Complete audit trail (all actions)	id, user_id, action, table_name, old_values (JSON), new_values (JSON)	Growing: 10,000+
`api_rate_limits`	Rate limiting & DDoS protection	identifier, endpoint, request_count, blocked, window_reset_at	Active: 100-500
`failed_login_attempts`	Security: Track failed logins	username, ip_address, attempt_time, blocked_until	Active: 50-200
`backup_history`	Database backup logs	backup_file, backup_type, status, file_size_mb, started_at	Weekly: 52/year
`appconfig`	System configuration key-value store	configKey, configValue, category, updatedAt	Static: 20-30
`documents`	Digital document management	qr_code, name, file_path, uploaded_by, version	Active: 100-300
`dockings`	Truck docking station management	gate_id, docking_station, status (available/occupied)	Static: 10-20
`analyticssavedsearches`	User-saved analytics queries	userId, searchName, query, filters (JSON)	Active: 20-50

Note: All sensitive data (passwords, OTPs) are hashed using bcrypt (cost factor: 10). Personal Identifiable Information (PII) includes visitor names, mobile numbers, ID numbers, and email addresses.

1.2 Access Levels & Role-Based Permissions

The system implements a comprehensive role-based access control (RBAC) model with 10 distinct user roles.

Role	Access Level	Permissions	Typical Use Case
Owner	Super Admin	Full system access including organization management, app configuration, all modules	System administrators, IT team
Global_Admin	Full Admin	All modules except organization management	Regional administrators, country heads
Country_Admin	Full Admin	Same as Global_Admin (country-level administration)	Country-specific administrators
Site_Admin	Site Management	Visitor registration, gate pass, status, history, data visualization, digital docs	Site managers, reception supervisors
Site_Creator	Site Management	Same as Site_Admin (can create/edit visitors and passes)	Front desk staff, reception
Site_Manager	Site Management	Same as Site_Admin	Site operations managers
Site_Approver	Site Management	Approve/reject gate passes, view visitor data	Department heads, managers
Global_Auditor	Read-Only	View status, history, data visualization, digital docs (no create/edit/delete)	Compliance officers, internal auditors
Site_Security	Security Operations	Visitor registration, gate pass, QR scanner, truck registration, status, history	Security guards, gate operators
User	Minimal Access	View digital documents, limited access	General employees, contractors
Attendance_Master	Attendance Only	QR scanner for employee attendance, digital documents	HR staff, attendance coordinators

Security Note: Role changes require re-authentication. Users can only be assigned to one role at a time. Role-based navigation is enforced both on frontend (UI) and backend (API endpoints).

1.3 External Services & Integrations

Current External Integrations:

Service Type	Provider/Technology	Purpose	Status
Email Service	Nodemailer (SMTP)	Password reset OTP, gate pass notifications	Configurable (currently disabled)
Face Detection	TensorFlow.js + MediaPipe	Visitor facial verification during check-in	Active (client-side processing)
QR Code Generation	qrcode (Node.js library)	Generate unique QR codes for gate passes	Active
Image Processing	Sharp	Resize, optimize, and process uploaded photos	Active
Thermal Printing	ESC/POS Protocol	Print gate passes on thermal printers	Active (local network)
Database Backup	mysqldump	Automated weekly database backups	Active (configurable to daily)
Real-time Updates	WebSocket (ws)	Live status updates, notifications	Active
RFID Card Reader	PC/SC Lite (@pokusew/pcsclite)	Employee RFID card scanning for attendance	Active (hardware dependent)

API Design: RESTful API architecture with versioned endpoints (/api/v1/*). All endpoints return JSON responses. Rate limiting: 100 requests per 15 minutes per IP address.

1.4 Software Dependencies & Version Control

Backend Dependencies (Node.js/NPM)

Package	Version	Purpose	Security Patches
express	4.18.2	Web application framework	Up to date
mysql2	3.6.0	MySQL database driver	Up to date
jsonwebtoken	9.0.2	JWT authentication	Up to date
bcrypt	6.0.0	Password hashing	Up to date
sharp	0.34.3	Image processing	Up to date
winston	3.11.0	Logging framework	Up to date
express-rate-limit	7.1.5	API rate limiting	Up to date
express-validator	7.0.1	Input validation & sanitization	Up to date
cors	2.8.5	Cross-origin resource sharing	Up to date
dotenv	17.2.0	Environment variable management	Up to date
multer	2.0.2	File upload handling	Up to date
nodemailer	6.10.1	Email sending	Up to date
node-cron	3.0.3	Scheduled task automation	Up to date
ws	8.18.3	WebSocket server	Up to date

Frontend Libraries (CDN/NPM)

Library	Version	Purpose
jQuery	3.6.0	DOM manipulation
Bootstrap	4.5.2	Responsive UI framework
Font Awesome	6.4.0	Icon library
Chart.js	Latest (CDN)	Data visualization & charts
TensorFlow.js	4.22.0	Machine learning (face detection)
MediaPipe Tasks Vision	0.10.22	Face detection models
Select2	4.1.0	Enhanced select dropdowns
Toastify.js	Latest (CDN)	Toast notifications
Intl Tel Input	17.0.13	International phone number formatting

Update Policy: Dependencies are reviewed quarterly. Security patches are applied within 48 hours of release. Major version updates are tested in staging before production deployment.

1.5 Integration Capabilities & Extensibility

The system is designed with extensibility in mind and supports various integration methods.

Available Integration Methods:

REST API: Full CRUD operations via JSON API endpoints
WebSocket: Real-time bidirectional communication
CSV Import/Export: Bulk data operations
Database Direct Access: For advanced integrations
Webhook Support: Event-driven notifications (planned)

Future Integration Roadmap:

LDAP/Active Directory authentication
Single Sign-On (SSO) support
Mobile app API (iOS/Android)
ERP system integration (SAP, Oracle)
Cloud storage integration (AWS S3, Azure Blob)

Section 2: Security Architecture & Authentication

2.1 Data Storage Architecture

Database Storage:

Location: VPS/Dedicated Server (192.168.1.43)
Database Type: MariaDB 11.8.2
Storage Engine: InnoDB (ACID compliant)
Backup Storage: Local file system + offsite (configurable)
Retention Policy: Active data indefinite, backups 90 days

File Storage:

Visitor Photos: /public/uploads/ directory
Document Files: /public/uploads/ directory
Max File Size: 50MB per upload
Allowed Formats: JPG, PNG, PDF, CSV
Processing: Images auto-resized and optimized

Data Sovereignty: All data is stored on-premise within India. No data is transmitted to external cloud services without explicit configuration.

2.2 Authentication Method: JWT (JSON Web Tokens)

Why JWT? Authentication Method Comparison

Feature	JWT (Current)	Session Cookies	OAuth 2.0
Scalability	Stateless, horizontally scalable	Requires session store	Scalable
Mobile App Support	Excellent	Difficult	Excellent
Implementation Complexity	Simple	Simple	Complex
Storage Location	Client-side (browser memory/localStorage)	Server-side (session store)	Client-side + Authorization server
Performance	Fast (no DB lookup)	Moderate (DB lookup)	Moderate
Security	Signed & encrypted, short expiry	Secure if HTTPS + httpOnly	Enterprise-grade
Cross-Domain Support	Excellent (CORS)	Difficult	Excellent
Best For	APIs, microservices, mobile apps	Traditional web apps	Third-party integrations, SSO

Decision Rationale: JWT was selected for its stateless architecture, excellent mobile app support, and suitability for future microservices expansion. The system is designed to scale horizontally without requiring a centralized session store.

Token Configuration & Expiry

Access Token

Expiry:	1 hour
Purpose:	API authentication
Storage:	Browser memory (sessionStorage)
Algorithm:	HS256 (HMAC SHA-256)

Why 1 hour? Balances security (short window for token theft) with usability (minimal re-authentication). Automatically refreshed via refresh token.

Refresh Token

Expiry:	7 days
Purpose:	Obtain new access tokens
Storage:	Browser localStorage (HttpOnly preferred)
Algorithm:	HS256 (HMAC SHA-256)

Why 7 days? Users remain logged in for a full work week without re-entering credentials. After 7 days, full re-authentication is required for security.

Authentication Flow Diagram

┌─────────────┐                                     ┌─────────────┐
│   Client    │                                     │   Server    │
│  (Browser)  │                                     │  (Node.js)  │
└──────┬──────┘                                     └──────┬──────┘
       │                                                   │
       │  1. POST /api/v1/auth/jwt-login                  │
       │     { username, password }                        │
       ├──────────────────────────────────────────────────>│
       │                                                   │
       │                    2. Verify credentials          │
       │                       (bcrypt compare password)   │
       │                                                   │
       │  3. Return tokens                                 │
       │     { accessToken, refreshToken, user }           │
       │<──────────────────────────────────────────────────┤
       │                                                   │
       │  4. Store tokens in sessionStorage/localStorage   │
       │                                                   │
       │  5. API requests with Bearer token                │
       │     Authorization: Bearer            │
       ├──────────────────────────────────────────────────>│
       │                                                   │
       │                    6. Verify JWT signature        │
       │                       Extract user info from token│
       │                                                   │
       │  7. Return data                                   │
       │<──────────────────────────────────────────────────┤
       │                                                   │
       │  8. When access token expires (1 hour)            │
       │     POST /api/v1/auth/refresh-token               │
       │     { refreshToken }                              │
       ├──────────────────────────────────────────────────>│
       │                                                   │
       │                    9. Verify refresh token        │
       │                       Issue new access token      │
       │                                                   │
       │  10. Return new access token                      │
       │<──────────────────────────────────────────────────┤
       │                                                   │
       │  11. Continue API requests with new token         │
       │                                                   │
       │  12. Logout: POST /api/v1/auth/jwt-logout         │
       │     (Clear client-side tokens)                    │
       ├──────────────────────────────────────────────────>│
       │                                                   │
       │  13. Success response                             │
       │<──────────────────────────────────────────────────┤
       │                                                   │
└───────┘                                           └───────┘

Storage Method Explanation & Trade-offs

Storage Method	Pros	Cons	Used For
sessionStorage	Cleared on tab close, immune to XSS in other tabs	Lost on tab close (user must re-login)	Access Token (current)
localStorage	Persists across browser sessions, convenient	Vulnerable to XSS attacks if script injection occurs	Refresh Token (current)
httpOnly Cookie	Not accessible via JavaScript, immune to XSS	Vulnerable to CSRF if not properly configured	Future enhancement (recommended)
Memory Only	Most secure, never written to disk	Lost on page refresh (poor UX)	Not used (poor usability)

Security Recommendation: For production environments handling highly sensitive data, consider migrating to httpOnly cookies for refresh tokens to eliminate XSS risk. This requires CSRF protection implementation.

2.3 Security Best Practices & Implementation

Implemented Security Measures:

Password Hashing: bcrypt with cost factor 10
JWT Secret: 256-bit random key stored in .env
Rate Limiting: 100 req/15min per IP (global), 5 req/15min (login)
Input Validation: express-validator on all endpoints
SQL Injection Protection: Parameterized queries only
XSS Protection: Input sanitization, CSP headers
CORS: Configured for specific origins only
HTTPS/SSL: TLS 1.2+ encryption (production)
Audit Logging: All CRUD operations logged
Failed Login Tracking: Auto-block after 5 attempts

Planned Security Enhancements:

Two-Factor Authentication (2FA/MFA)
httpOnly cookies for refresh tokens
CSRF token implementation
Encryption at rest for PII data
Advanced threat detection (IP reputation)
Security headers (HSTS, X-Frame-Options)
Penetration testing by third party
SIEM integration for log analysis
Data masking for sensitive fields
Regular security training for developers

2.4 IT Governance: Common Questions & Answers

Q1: How is user authentication secured against brute-force attacks?

Answer: The system implements multi-layered protection:

Rate Limiting: Maximum 5 login attempts per 15-minute window per IP address
Account Lockout: After 5 failed attempts, account is temporarily blocked for 30 minutes
Failed Login Logging: All failed attempts logged in failed_login_attempts table with IP address and timestamp
IP Blocking: Repeated failed attempts from same IP can trigger permanent ban
Strong Password Policy: Minimum 8 characters (configurable to enforce complexity)

Q2: What happens if a JWT token is stolen or compromised?

Answer: JWT tokens have built-in security mitigations:

Short Expiry: Access tokens expire in 1 hour, limiting the window of vulnerability
Signature Verification: All tokens are cryptographically signed with HS256. Modified tokens are rejected
HTTPS Only: Tokens transmitted only over encrypted connections (TLS 1.2+)
Token Revocation: Logout endpoint clears refresh tokens (client-side) and can blacklist tokens (future enhancement: server-side token blacklist)
IP Monitoring: Audit logs track token usage by IP. Unusual activity can be detected
Immediate Action: Admins can force user re-authentication by disabling/deleting user account

Q3: How is sensitive data (passwords, PII) protected in the database?

Answer: Data protection follows industry best practices:

Password Hashing: All passwords hashed with bcrypt (cost factor 10). Plaintext passwords never stored
OTP Hashing: Password reset OTPs are hashed before storage (cannot be reversed)
Database Access Control: Database user has restricted permissions (no DROP, ALTER on production)
Network Isolation: Database server accessible only from application server (firewall rules)
Backup Encryption: Database backups can be encrypted before offsite storage (configurable)
PII Handling: Visitor ID numbers, mobile numbers stored as-is (required for business operations) but access logged via audit trail

Q4: Can user actions be traced for compliance and audit purposes?

Answer: Comprehensive audit logging is implemented:

Audit Log Table: All database changes (INSERT, UPDATE, DELETE) recorded in audit_log table
Change Tracking: Old and new values stored as JSON for comparison (before/after state)
User Attribution: Every action linked to user ID, username, email, role, organization
IP & User Agent: Request origin and device information captured
API Endpoint Tracking: Request method (GET/POST/PUT/DELETE) and URL logged
Retention: Audit logs retained indefinitely unless manually archived
Query Capabilities: Admins can search audit logs by user, date range, action type, table name

Q5: What is the disaster recovery plan if the server crashes or data is lost?

Answer: Disaster recovery strategy includes:

Automated Backups: Weekly full database backups (configurable to daily)
Backup Storage: Backups stored locally + can be configured for offsite cloud storage (S3, Azure Blob)
Backup Verification: Each backup logged in backup_history table with file size and status
Recovery Time Objective (RTO): 4 hours (restore from backup + verify data integrity)
Recovery Point Objective (RPO): 7 days maximum data loss (with weekly backups), 24 hours if daily backups enabled
Restoration Procedure: Documented SQL restore commands, tested quarterly
High Availability (Future): Database replication to standby server for zero downtime

Q6: How does the system comply with data protection regulations (GDPR, DPDPA)?

Answer: Compliance measures implemented:

Data Minimization: Only essential visitor data collected (name, mobile, ID for security purposes)
Consent Tracking: Visitor registration implies consent (can be enhanced with explicit checkbox)
Right to Erasure: Admins can delete visitor records and associated gate passes
Data Portability: CSV export functionality allows data export in machine-readable format
Access Control: Role-based access ensures only authorized personnel view PII
Audit Trail: All data access and modifications logged for regulatory proof
Data Retention: Configurable retention policies (currently indefinite, can be automated for deletion after N days)
Security: Encryption in transit (HTTPS), password hashing, restricted database access

Q7: What measures are in place to prevent SQL injection and XSS attacks?

Answer: Defense-in-depth security approach:

SQL Injection Prevention:
- All database queries use parameterized statements (mysql2 prepared statements)
- User input never directly concatenated into SQL queries
- express-validator sanitizes and validates all API inputs
XSS Prevention:
- Input validation on all form fields (client-side and server-side)
- Output encoding when displaying user-generated content
- Content Security Policy (CSP) headers can be enabled
- HTML special characters escaped in templates
Additional Measures: CORS configured for trusted origins only, rate limiting prevents automated attacks

Q8: How is role-based access control (RBAC) enforced across the system?

Answer: RBAC implemented at multiple layers:

Frontend Layer: Navigation menu dynamically generated based on user role (prevents UI access)
API Layer: Middleware authenticates JWT and checks user role before allowing endpoint access
Database Layer: Role-specific data filtering (e.g., Site_Admin sees only their organization's data)
Role Hierarchy: Owner > Global_Admin > Site_Admin > Site_Security > User
Least Privilege: Users granted minimum necessary permissions for their role
Role Assignment: Only Owner and Global_Admin can assign/modify user roles
Re-authentication: Role changes require user to logout and login again

2.5 Production Security Checklist

This checklist ensures all security measures are properly configured before go-live.

Status	Security Item	Verification Method	Responsibility
✅	SSL/TLS certificate installed and valid	Access https://[domain] - verify green padlock	DevOps/SysAdmin
✅	JWT_SECRET changed from default	Verify .env file has 256-bit random key	Developer
✅	Database password is strong (20+ chars)	Check .env DB_PASSWORD	DBA
✅	Default admin password changed	Login as owner, verify password changed	Security Officer
✅	Firewall configured (only ports 80, 443, 3306)	Run: sudo ufw status	SysAdmin
✅	Database accessible only from app server	Verify firewall rule: allow 3306 from app IP only	DBA/SysAdmin
✅	VPN required for admin access	Disconnect VPN, verify cannot access admin panel	Network Admin
✅	IP whitelisting configured	Check nginx/firewall rules for IP restrictions	SysAdmin
✅	Backup service running and tested	Check /backups directory for recent .sql files	DBA
⚠️	Rate limiting enabled	Send 6 login requests rapidly - verify 429 error	Developer
⚠️	Input validation on all endpoints	Run automated API security tests	QA/Security
❌	Security headers configured	Run: curl -I https://[domain] \| grep -i security	DevOps
❌	Audit logging enabled	Create user, verify entry in audit_log table	Developer
❌	Failed login tracking active	Login with wrong password 5x, verify lockout	Developer
❌	CORS limited to production domains	Check server.js CORS config	Developer
❌	Sensitive data not logged (passwords, tokens)	Review winston logger config + log files	Developer
❌	Production environment variables set	Verify NODE_ENV=production in .env	DevOps
❌	Unnecessary services disabled	Run: sudo systemctl list-units --type=service	SysAdmin
❌	OS security patches up to date	Run: sudo apt update && apt list --upgradable	SysAdmin
❌	Node.js and npm packages updated	Run: npm audit	Developer

Legend:

✅ = Implemented and verified
⚠️ = Partially implemented, needs review
❌ = Not yet implemented, requires action

2.6 Encryption & Data Protection

Data Type	Encryption Method	Key Management	Status
Data in Transit (API)	TLS 1.2+ (HTTPS)	SSL certificate managed by VPS provider	Active
Data in Transit (WebSocket)	WSS (WebSocket Secure)	Same SSL certificate as HTTPS	Active
Passwords	bcrypt hashing (irreversible)	Salt auto-generated per password	Active
JWT Tokens	HS256 signature (not encrypted)	Secret key in .env (JWT_SECRET)	Active
Database at Rest	File system encryption (OS level)	LUKS/dm-crypt or VPS provider	Optional
Backup Files	AES-256 encryption (optional)	Backup encryption key in .env	Configurable
Uploaded Files (photos)	File system permissions (644)	N/A (not encrypted)	Not encrypted

Recommendation: For compliance with data protection regulations, consider enabling at-rest encryption for the database and uploaded files. This can be achieved via OS-level encryption (LUKS) or database-level encryption (MySQL Transparent Data Encryption).

2.7 Backup & Disaster Recovery

Current Backup Configuration:

Backup Type:	Full database dump (mysqldump)
Frequency:	Weekly (configurable to daily)
Schedule:	Every Sunday at 2:00 AM (node-cron)
Storage Location:	Local: /backups/ directory on VPS
Retention:	90 days (older backups manually archived)
Notification:	Email notification on backup success/failure (if email enabled)
Verification:	Backup size and timestamp logged in backup_history table

Disaster Recovery Procedures:

Scenario 1: Database Corruption

Stop the application server: sudo systemctl stop gatepass
Identify latest valid backup: ls -lh /backups/*.sql
Restore database: mysql -u root -p starengts_gatepass < /backups/backup_2025-12-08.sql
Verify data integrity: Check critical tables (users, gatepasses)
Restart application: sudo systemctl start gatepass
Test login and core functionality
Expected RTO: 2-4 hours

Scenario 2: Complete Server Failure

Provision new VPS with same OS version
Install Node.js, MySQL, and dependencies
Clone application repository from Git
Restore latest database backup
Update .env with new server configuration
Configure firewall, SSL certificate, VPN access
Start application and verify functionality
Expected RTO: 8-12 hours

Scenario 3: Accidental Data Deletion

Identify time of deletion from audit_log table
Locate backup taken before deletion
Extract specific records using SQL query on backup file
Re-insert deleted records into live database
Verify data consistency (foreign key relationships)
Expected RTO: 1-2 hours

Recommendation:

Enable daily backups (change to 24-hour interval in backup-service.js)
Configure offsite backup storage (AWS S3, Azure Blob, or Google Cloud Storage)
Test backup restoration quarterly to ensure recoverability
Implement database replication (master-slave) for high availability

Section 3: System Lifecycle & Maintenance

3.1 Development Workflow & Version Control

Development Pipeline:

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│  Development    │────>│    Testing      │────>│    Staging      │────>│   Production    │
│  (Local)        │     │  (QA Server)    │     │  (Pre-Prod)     │     │  (VPS Live)     │
└─────────────────┘     └─────────────────┘     └─────────────────┘     └─────────────────┘
  │                       │                       │                       │
  │ • Feature dev         │ • Unit testing        │ • UAT                 │ • Live traffic
  │ • Code changes        │ • API testing         │ • Performance test    │ • Monitoring
  │ • Git commits         │ • Security scan       │ • Load testing        │ • Backups
  │ • npm run dev         │ • Bug fixes           │ • Final approval      │ • npm start

Version Control:

Repository:	Git (private repository)
Branching Strategy:	main (production), develop (staging), feature/* branches
Commit Convention:	Conventional Commits (feat:, fix:, docs:, refactor:)
Code Review:	Pull requests required for main branch merges
CI/CD:	Manual deployment (can be automated with GitHub Actions/Jenkins)

Deployment Process:

Pre-Deployment: Run npm audit to check for vulnerabilities
Backup: Trigger manual database backup before deployment
Code Push: Push latest code to VPS via Git pull or SCP
Dependency Update: Run npm install --production
Database Migration: Apply any schema changes via migration scripts
Service Restart: sudo systemctl restart gatepass
Health Check: Verify application responds at https://[domain]
Smoke Test: Test critical flows (login, visitor registration, gate pass creation)
Monitoring: Watch logs for errors: tail -f /var/log/gatepass.log
Rollback Plan: If errors occur, revert to previous Git commit and restart

3.2 Maintenance Schedule & Responsibilities

Frequency	Task	Responsibility	Estimated Time
Daily	Monitor application logs for errors	DevOps/SysAdmin	15 minutes
Daily	Verify backup completion (if daily backups enabled)	DBA	5 minutes
Weekly	Review audit logs for unusual activity	Security Officer	30 minutes
Weekly	Check disk space usage on VPS	SysAdmin	10 minutes
Weekly	Review failed login attempts and blocked IPs	Security Officer	15 minutes
Monthly	Update npm packages (security patches only)	Developer	1-2 hours
Monthly	Test backup restoration on staging server	DBA	2-3 hours
Monthly	Archive old audit logs (>90 days)	DBA	30 minutes
Monthly	Review and optimize slow database queries	DBA/Developer	1-2 hours
Quarterly	Major dependency updates (test thoroughly)	Developer	4-8 hours
Quarterly	Security vulnerability assessment	Security Team	4-8 hours
Quarterly	Performance tuning and optimization	Developer/DBA	4-8 hours
Quarterly	User access review (remove inactive users)	HR/Security Officer	2-3 hours
Annually	Full disaster recovery drill (test restoration)	IT Team	8-12 hours
Annually	Third-party penetration testing	External Vendor	40-80 hours
Annually	SSL certificate renewal	SysAdmin/DevOps	1-2 hours
As Needed	Hot fixes for critical bugs	Developer	Varies
As Needed	User training and onboarding	Trainer/Admin	2-4 hours per session

3.3 Documentation Locations & Resources

Document Type	Location	Audience	Update Frequency
System Documentation (This Document)	Admin Panel > System Documentation	IT Governance, Auditors	Quarterly
API Documentation	/api-docs (Swagger UI)	Developers, Integration Partners	Every release
User Manual	/public/user-manual.pdf (to be created)	End Users (Admin, Security, Reception)	Every major release
Installation Guide	/INSTALLATION.md (Git repository)	DevOps, SysAdmins	Every major release
Database Schema	/database/schema.sql (Git repository)	Developers, DBAs	Every schema change
Runbook (Operational Procedures)	/docs/runbook.md (to be created)	DevOps, Support Team	Quarterly
Change Log	/CHANGELOG.md (Git repository)	All stakeholders	Every release
Code Comments	Inline in source code	Developers	Continuous

Recommendation: Create a dedicated knowledge base using Confluence, Notion, or GitBook to centralize all documentation. Include screenshots, video tutorials, and troubleshooting guides for common issues.

3.4 Support Model & Escalation

Support Tiers:

Tier	Scope	Response Time	Resolution Time (Target)
Tier 1 (Helpdesk)	User questions, password resets, basic troubleshooting	2 hours during business hours	Same day
Tier 2 (Technical Support)	Configuration changes, data issues, module errors	4 hours during business hours	1-2 business days
Tier 3 (Development Team)	Bugs, feature requests, code changes, integrations	1 business day	1-2 weeks (depends on complexity)
Critical Incident	System down, data loss, security breach	30 minutes (24/7)	4 hours (RTO)

Escalation Path:

User Issue
   │
   ├──> Tier 1 (Helpdesk) ──> Resolve or Escalate
   │                              │
   └──────────────────────────────┴──> Tier 2 (Technical Support) ──> Resolve or Escalate
                                                      │
                                                      └──> Tier 3 (Development Team) ──> Fix & Deploy
                                                                     │
                                                                     └──> Critical? ──> Emergency Hotfix

Support Channels:

Email: support@starengts.com (monitored during business hours)
Phone: Helpdesk hotline for critical issues (to be configured)
Ticketing System: Internal JIRA/ServiceNow (to be configured)
In-App Support: User can submit feedback via Digital Doc module

3.5 User Training & Onboarding

Training Programs:

Role	Training Topics	Duration	Format
Site Security (Gate)	Visitor registration, QR scanning, gate pass approval, truck entry	2-3 hours	Hands-on + video
Reception Staff	Visitor registration, gate pass creation, photo capture, digital docs	2-3 hours	Hands-on + video
Site Admin	User management, reports, analytics, data visualization	4-5 hours	Workshop + documentation
Owner/Global Admin	Full system administration, organization management, app configuration, backups	8-10 hours	Workshop + shadowing
IT/DevOps Team	Server setup, deployment, monitoring, troubleshooting, backup restoration	16-20 hours	Technical training + runbook

Onboarding Checklist (New Admin User):

Receive login credentials (Owner creates account)
Complete initial login and change password
Attend 2-hour training session
Review user manual and watch tutorial videos
Practice in staging environment (if available)
Shadow experienced user for 1 day
Complete onboarding quiz (to be created)
Granted production access with supervision
After 1 week: Independent access + follow-up review

Section 4: Technology Architecture & Infrastructure

4.1 Complete Technology Stack

Full Stack Architecture:

Presentation Layer	HTML5, CSS3, JavaScript (Vanilla), Bootstrap 4.5.2, Font Awesome 6.4.0
Client-Side Libraries	jQuery 3.6.0, Chart.js, TensorFlow.js 4.22.0, MediaPipe, Select2, Toastify.js
Application Layer	Node.js (LTS), Express.js 4.18.2
API Layer	RESTful API (JSON), WebSocket (ws 8.18.3), Swagger API Docs
Security Layer	JWT (jsonwebtoken 9.0.2), bcrypt 6.0.0, express-rate-limit 7.1.5, express-validator 7.0.1
Business Logic	Custom JavaScript modules (main.js 16,000+ lines)
Database Layer	MySQL 2 (mysql2 3.6.0 driver), MariaDB 11.8.2
File Storage	Local File System (/public/uploads/), Sharp 0.34.3 (image processing)
Infrastructure	VPS/Dedicated Server, Linux (Ubuntu/Debian), Nginx/Apache (reverse proxy)
Networking	SSL/TLS (HTTPS), VPN Access, Firewall (ufw/iptables), IP Whitelisting
Monitoring & Logging	Winston 3.11.0, Custom audit logging, Error tracking
Automation	node-cron 3.0.3 (scheduled tasks), Automated backups (mysqldump 3.2.0)
DevOps	Git (version control), npm (package management), systemd (process management)

Technology Choices & Rationale:

Technology	Why Chosen	Alternatives Considered
Node.js + Express	Fast development, JavaScript full-stack, excellent async I/O, large ecosystem	Python/Django, Java/Spring, PHP/Laravel
MySQL/MariaDB	Mature, reliable, ACID compliant, strong community support, familiar to team	PostgreSQL, MongoDB, Microsoft SQL Server
JWT Authentication	Stateless, scalable, mobile-friendly, industry standard for APIs	Session cookies, OAuth 2.0, SAML
Vanilla JavaScript (Frontend)	No framework bloat, full control, faster performance, easier to maintain	React, Vue.js, Angular
Bootstrap 4	Responsive out-of-the-box, minimal custom CSS, well-documented	Tailwind CSS, Material-UI, Foundation
TensorFlow.js	Client-side face detection (no server load), privacy-friendly (data stays on device)	Server-side OpenCV, AWS Rekognition, Face++

4.2 Infrastructure Architecture

Production Environment Specifications:

Hosting Type:	VPS/Dedicated Server
Server Location:	India (on-premise/data center)
IP Address:	192.168.1.43 (internal) + public IP (whitelisted access)
Operating System:	Linux (Ubuntu 20.04 LTS or Debian 11)
CPU:	4-8 vCPUs (recommended for 100+ concurrent users)
RAM:	8-16 GB (recommended minimum: 8GB)
Storage:	100-500 GB SSD (fast I/O for database + uploads)
Network:	1 Gbps port, static IP, DDoS protection
Uptime SLA:	99.9% (managed by hosting provider)

Network Architecture Diagram:

                                        INTERNET
                                           │
                                           ▼
                                  ┌──────────────────┐
                                  │   Firewall       │
                                  │  (IP Whitelist)  │
                                  └────────┬─────────┘
                                           │
                                           ▼
                                  ┌──────────────────┐
                                  │  VPN Gateway     │
                                  │  (Required for   │
                                  │  Admin Access)   │
                                  └────────┬─────────┘
                                           │
                           ┌───────────────┼───────────────┐
                           ▼               ▼               ▼
                    ┌────────────┐  ┌────────────┐  ┌────────────┐
                    │  HTTPS     │  │ WebSocket  │  │ SSH (Port  │
                    │ (Port 443) │  │ (Port 443) │  │    22)     │
                    └─────┬──────┘  └─────┬──────┘  └─────┬──────┘
                          │               │               │
                          └───────────────┴───────────────┘
                                           │
                                           ▼
                                  ┌──────────────────┐
                                  │ Nginx/Apache     │
                                  │ (Reverse Proxy)  │
                                  │ + SSL Termination│
                                  └────────┬─────────┘
                                           │
                                           ▼
                                  ┌──────────────────┐
                                  │  Node.js Server  │
                                  │  (Port 3001)     │
                                  │  + Express.js    │
                                  └────────┬─────────┘
                                           │
                                           ▼
                                  ┌──────────────────┐
                                  │  MySQL/MariaDB   │
                                  │  (Port 3306)     │
                                  │  - Localhost only│
                                  │  - No external   │
                                  │    access        │
                                  └──────────────────┘

Security Zones:

Zone	Components	Access Control	Security Level
DMZ (Public)	Web server (HTTPS), API endpoints	IP whitelisted + VPN for admin	Medium
Application Zone	Node.js application server	Accessed only via reverse proxy	High
Database Zone	MySQL/MariaDB database server	Localhost only (127.0.0.1)	Critical
Backup Zone	Backup storage directory	Root access only	Critical

Best Practice Implemented: Database server is not directly accessible from the internet. All database connections originate from localhost (127.0.0.1), eliminating external attack surface.

4.3 Enterprise Architecture Alignment

Alignment with Enterprise IT Standards:

Standard/Framework	Requirement	Compliance Status	Notes
ISO 27001 (Information Security)	Access control, encryption, audit logging	Compliant	RBAC, JWT, SSL/TLS, comprehensive audit logs
GDPR / DPDPA (Data Protection)	Consent, right to erasure, data minimization	Partially Compliant	Can delete visitor records; explicit consent checkbox recommended
NIST Cybersecurity Framework	Identify, Protect, Detect, Respond, Recover	Compliant	Risk assessment, security controls, incident response, backups
OWASP Top 10	Protection against common web vulnerabilities	Compliant	SQL injection prevention, XSS protection, secure authentication
PCI DSS (if handling payments)	Secure cardholder data	Not Applicable	System does not handle payment card data
SOC 2 Type II	Security, availability, confidentiality controls	Not Certified	Controls in place; formal audit not conducted

4.4 Technology Roadmap & Future Enhancements

Planned Features (6-12 Months):

Q1 2026: Mobile Application

Native iOS and Android apps for visitor self-registration
QR code scanning on mobile devices
Push notifications for gate pass approvals

Q2 2026: Biometric Integration

Fingerprint scanner integration for employee attendance
Facial recognition for visitor verification (enhanced accuracy)
IRIS scanner support for high-security areas

Q3 2026: Cloud-Native Architecture

Migrate to cloud hosting (AWS/Azure/GCP) for scalability
Implement auto-scaling for high traffic periods
Multi-region deployment for global organizations

Q4 2026: AI/ML Enhancements

Predictive analytics for visitor traffic patterns
Anomaly detection for security threats
Natural language chatbot for visitor queries

Ongoing: Integration Ecosystem

LDAP/Active Directory integration for SSO
ERP integration (SAP, Oracle, Microsoft Dynamics)
HR system integration for employee data sync
Third-party API for visitor background checks

Ongoing: Security Hardening

Two-Factor Authentication (2FA) for all users
Advanced threat protection (WAF integration)
Zero Trust architecture implementation
Compliance certifications (ISO 27001, SOC 2)

Technology Evolution Path:

Component	Current State	Future State	Timeline
Architecture	Monolithic (single server)	Microservices (containerized)	12-18 months
Database	Single MySQL instance	Master-slave replication + read replicas	6-9 months
File Storage	Local file system	Cloud object storage (S3/Azure Blob)	6-9 months
Frontend	Vanilla JavaScript SPA	Modern framework (React/Vue) for mobile app API	12-15 months
API	RESTful JSON API	GraphQL for flexible queries	18-24 months
Deployment	Manual deployment	CI/CD pipeline (GitHub Actions/Jenkins)	3-6 months
Monitoring	Winston logs + manual review	ELK Stack (Elasticsearch, Logstash, Kibana) + Grafana	6-9 months
Backup	Weekly mysqldump (local storage)	Daily incremental backups + cloud replication	Immediate (configurable now)

4.5 Compliance, Governance & Risk Management

Regulatory Compliance Status:

Regulation	Applicability	Compliance Status	Action Items
DPDPA 2023 (India)	Handles personal data of visitors	Partially Compliant	Add explicit consent checkbox, implement data retention policy
GDPR (EU)	If EU visitors are processed	Partially Compliant	Same as DPDPA + data processing agreement
IT Act 2000 (India)	Electronic records and digital signatures	Compliant	N/A (audit logs maintained)
ISO 27001	Information security management	Controls Implemented	Formal certification audit (optional)
Labour Laws (Attendance)	Employee attendance tracking	Compliant	N/A (records maintained as per law)

Risk Assessment & Mitigation:

Risk	Likelihood	Impact	Mitigation Strategy
Data Breach (Unauthorized Access)	Medium	High	VPN + IP whitelisting, strong passwords, 2FA (planned), audit logging
Server Failure / Hardware Crash	Medium	High	Weekly backups (configurable to daily), disaster recovery plan, RTO: 4 hours
SQL Injection Attack	Low	High	Parameterized queries, input validation, no dynamic SQL
DDoS Attack	Medium	Medium	Rate limiting (100 req/15min), firewall, VPS DDoS protection
Insider Threat (Malicious Admin)	Low	High	Audit logging (all actions tracked), role-based permissions, background checks
Dependency Vulnerability	Medium	Medium	Monthly npm audit, automated security alerts, rapid patching
Accidental Data Deletion	Low	Medium	Backups, audit trail, soft delete (can be implemented), confirmation prompts

High Priority Risks: Implement daily backups immediately (change backup interval to 24 hours). Consider enabling database replication for zero data loss. Prioritize 2FA implementation for all admin users.

4.6 Performance Metrics & Scalability

Current Performance Benchmarks:

Metric	Current Value	Target (SLA)	Status
Average Page Load Time	1.5-2.5 seconds	< 3 seconds	✅ Meeting
API Response Time (95th percentile)	200-500 ms	< 1 second	✅ Meeting
Database Query Time (avg)	50-100 ms	< 200 ms	✅ Meeting
Concurrent Users Supported	100-150 users	200+ users	⚠️ Near capacity
System Uptime (monthly)	99.5%	99.9%	⚠️ Below target
Database Size	2-5 GB	< 100 GB	✅ Well within limits
File Storage Usage	10-20 GB	< 500 GB	✅ Well within limits

Scalability Limits & Growth Plan:

Current Limits:

Max Concurrent Users: 150-200 (limited by single server)
Max Database Size: 100 GB (VPS storage limit)
Max API Throughput: 1000 requests/minute
Geographic Reach: Single region (India)

Scaling Strategy:

Vertical Scaling: Upgrade VPS to 16GB RAM, 8 vCPUs (supports 500 users)
Horizontal Scaling: Load balancer + multiple app servers (supports 1000+ users)
Database Scaling: Read replicas for analytics queries
CDN Integration: CloudFront/Cloudflare for static assets

Document Revision History:

Version	Date	Changes	Author
1.0		Initial system documentation for IT governance review	System Administrator

Starengts Technologies | Gate Pass Management System v1.0.0
Document generated:
For questions or clarifications, contact: support@starengts.com

Visitor Management System

Reset Password

Enter Reset Code

Gate Pass Status

Gate Pass History

Register Visitor

🔍 Search Existing Visitors

Edit Visitor Information

Create New Gate Pass

User Management

Personal & Corporate Information

Role & Access Permissions

Location Information

🔍 Search Existing Users

Advanced Analytics Dashboard

Total Visitors

Currently In

Total Out

Approved - Waiting

Pending - My Approval

Rejected

Visitor Journey

Time Analysis

Company Insights

Frequency Patterns

Saved Searches

Download & Upload

Download Reports

Bulk Upload Users

Confirm Action

Organization Management

Existing Organizations

System Documentation

System Documentation

Gate Pass Management System

Table of Contents

Section 1: Data Access & Integration

1.1 Database Schema & Structure

Core Database Tables (20+ tables)

1.2 Access Levels & Role-Based Permissions

1.3 External Services & Integrations

Current External Integrations:

1.4 Software Dependencies & Version Control

Backend Dependencies (Node.js/NPM)

Frontend Libraries (CDN/NPM)

1.5 Integration Capabilities & Extensibility

Available Integration Methods:

Future Integration Roadmap:

Section 2: Security Architecture & Authentication

2.1 Data Storage Architecture

Database Storage:

File Storage:

2.2 Authentication Method: JWT (JSON Web Tokens)

Why JWT? Authentication Method Comparison

Token Configuration & Expiry

Access Token

Refresh Token

Authentication Flow Diagram

Storage Method Explanation & Trade-offs

2.3 Security Best Practices & Implementation

Implemented Security Measures:

Planned Security Enhancements:

2.4 IT Governance: Common Questions & Answers

Q1: How is user authentication secured against brute-force attacks?

Q2: What happens if a JWT token is stolen or compromised?

Q3: How is sensitive data (passwords, PII) protected in the database?

Q4: Can user actions be traced for compliance and audit purposes?

Q5: What is the disaster recovery plan if the server crashes or data is lost?

Q6: How does the system comply with data protection regulations (GDPR, DPDPA)?

Q7: What measures are in place to prevent SQL injection and XSS attacks?

Q8: How is role-based access control (RBAC) enforced across the system?

2.5 Production Security Checklist

2.6 Encryption & Data Protection

2.7 Backup & Disaster Recovery

Current Backup Configuration:

Disaster Recovery Procedures:

Scenario 1: Database Corruption

Scenario 2: Complete Server Failure

Scenario 3: Accidental Data Deletion

Section 3: System Lifecycle & Maintenance