What project I contributed
In the third week of hacktoberfest, I revisited the OpsiMate repo which i found on the first week of hacktoberfest. OpsiMate is an all-in-one platform designed for DevOps and IT teams to manage and monitor their infrastructure in one place. I had discovered this repo in the first week. Initially, I was hesitant about contributing to such a big project, but after gaining confidence through other contributions, I decided to submit a PR which closed this issue.This contribution led me to connect with the maintainer, and we had a great discussion on Slack.
What Was The Issue
The problem was related to API key validation on both the client-side and server-side. Users could enter API keys with whitespace characters, which violates the standard for API keys. Once I understood the issue, I knew exactly what to search for in the codebase. I added Zod validation to reject API keys containing spaces and display an error message: API key cannot contain spaces when validation fails. Additionally, I changed the type from any to a specific object structure in the schemas.ts file.
Previous Validation
credentials: z.record(z.any()),
Fixed Validation
credentials: z.object({
apiKey: z.string().refine(
(val) => !/\s/.test(val),
{ message: 'API key cannot contain spaces' }
).optional(),
appKey: z.string().refine(
(val) => !/\s/.test(val),
{ message: 'Application key cannot contain spaces' }
).optional(),
}).passthrough(),
I also added validation rules for apiKey and appKey on the client-side that detect whitespace using the regex pattern /\s/ in the ValidationFeedback.tsx file:
apiKey: [
{
id: 'apikey-no-spaces',
label: 'API key cannot contain spaces',
validator: (value: string) => {
if (value.length === 0) return true;
return !/\s/.test(value);
},
},
],
appKey: [
{
id: 'appkey-no-spaces',
label: 'Application key cannot contain spaces',
validator: (value: string) => {
if (value.length === 0) return true;
return !/\s/.test(value);
},
},
],
Impact: Frontend and Backend Validation
My implementation created a validation layer across both frontend and backend. Users now receive immediate visual feedback when adding API keys, which improves the user experience. Also, the backend validation ensures data integrity by preventing invalid data from reaching the database.
Gained Experience
I had to dive deep into Zod schemas to understand the type system. This experience showed how using any can destroy your entire validation strategy. In TypeScript, any should can be used temporarily, when migrating JavaScript code. any is not recommended in the TypeScript community because it disables type checking entirely, and types are determined at run-time which raises the question: why do we use TypeScript at all?
I also gained a deeper knowledge for Zod's runtime validation capabilities. Unlike TypeScript's compile-time checking, Zod validates data at runtime, ensuring that invalid data never enters your application. Additionally, this contribution boosted my confidence in working with large, unfamiliar codebases which intimidated me when I started my open source journey.
Communication With Maintainer
I met the maintainer online via Slack and had a fruitful conversation. I realized that you don't need to be familiar with an entire codebase to make meaningful contributions, because with time and effort, understanding comes naturally. It was cool to talk with a DevOps engineer and learn from their perspective. I was honest about my gaps in knowledge, particularly regarding Docker and Kubernetes. However, I'm confident that with dedication, I'll become comfortable in these technologies. I created an issue for implementing a search feature for audit logs, which I'll cover in an upcoming blog post where I'll discuss the implementation and what I learned.