Client-Side sessionStorage Value Not Populating SQLite Column in Server-Side UPDATE Query

Client-Side Data Isolation from Server-Side SQLite Operations

Issue Overview
The core challenge revolves around attempting to directly inject a client-side browser sessionStorage value (emailrandomconfirmationnumber) into a server-side SQLite database column (userConfirmedContactUsNumber) via an UPDATE query. The system comprises three layers:

1. A client-side HTML form with JavaScript generating a confirmation number stored in sessionStorage.
2. A Node.js/Express server handling form submissions.
3. A SQLite database with a table (ContactUs) that should store the confirmation number.

The UPDATE query succeeds when hardcoding a value (e.g., "987654321") but fails when attempting to use the dynamically generated sessionStorage value. This disconnect arises from fundamental mismatches between client-side browser storage, server-side data handling, and SQLite query execution.

Critical symptoms include:

• The sessionStorage value never reaches the server.
• The server-side UPDATE query operates in isolation from client-side data.
• The hidden form field (userConfirmedContactUsNumber) retains a static value ("test"), which is inserted into the database but overridden by the hardcoded UPDATE.

Client-Server Data Pipeline Breakdown
The failure stems from these interconnected factors:

1. Client/Server Context Confusion
   sessionStorage exists purely in the browser’s JavaScript runtime. Server-side code (Node.js) cannot directly access it. The server only processes data explicitly sent via HTTP requests (e.g., form submissions, AJAX). The UPDATE query’s hardcoded value works because it’s embedded in server code, but dynamic client data requires explicit transmission.

2. Form Submission Data Flow Incompleteness
   The hidden form field userConfirmedContactUsNumber has a static value="test". Even though JavaScript populates sessionStorage, the form does not transmit this value to the server. Submitting the form sends "test" as the field value, which the server inserts into the database. The subsequent UPDATE overwrites it with "987654321", masking the underlying issue.

3. Parameterization Gap in UPDATE Query
   The working UPDATE uses a hardcoded string, but dynamic values require proper SQL parameterization to avoid syntax errors and SQL injection risks. The server code uses parameterization for the INSERT query but not for the UPDATE, creating inconsistency.

4. Asynchronous Execution Blind Spots
   The server’s db.run() calls for INSERT and UPDATE lack synchronization. If the UPDATE executes before the INSERT completes (due to SQLite’s async nature), it might target an incorrect MAX(ID).

Resolving the Client-to-Server Data Pipeline

Step 1: Bridge Client-Side sessionStorage to Form Submission
Modify the client-side JavaScript to inject the sessionStorage value into the form’s hidden field before submission:

// In ContactUs.html, before form submission
document.getElementById('formContactUs').addEventListener('submit', function(e) {
  // Populate hidden field with sessionStorage value
  document.getElementById('confirmedContactUsNumber').value = 
    sessionStorage.getItem('emailrandomconfirmationnumber');
});

This ensures the dynamically generated value is included in the POST request’s payload.

Step 2: Server-Side Data Handling Refinement
The server receives the userConfirmedContactUsNumber value via req.body.userConfirmedContactUsNumber. Use this value in both INSERT and UPDATE queries with parameterization:

// In index.js, replace hardcoded UPDATE with parameterized query
const sqlUpdate = 'UPDATE ContactUs SET userConfirmedContactUsNumber = ? WHERE ID = (SELECT MAX(ID) FROM ContactUs)';
db.run(sqlUpdate, [data.userConfirmedContactUsNumber], function(err) {
  // Handle errors/responses
});

Step 3: Validate Data Flow with Logging
Add server-side logging to trace the received value:

console.log('Received userConfirmedContactUsNumber:', data.userConfirmedContactUsNumber);

Client-side, verify the hidden field’s value before submission:

console.log('Form submission value:', document.getElementById('confirmedContactUsNumber').value);

Step 4: Synchronize INSERT and UPDATE Operations
Wrap database operations in a transaction or sequence them using callbacks to ensure the UPDATE targets the correct ID:

db.serialize(() => {
  db.run(sqlInsert, params, function(err) {
    if (err) { /* handle error */ }
    db.run(sqlUpdate, [data.userConfirmedContactUsNumber], function(err) {
      if (err) { /* handle error */ }
    });
  });
});

Step 5: Sanitize and Validate Inputs
Ensure the confirmation number matches expected patterns (e.g., alphanumeric, length):

const isValidConfirmation = /^[A-Za-z0-9-]{15,}$/.test(data.userConfirmedContactUsNumber);
if (!isValidConfirmation) {
  // Reject request
}

Step 6: Mitigate SQL Injection Risks
Never concatenate client-provided values into SQL strings. Use parameterized queries exclusively:

// WRONG: Concatenation
var sqlUpdate = 'UPDATE ... = "' + value + '" WHERE ...';
// CORRECT: Parameterization
var sqlUpdate = 'UPDATE ... = ? WHERE ...';
db.run(sqlUpdate, [value]);

Step 7: Cross-Origin sessionStorage Considerations
If the form submission navigates to a different origin (domain/port), sessionStorage is not shared. Use localStorage or cookies (with appropriate flags) instead, or ensure both pages share the same origin.

Step 8: Debugging Client-Side Storage
Use browser developer tools to verify sessionStorage is set correctly:

• Console: console.log(sessionStorage.getItem('emailrandomconfirmationnumber'));
• Application Tab: Inspect sessionStorage entries.

Step 9: Database Schema Verification
Confirm the userConfirmedContactUsNumber column allows sufficient length for the generated strings:

CREATE TABLE ContactUs (
  ...
  userConfirmedContactUsNumber VARCHAR(50) NOT NULL
);

A VARCHAR(50) accommodates a 15-character string plus a timestamp suffix.

Step 10: End-to-End Testing Protocol

1. Generate confirmation number in userContactUs_Confirmed.html.
2. Submit form in ContactUs.html.
3. Check server logs for received value.
4. Query database to verify both INSERT and UPDATE used the correct value.

By systematically addressing the client-server data pipeline, ensuring parameterization, and validating each layer’s responsibilities, the userConfirmedContactUsNumber will reliably propagate from browser sessionStorage to the SQLite database.