👨‍💻 Making the College Portal Better & More Secure

It's been a rewarding few weeks. We've gone from building out a new home page to creating a suite of content pages—for student living, careers, and announcements. The site is starting to feel like a real, functioning college portal. But as the app has grown, Kai and I have shifted our focus from simply adding features to making the existing ones more secure and user-friendly.

This has been a crucial learning step for Kai. He's not just building what's visible; he's learning how to build a strong foundation that protects the data and provides a smooth experience for users.

🔑 Step 1: From Direct Queries to Stored Procedures

In our initial work on the Students.aspx page, we were using direct SQL statements inside the C# code. This works, but it leaves the application vulnerable to a serious security threat called SQL injection. I explained to Kai that an attacker could input malicious code into a form field to delete data or access unauthorized information.

To fix this, we moved the data manipulation logic into a stored procedure on the SQL Server. This is like a pre-compiled, secure function that resides in the database. When the app needs to add a student, it just calls the procedure and passes the data as parameters, which the database handles safely.

Our C# code changed from something like this:

string sql = "INSERT INTO Students (Name, Email) VALUES ('" + txtStudentName.Text + "', '" + txtEmail.Text + "')";
// Execute SQL

To a much safer call to our stored procedure:

// In Students.aspx.cs
protected void btnAddStudent_Click(object sender, EventArgs e)
{
    // Call our secure service method
    StudentService.AddStudent_Secure(txtStudentName.Text, txtEmail.Text);
}

// In StudentService.cs
public static void AddStudent_Secure(string name, string email)
{
    // Call the stored procedure
    // No more direct SQL!
}

Kai: "I get it now. It's like having a bouncer at the door. The stored procedure checks everything before it lets it in, so nothing bad gets through. It makes so much more sense to handle security in the database itself."

🛡️ Step 2: Building an Error-Proof App

Next, we tackled a different kind of problem: user experience. What happens if the database is down or a field is left blank? The app would just crash or show a generic, confusing error.

We added try...catch blocks to our C# code. This is like a "safety net" for the code. It allows us to try to perform an action (like adding a student) and, if anything goes wrong, catch the error before the app breaks.

Here’s the updated C# code for adding a student, now with proper error handling and a user-friendly message:

protected void btnAddStudent_Click(object sender, EventArgs e)
{
    try
    {
        StudentService.AddStudent_Secure(txtStudentName.Text, txtEmail.Text);
        lblMessage.Text = "Student added successfully!";
        lblMessage.ForeColor = System.Drawing.Color.Green;
    }
    catch (Exception ex)
    {
        lblMessage.Text = "Error: Something went wrong. Please try again.";
        lblMessage.ForeColor = System.Drawing.Color.Red;
        // For debugging, we can log the full error:
        // System.Diagnostics.Debug.WriteLine(ex.Message);
    }
}

This simple change means the app won’t crash. Instead, it gives the user clear feedback.

✨ Final Thoughts

It's been a fantastic few weeks. Kai's not just a front-end developer anymore; he's becoming a full-stack thinker. He now understands that a great app isn't just about how it looks, but how secure, stable, and user-friendly it is. By thinking about things like stored procedures and error checking, he's building a foundation that can scale and last.

Kai: "Fixing that broken link felt good, but knowing the data is secure and the app won't crash is a whole new level. It's not just a project anymore; it's something I can trust and build on."

We’ve now got a solid, secure framework. What do you think we should work on next?

Search This Blog