1.

Portal SPOC Login Validation

Overview

The Portal SPOC (Single Point of Contact) login validation system plays a
critical role in securing access to internal resources. It is intended to
authenticate authorized users and prevent unauthorized access. During the
internship, I was assigned to design, develop, and test the login system with
necessary security validations.

Design Objectives

 Authenticate users securely.

 Maintain session integrity.
 Provide user feedback upon login failure or success.
 Prevent brute force and session hijacking attacks.

Technological Stack

 Frontend: HTML5, CSS3, JavaScript

 Backend: PHP
 Database: MySQL
 Session Handling: PHP Sessions

Detailed Development Process

1. Form Creation
o A clean login form was created using HTML and styled with CSS.
o Client-side validation was added using JavaScript to ensure that
empty submissions were prevented.
o Focus management and basic accessibility features were included.
2. Backend Logic
o The backend PHP script accepted POST requests from the login
form.
o Input sanitation was performed using PHP's
htmlspecialchars() and
mysqli_real_escape_string().
o Database connection was securely established using mysqli.
o Credentials were compared using the password_verify()
function.
o If matched, session variables were set to preserve user state.
3. Session & Cookie Handling
 o Sessions were initiated on successful login using
session_start().
o The session ID was regenerated to prevent fixation attacks.
o HTTPOnly cookies were used to mitigate XSS-based session
hijacking.
4. User Feedback
o If login failed, a styled message was displayed.
o Logs were maintained for each login attempt with timestamp and
IP.
5. Security Mechanisms
o Brute-force protection was implemented using attempt counters
and temporary lockouts.
o SQL injection prevention with prepared statements
(mysqli_prepare).
o Encrypted password storage using password_hash() with the
BCRYPT algorithm.

Challenges Encountered

 Handling multiple incorrect login attempts elegantly.

 Ensuring compatibility across various browsers and screen sizes.

Testing Procedures

 Manual testing for edge cases (e.g., blank input, special characters).
 Automated testing with tools like Selenium for repeated login sequences.

Results and Impact

 Fully functional, secure login validation module.

 Reduced vulnerability exposure significantly.
 Improved authentication mechanism aligns with best practices.

2. Database Restoration in the Local System

Purpose and Objective

The goal was to recreate the production database in a local development

environment. This allows developers to test new features and debug issues in
isolation without risking damage to live data.

Environment Setup
  Installed MySQL Workbench for GUI-based interaction.
 Configured a MySQL server instance with necessary privileges.
 Ensured system compatibility (UTF-8 encoding and strict mode enabled).

Backup File Handling

 A .sql dump file was received from the system administrator.

 The file size was approximately 150 MB, with multiple interdependent
tables.
 Verified backup integrity using checksum.

Restoration Process

1. Import Method
o Used Workbench’s "Import from Self-Contained File" feature.
o Defined the default target schema.
o Selected “Dump Structure and Data”.
2. Fixes and Adjustments
o Disabled foreign key checks during import: SET
foreign_key_checks = 0;
o Identified circular dependencies and reordered insert statements.
o Adjusted SQL modes temporarily to bypass strict validation errors.

Schema Review

 Opened the ER diagram feature to visually verify table relations.

 Identified missing foreign keys and added them manually.
 Validated auto-increment behavior on primary keys.

Data Validation

 Queried high-priority tables (users, logs, activities).

 Checked for null values in non-nullable fields.
 Verified timestamps and character encodings.

Issues Faced

 Import failed on tables with triggers.

 Lock wait timeouts when multiple tables were restoring concurrently.

Resolutions

 Removed and re-created triggers after restoration.

 Split the import into two batches: schema first, data second.
Learning Outcome

 Gained deep insight into MySQL architecture.

 Understood common data integrity pitfalls during migration.

3. Change Password Page - Frontend Development

Objective

To create a responsive and user-friendly frontend interface for the 'Change

Password' functionality in the TNSDC Portal. This component is essential for
allowing users to update their credentials securely.

Technology Stack

 HTML5: For structure and form elements.

 CSS3: For styling the layout and responsiveness.
 JavaScript: For client-side validation and interactivity.

Design Requirements

 A form with fields for current password, new password, and confirm new
password.
 Clear error messages for mismatches or weak passwords.
 Responsive design compatible with mobile and desktop screens.

Development Steps

1. Layout Design
o Created a form layout with labeled input fields using HTML
<form>, <label>, and <input> tags.
o Grouped fields using semantic containers like <fieldset> and
<div>.
2. Styling and Responsiveness
o Used CSS Flexbox for vertical alignment.
o Applied media queries to adapt to screen widths under 600px.
o Implemented theme colors consistent with the TNSDC portal
branding.
3. Client-Side Validation
o JavaScript functions to:
 Check if all fields are filled.
 Ensure new password matches confirmation.
  Verify password length and complexity.
o Provided real-time feedback with dynamic error messages.
4. Accessibility Enhancements
o ARIA labels added for screen reader support.
o Tab index management for seamless keyboard navigation.

Security Considerations

 Masked password inputs with type="password".

 Disabled auto-complete to avoid browser storing sensitive data.
 Ensured no password values were retained in memory after form
submission.

User Interface Feedback

 Added success and error pop-ups using modal dialogs.

 Visual indicators like green checkmarks or red crosses shown next to
fields.
 Used icons for password visibility toggle.

Challenges Encountered

 Ensuring uniform appearance across multiple browsers.

 Managing dynamic error messages with minimal visual clutter.

Testing Procedures

 Cross-browser testing on Chrome, Firefox, and Edge.

 Form submission tests with various valid and invalid inputs.
 Mobile responsiveness tested using browser developer tools and actual
devices.

Improvements Suggested

 Integration with a password strength meter.

 Add option to show/hide passwords using eye icon.
 Use animations for smooth transition of error messages.

Outcome and Impact

 Delivered an intuitive and visually consistent UI.

 Improved user experience by reducing password update friction.
 Prepared the frontend for seamless backend integration in future stages.
4.SRS (Software Requirement Specification) Documentation

Introduction to SRS Documentation

The Software Requirement Specification (SRS) document serves as a blueprint

for the development process. It outlines the functional and non-functional
requirements for the application, detailing what the system will do and the
constraints it must operate under. The SRS helps developers, testers, and
stakeholders align their understanding of the project.

Purpose of the SRS Document

The primary purpose of the SRS document is to define the goals, constraints,
and the functionality of the system. It serves as a foundation for:

 Design: Informing the architectural and UI design decisions.

 Testing: Guiding test cases and scenarios based on defined requirements.
 Project Management: Ensuring timelines and deliverables align with the
documented requirements.

In the case of the “Change Password” page, the SRS document ensures that
everyone involved knows how the feature will work and is designed to handle
security and usability.

Components of an SRS Document

An SRS document typically includes the following components:

1. Introduction: Provides the purpose, scope, and audience of the

document.
2. System Overview: High-level description of the application, including its
major functions.
3. Functional Requirements: Detailed requirements, such as the ability to
change passwords, validations, and user roles (admin, user).
4. Non-Functional Requirements: Requirements related to performance,
security, and user experience.
5. System Features: Detailed description of features like input validation,
password strength check, and user feedback.
6. External Interface Requirements: How the system will interact with
other components, such as backend APIs and databases.
7. Appendices: Any additional resources, such as diagrams or system
workflows.
Challenges in Writing an SRS Document

Writing an effective SRS document involves understanding both the technical

requirements and the user experience. Some challenges include:

 Unclear Requirements: Sometimes stakeholders have vague or changing

requirements.
 Technical Constraints: Understanding the limitations of the current
system can affect what is feasible.
 Balancing Detail: It’s essential to provide enough detail without making
the document overly complex.

Conclusion

The SRS document is vital in ensuring that the “Change Password” page is
developed according to expectations. By clearly outlining both functional and
non-functional requirements, it serves as a foundation for the development
process.

5. CSS Styling for Change Password Page

Introduction to CSS Styling

CSS is used to enhance the visual appeal and usability of web pages. For the
“Change Password” page, CSS not only ensures the page looks aesthetically
pleasing but also contributes to the page's responsiveness and overall user
experience.

Styling Layout and Structure

The layout of the “Change Password” page is designed to be user-friendly and

intuitive. CSS is used to:

 Center the Form: Ensuring that the form is centrally aligned on the page
for easy access.
 Spacing and Margins: Proper spacing between form elements to avoid
clutter.
 Form Input Styling: Input fields are styled to be clear and easy to fill
out, with borders, padding, and background color that stand out.

Responsive Design
Responsive design ensures that the page works well on different screen sizes.
The CSS media queries help adjust the layout depending on the screen size.
This includes:

 Flexible Grids: Using percentages instead of fixed units to ensure the

layout adjusts on mobile devices.
 Mobile-first Design: The page is designed for mobile use first, with
adjustments made for larger screens.

Colors and Typography

A good color scheme and appropriate typography enhance readability and make
the page more engaging. The CSS defines:

 Colors: Using contrasting colors for buttons and feedback messages.

 Typography: Ensuring legibility with easy-to-read fonts and appropriate
font sizes.
 Feedback Messages: Success and error messages are color-coded (green
for success, red for error) for easy identification.

Button Styling and Interaction

Buttons on the page are designed to be visually distinct, with hover effects that
provide immediate visual feedback to the user. The CSS for buttons includes:

 Color: Buttons change color when hovered over to indicate interactivity.

 Size and Spacing: Buttons are appropriately sized and spaced for easy
interaction.

Conclusion

CSS plays a key role in making the "Change Password" page visually appealing,
functional, and responsive. It ensures that the page is user-friendly, easy to
navigate, and provides a positive user experience.

6. Change Password Page - Backend Integration

Introduction to Backend Integration

Backend integration refers to connecting the frontend of the “Change Password”

page with the server-side components that process requests and interact with the
database. This ensures that the password change request is processed securely
and updated in the database.

Backend Workflow

When a user submits a password change request, the following steps are
executed:

1. User Authentication: The user must first authenticate with the current
password.
2. New Password Validation: The backend validates the new password for
strength and confirms that it meets the necessary criteria.
3. Password Update: If the new password is valid, it is hashed and stored in
the database.
4. Feedback: The system sends feedback to the user, notifying them
whether the password change was successful or failed.

API Development for Password Change

The backend system uses APIs to communicate between the client and the
server. A typical “Change Password” API might involve:

 POST Request: A POST request is made to update the user’s password.

 Password Hashing: The new password is hashed using algorithms like
bcrypt to prevent storing it in plain text.
 Error Handling: The API includes error handling for issues such as
incorrect current password or weak new password.

Database Design for Storing User Passwords

The database design involves creating a secure table to store user credentials.
Best practices include:

 Storing Hashed Passwords: Passwords are never stored in plaintext but

hashed with a secure hashing algorithm.
 Salting: Adding a unique salt for each password before hashing to
increase security.

Security Measures
Security is a key consideration in the backend integration:

 Encryption: Ensuring that the password is encrypted during transmission

using HTTPS.
 Session Management: After the password is changed, the system may
invalidate old sessions to prevent unauthorized access.
 Rate Limiting: Preventing brute-force attacks by limiting the number of
password change attempts.

Conclusion

The backend integration of the "Change Password" page ensures that the system
is secure, efficient, and reliable. It handles authentication, password validation,
and updates securely, while providing essential feedback to users.

Tools Used
1. Frontend Development Tools

 HTML/CSS: For structuring and styling the page.

 JavaScript: For client-side validation (e.g., password strength, matching
fields).
 React.js/Vue.js: Optional frameworks for dynamic UI (if applicable).
 Bootstrap/Tailwind CSS: For responsive design and pre-built
components.
 VSCode/Sublime Text: Code editors for writing and managing the code.
 Git: Version control to track changes and collaborate.

2. SRS Documentation Tools

 Microsoft Word/Google Docs: For writing the SRS document.

 Markdown/LaTeX: For a more structured and technical approach.
 Lucidchart/Draw.io: For visual diagrams and flowcharts.

3. CSS Styling Tools

 Sass/LESS: CSS preprocessors for better management.

  Tailwind CSS/Bootstrap: CSS frameworks for faster, responsive design.
 Chrome DevTools: For inspecting and debugging the CSS on different
devices.
 Figma/Adobe XD: For UI design and prototyping.

4. Backend Integration Tools

 Node.js/Express.js: For server-side logic and API development.

 MySQL/PostgreSQL: For database management.
 bcrypt/Argon2: For securely hashing passwords.
 Postman/Swagger: For API testing and documentation.
 Git: For version control in backend development.

5. Testing and Deployment Tools

 Jest/Cypress: For frontend and end-to-end testing.

 Mocha/Chai: For backend unit testing.
 Docker: For containerizing the application.
 GitLab CI/GitHub Actions: For automating deployment and testing.
 AWS/Heroku: Cloud platforms for hosting and deploying the app.