Personal project • legacy modernization • living documentation

Farmer Buddy, understood end to end.

A code-evidence-based guide to what the system does, how its 62 screens fit together, where the original implementation is incomplete, how to run it safely, and how to evolve it into a credible modern agriculture platform.

ASP.NET Web FormsC# / .NET FrameworkSQL ServerIIS ExpressMermaid architectureSanitized for GitHub
01 — Executive overview

One product, two historical copies

“Farmer Hub” and “Farmer Buddy” are not two independent applications. They are two snapshots of the same ASP.NET Web Forms website. The newer root-level copy is the baseline for this personal-project repository; the nested Farmer Hub copy is retained only as historical evidence.

62ASPX pages
69C# code-behind files
5master pages
8 + 4existing + missing database tables
454identical files shared by both copies
0automated tests found
Positioning: From this point forward the work is described as a personal project and modernization case study. The repository does not claim internship delivery, production usage, or outcomes that cannot be demonstrated from the code.

Product intent

The application aims to give farmers and agricultural learners a single portal for crop/product information, articles, government schemes, insurance, educational video, weather, questions to experts, profiles, and administrative content management.

What is demonstrably working

  • The website-folder project compiles with the installed ASP.NET compiler.
  • The public home page is served by IIS Express and returns HTTP 200.
  • Core CRUD screens and SQL-bound lists exist for users and administrators.
  • The clean project excludes historical personal data, uploaded portraits, IDE state, and embedded secrets.
02 — Repository discovery

How the source folders relate

flowchart LR
  A["Farmer Hub folder\nEarlier snapshot"] --> C["454 identical shared files"]
  B["FarmerBuddy-Design-2023\nNewer snapshot"] --> C
  A --> D["Historical SQL + reports + presentation"]
  B --> E["12 extra files\nIDE metadata + admin photos"]
  A --> F["3 changed shared files"]
  B --> F
  B --> G["Sanitized Personal Project\nGitHub-safe working copy"]
  style G fill:#78d44b,color:#07140d,stroke:#2e7d32
        
LocationMeaningDecision
FarmerBuddy-Design-2023Newer application snapshot; 469 files and about 37 MB.Technical baseline only; leave unchanged.
Farmer Hub/FarmerBuddy-Design-2023Earlier application snapshot; 457 files and about 35 MB.Historical comparison only.
Farmer Hub/FarmerBuddy.sqlOriginal schema plus plaintext accounts and personal data.Never publish. Replaced with clean schema.
FarmerBuddy-Personal-ProjectSanitized modernization workspace.Only this folder should become the public repository.

Only three common files differ between snapshots: web.config, UserLogin.aspx.cs, and USER/LoginMasterPage.master. That level of overlap is decisive evidence that this is version duplication, not two products.

03 — Current architecture

A server-rendered three-layer website

Pages and master pages form the presentation layer. C# code-behind performs event handling and business rules. ADO.NET commands and ASP.NET SqlDataSource controls access SQL Server directly; there is no dedicated service or repository layer.

flowchart TB
  Browser["Desktop / mobile browser"] --> IIS["IIS Express or IIS"]
  IIS --> Public["Public Web Forms\nHome, registration, login"]
  IIS --> User["User area\nArticles, crops, schemes, advice"]
  IIS --> Admin["Admin area\nContent and user management"]
  Public --> CB["C# code-behind"]
  User --> CB
  Admin --> CB
  Public --> SDS["SqlDataSource controls"]
  User --> SDS
  Admin --> SDS
  CB --> ADO["System.Data.SqlClient"]
  SDS --> DB[("SQL Server\nFarmerBuddy")]
  ADO --> DB
  CB -.-> Weather["Weather API\nlegacy integration"]
  CB -.-> SMS["SMS gateway\nlegacy integration"]
        

Presentation

ASPX markup, five master pages, Bootstrap-era styles, jQuery plugins, images and Web Forms server controls.

Application logic

Page events in code-behind. Validation, redirects, file handling, SMS/weather calls and database commands are mixed together.

Persistence

SQL Server tables accessed through connection strings named FarmerBuddyConnectionString and LIS.

Deployment

A website-folder project targeting .NET Framework 4.5. There is no solution or project file and no package manifest.

Typical request lifecycle

sequenceDiagram
  actor F as Farmer
  participant P as ASPX page
  participant C as Code-behind
  participant S as SQL Server
  F->>P: Submit login / search / content form
  P->>C: Raise server-side event
  C->>C: Read controls and session
  C->>S: Execute query or command
  S-->>C: Rows / scalar / affected count
  C-->>P: Bind controls or redirect
  P-->>F: Render complete HTML response
        
04 — People and journeys

Three main roles, but incomplete authorization

flowchart LR
  Visitor["Visitor"] --> Register["Register"]
  Visitor --> Browse["View public home"]
  Register --> Login["User login"]
  Login --> Farmer["Farmer workspace"]
  Farmer --> Learn["Articles, crops, video"]
  Farmer --> Support["Schemes and insurance"]
  Farmer --> Ask["Ask expert"]
  Farmer --> Profile["Profile / password"]
  AdminLogin["Admin login"] --> Admin["Admin dashboard"]
  Admin --> Content["Manage content"]
  Admin --> Users["Verify and manage users"]
  Admin --> Answers["Answer questions"]
  Expert["Expert role"] -. "represented in data,\nnot fully separated in navigation" .-> Answers
        
Authorization warning: directories are not protected by a centralized authentication rule. Knowing a URL may bypass the intended login journey. Proper role-based authorization is a release blocker.
05 — Module inventory

Feature coverage by area

ModuleEvidence in codeStatusPrimary work remaining
Public homeDefault page, master layout, tips feedRunsNew visual system, accessible navigation, verified content
RegistrationRegistration form and insert commandPartialPassword hashing, uniqueness validation, safe uploads
User loginPBKDF2 verification and centralized route guardFirst passSession renewal, throttling/lockout and automated authorization tests
Admin loginDatabase-backed verified Admin role; hardcoded account removedFirst passAdmin bootstrap script, lockout, audit trail and role tests
ArticlesAdd, list, search, view, editMostly presentParameterize search/details and sanitize rich text
Crop marketplaceProduct catalogue and admin CRUDMostly presentClarify marketplace scope, pricing types, inventory
SchemesGovernment scheme list and admin CRUDMostly presentCorrect naming, source links, review/expiry dates
InsuranceInsurance list and admin CRUDMostly presentURL validation and query parameterization
VideosTwo overlapping video tables and screensDuplicatedConsolidate model and validate embed allowlist
Expert adviceQuestion, answer, status flowBroken contractAlign eid/question fields and expert permissions
Password recoveryUnsafe legacy password-by-SMS behavior removedSafely disabledImplement expiring single-use reset tokens without revealing passwords
WeatherExternal API integration pageLegacyHTTPS endpoint, server-side secret, resilient errors
SearchAdmin and user LIKE searchesUnsafeParameterized queries, paging and empty-state design
06 — Data model

Clean compatibility schema

The historical dump defined eight tables but the application references four more. The new schema adds the missing structures, primary keys, useful constraints and synthetic sample content without copying historical personal records.

erDiagram
  REGISTRATION {
    int id PK
    nvarchar username UK
    nvarchar e_mail UK
    nvarchar password
    nvarchar user_type
    bit veriefied
  }
  EXPERT_ADVICE {
    int eid PK
    nvarchar username FK
    nvarchar question
    nvarchar answer
    nvarchar status
  }
  OTP_DATA {
    bigint id PK
    nvarchar username FK
    nvarchar otp
    datetime expires_at
  }
  ARTICLE_DATA { int aid PK nvarchar article_title nvarchar authors }
  PRODUCT_DATA { int pid PK nvarchar pname decimal mrp_amount decimal sell_amount }
  GOV_SCHEME_DATA { int gid PK nvarchar schemeName decimal amount }
  CROP_INSURANCE_DATA { int cid PK nvarchar companyName nvarchar InsuranceName }
  VIDEOS_DATA { int vid PK nvarchar title nvarchar link }
  VIDEO { int id PK nvarchar title nvarchar url }
  GRAINS { int id PK nvarchar grains UK }
  TIPS_DATA { int id PK nvarchar tips }
  REGISTRATION ||--o{ EXPERT_ADVICE : asks
  REGISTRATION ||--o{ OTP_DATA : requests
        
Compatibility versus final design: the clean script intentionally preserves legacy misspellings such as GovScemeData, CroplnsuranceData, and veriefied so the existing pages can run. A later migration should rename these through a controlled versioned change.
07 — Security review

Public release requires a security milestone first

flowchart LR
  Internet["Untrusted browser input"] --> Forms["Forms and query strings"]
  Forms --> App["Legacy Web Forms app"]
  Upload["Uploaded files"] --> App
  App --> DB[("User and content data")]
  App --> APIs["Weather / SMS providers"]
  subgraph Trust boundary
    App
    DB
  end
  R1["SQL injection"] -.-> Forms
  R2["Stored XSS"] -.-> Forms
  R3["Arbitrary file upload"] -.-> Upload
  R4["Broken access control"] -.-> App
  R5["Secret leakage"] -.-> APIs
        
Critical
Plaintext and hardcoded credentials in the historical source. The clean copy now uses PBKDF2 hashes and a database-backed Admin role, but existing historical accounts require a controlled password migration and lockout/audit controls remain.
Critical
Secrets and personal data in historical artifacts. The original configuration, integrations, SQL inserts, phone numbers, emails, passwords, and photographs must never enter the public repository.
High
SQL injection. Multiple list, search, and detail pages concatenate query-string or search text into SQL. Every value must become a typed parameter.
High
Broken authorization. Page folders lack a reliable central role check. Authentication must be enforced server-side on every protected route.
High
Unsafe uploads and validation disabled. Uploaded files can enter web-served folders and request validation was disabled globally. Store outside the web root, verify content, randomize names and impose limits.
Medium
Obsolete integrations and dependencies. Legacy HTTP endpoints, old jQuery/Bootstrap assets and weak error handling increase risk and maintenance cost.

Sanitization already applied to this working copy

  • Excluded .vs metadata and all user/admin upload directories.
  • Did not copy the historical SQL dump or its personal records.
  • Removed the obsolete date-triggered deletion class from the public copy.
  • Replaced hardcoded database credentials and API secrets with empty configuration placeholders.
  • Re-enabled ASP.NET request validation and safer cookie defaults.

First security repairs applied

  • New registrations and password changes store PBKDF2 hashes instead of plaintext.
  • The hardcoded administrator account was removed in favor of a verified database role.
  • Central route checks now protect user, administrator and super-administrator pages.
  • Uploaded profile images are restricted by size/type, randomized and stored below App_Data.
  • The insecure password-by-SMS recovery flow is disabled until token-based recovery is implemented.
08 — Gaps and defects

Concrete problems found in code

FindingImpactRecommended correction
ExpertAdvice.aspx.cs uses id/que; schema uses eid/question.Question submission fails.Use one model and migration; add integration test.
Password recovery requests Registration.mobile; schema uses mobile_no.OTP recovery fails.Correct the field and redesign recovery securely.
App references Grains, Image_Details, OtpData and TipsData absent from dump.Specific screens fail at runtime.Clean schema adds active tables; remove unused Image_Details code.
Configuration keys AR, EMP and LIS_local are referenced but absent.Runtime null connection strings.Consolidate to one named connection string and typed settings.
SuperAdmin and user master pages link to missing pages.Broken navigation.Remove dead links or implement routes with acceptance tests.
Two video tables (Video, VideosData).Confusing ownership and duplicate CRUD.Migrate to a single ContentVideo model.
Numeric data stored as text in legacy schema.Incorrect sorting and weak validation.Use decimal types and constraints.
No solution, project file, package manifest, CI or tests.Hard-to-repeat build and risky change process.Add scripted compile now; migrate to SDK-style solution later.
09 — Local deployment

D: drive development topology

flowchart LR
  Dev["Developer on Windows"] --> Script["scripts/Start-FarmerBuddy.ps1"]
  Script --> IIS["IIS Express\nlocalhost:51873"]
  IIS --> Site["D:\\Saurabh Dindokar Career\\FarmerBuddy-Personal-Project"]
  Site --> Static["Public page and assets"]
  Site -. "when installed" .-> SQL["SQL Server Express\nFarmerBuddy database"]
  Schema["database/FarmerBuddy.Schema.sql"] --> SQL
        
  1. Run scripts/Test-Build.ps1 to compile every page.
  2. Run scripts/Start-FarmerBuddy.ps1 to start IIS Express.
  3. Open http://localhost:51873/Default.aspx.
  4. For data screens, install SQL Server Express and execute the clean schema against a database called FarmerBuddy.
  5. Keep API keys and local credentials outside Git using ignored local settings.
Current machine limitation: IIS Express is installed, but no Microsoft SQL Server service or LocalDB command is available. Therefore public rendering and compilation can be verified now; database journeys cannot honestly be marked as locally verified yet.
10 — Test strategy

Build confidence in layers

1. Static safety

Secret scan, PII scan, dead-link scan, dependency inventory, unsafe SQL pattern scan and upload-path review.

2. Compilation

Run aspnet_compiler on every commit and treat new warnings as regressions.

3. Database integration

Create a clean database, apply schema from zero, verify each CRUD module and check constraints.

4. Browser journeys

Automate visitor, farmer, expert and administrator journeys at desktop and mobile widths.

5. Security

Test authorization, session fixation, XSS, SQL injection, upload validation, brute-force protection and secret absence.

6. Accessibility

Keyboard navigation, focus order, semantic labels, contrast, reduced motion and screen-reader landmarks.

11 — Target architecture

Move toward a maintainable platform

flowchart TB
  Web["Responsive web client\naccessible design system"] --> API["ASP.NET Core Web API"]
  API --> Auth["ASP.NET Core Identity\nroles + secure recovery"]
  API --> Services["Domain services\ncontent, advice, catalogue"]
  Services --> EF["Entity Framework Core"]
  EF --> DB[("SQL Server / PostgreSQL")]
  Services --> Files["Private object storage\nvalidated uploads"]
  Services --> Integrations["Weather + notification adapters"]
  API --> Obs["Structured logs, metrics, tracing"]
  CI["GitHub Actions"] --> Tests["Build, test, scan"]
  Tests --> Deploy["Versioned deployment"]
        

The target separates UI, application rules, persistence, integrations and operations. It preserves the product idea while replacing the most fragile implementation choices. A strangler-style migration can keep useful content screens available while each module moves behind tested services.

12 — Delivery roadmap

Finish in evidence-based phases

gantt
  title Farmer Buddy personal-project modernization
  dateFormat  YYYY-MM-DD
  axisFormat  %d %b
  section Foundation
  Inventory, sanitize, documentation :done, f1, 2026-08-18, 3d
  Repeatable local database           :f2, after f1, 4d
  section Security
  Identity and role authorization     :s1, after f2, 7d
  Parameterized data access           :s2, after f2, 7d
  Safe uploads and integrations       :s3, after s1, 5d
  section Product
  Repair expert advice and recovery   :p1, after s2, 5d
  Modern responsive visual system     :p2, after s3, 8d
  Content quality and accessibility   :p3, after p2, 5d
  section Delivery
  Automated tests and CI              :d1, after s2, 8d
  Container/cloud deployment option   :d2, after d1, 6d
        
GateDefinition of done
FoundationOne public-safe repository, clean repeatable schema, successful compile, architecture docs and issue backlog.
Secure accessHashed passwords, no hardcoded accounts, protected routes, session renewal, role tests and safe recovery.
Secure dataNo concatenated SQL, typed models, validated URLs/files, private upload storage and migration history.
Product completeAll navigation works; farmer/expert/admin journeys pass; empty, loading and error states exist.
Portfolio readyLive demo or video, public repository, test evidence, architecture diagrams and truthful case-study outcomes.
13 — Portfolio narrative

Present the work as engineering judgment

The strongest story is not “I built 62 pages.” It is “I recovered a legacy agriculture portal, proved which snapshots were duplicates, removed sensitive data, documented the system, restored a repeatable build, identified concrete security defects, and designed a staged modernization.”

Problem

A useful product concept was trapped in duplicated, undocumented legacy source with incomplete schema and unsafe defaults.

Approach

Evidence-led inventory, checksum comparison, compilation, local smoke testing, schema reconstruction, sanitization and architecture modeling.

Current outcome

A GitHub-safe personal-project foundation with detailed documentation, scripts, clean schema and an explicit risk-driven roadmap.

Next proof

Secure authentication, database-backed journey tests, redesigned graphics and a deployable modern slice.

Truthful wording: Use “personal legacy-modernization project.” Avoid claims of production scale, user adoption, performance improvement, or cloud deployment until measurements and links exist.
14 — Decision log

Why the repository is structured this way

DecisionReasonConsequence
Use the newer root snapshot as baseline.It contains all common code plus later changes.Historical folders remain evidence, not active source.
Create a separate personal-project directory.Prevents accidental damage and makes sanitization auditable.Future edits happen only in the new directory.
Exclude original SQL and uploads.They contain plaintext credentials and personal data.Clean schema and synthetic data replace them.
Keep Web Forms for the first milestone.Allows reproducible build and incremental repair before rewrite.Legacy risk remains visible until phased migration.
Do not claim database verification yet.This machine has no SQL Server engine installed.Installation and integration verification remain a named task.
Document before redesigning every screen.Architecture and acceptance criteria prevent random cosmetic changes.Graphics work will follow a coherent product direction.