daniel-orlov / quotes-server

Quotes server is an example of how I normally build an HTTP server. It started as a solution for a technical assignment and later turned into a showcase.

Software Engineer. Based in Denmark 🇩🇰

I'm currently working at Maersk, integrating teams to make zero-emission future a reality.

Note: Before joining Maersk, I have been mostly working with GitLab in the last few years, so here, on GitHub, you will find my personal projects, learning projects, some open source contributions.

If you're curious about my usual working style, just scroll down to the pinned repositories, where you'll find a collection of showcases.

Latest blog posts

• Slog: The Future Face of Go Logging?
• Go Excellence: Three Common Interface Mistakes Even Seasoned Devs Overlook
• Go Excellence: A Deep Dive into Error Handling
• Go Excellence: Dodge Three Mistakes and Tame the Dreadful Named Results
• Go Comments: The Missing Link in Your Code’s Story
• Bug Busters 101: Unleashing the Power of Precision Bug Reporting
• Ten Commandments of the Eternal Junior Developer

My GitHub Stats

My Tech Stack

Note: Some icons are missing, I will add them as soon as they are available.

Currently focused on ...

Digging deeper into the world of Kubernetes, Kafka and Azure

Learning next

Drop me a line

quotes-server's Issues

Add authentication middleware

Is your feature request related to a problem? Please describe.
Currently, our server lacks a standardized and secure authentication mechanism. We need a robust solution to authenticate users based on their username and password, ensuring that only authorized users can access protected resources and perform sensitive operations. Implementing username-password authentication as a middleware will help us improve the overall security posture of our application.

Describe the solution you'd like
I propose the addition of an authentication middleware based on username-password authentication to our server. This middleware should handle the following key functionalities:

1. User Registration: Provide an endpoint to allow new users to create an account with a unique username and a strong, securely hashed password.
2. User Login: Implement an endpoint that accepts a username and password and verifies them against the stored credentials. Successful authentication should generate a session token or JSON Web Token (JWT) for subsequent authenticated requests.
3. Password Management: Include mechanisms for users to reset their passwords securely in case they forget or need to change them.
4. Password Encryption: Ensure that user passwords are securely hashed and encrypted using a strong cryptographic algorithm to prevent unauthorized access to sensitive information.
5. Session Management: Maintain authenticated user sessions securely to provide seamless access to protected resources without repeated logins.

Describe alternatives you've considered
Currently, we might be using basic authentication or no authentication at all. However, implementing a dedicated authentication middleware with username-password authentication will significantly enhance the security of our application and provide a more user-friendly login experience.

Additional context
The addition of username-password authentication middleware will strengthen our server's security and protect user accounts from unauthorized access. Any specific preferences or requirements, such as the choice of encryption algorithms or session management approach, should be discussed in more detail.

This is related to #3

User Add authorization middleware

Is your feature request related to a problem? Please describe.
Currently, our server lacks a robust and flexible authorization mechanism. Managing access control and permissions for different users and roles is becoming increasingly complex, especially as the application grows in size and functionality. We need a solution that can handle fine-grained access control and is easy to integrate into our existing server architecture.

Describe the solution you'd like
I propose the addition of an authorization middleware based on Kasbin to our server. Kasbin is a powerful and flexible open-source library that provides support for Role-Based Access Control (RBAC) and Access Control Lists (ACL). By integrating Kasbin as a middleware, we can centralize and streamline the authorization logic, making it easier to manage and maintain access control policies.

The authorization middleware should include the following key features:

1. Policy Management: Ability to define and manage access control policies in a structured and organized manner.
2. RBAC Support: Support for Role-Based Access Control, allowing us to assign roles to users and manage permissions at a higher level.
3. Policy Enforcement: Seamless enforcement of authorization policies on API endpoints and resources.

Describe alternatives you've considered
Currently, we might be using custom authorization logic or other authorization middleware. However, integrating Kasbin will provide us with a more robust and feature-rich authorization solution, with a focus on maintainability and extensibility.

Additional context
Adding the Kasbin-based authorization middleware will significantly enhance our server's security and make managing access control more manageable. Any relevant details or considerations regarding the integration, such as the choice of policy storage or policy syntax preferences, would be beneficial for further discussion.

This issue is related to #3

Add OTel compatible telemetry

Is your feature request related to a problem? Please describe.
Currently, our server lacks comprehensive telemetry capabilities, which makes it challenging to gather essential performance and operational data. Proper telemetry is crucial for monitoring, debugging, and optimizing the server's performance and resource utilization. Adopting an open telemetry standard will provide a unified and interoperable approach to collecting and exporting telemetry data.

Describe the solution you'd like
I propose adding open telemetry compatible telemetry to our server. OpenTelemetry is an open-source project that provides a vendor-agnostic and standardized way to instrument applications for telemetry data collection. By integrating OpenTelemetry into our server, we can gain insights into various aspects of the application's performance, including:

1. Distributed Tracing: Implement distributed tracing to monitor the flow of requests across multiple services, identifying bottlenecks and performance issues.
2. Metrics Collection: Gather essential performance metrics, such as request latency, error rates, and resource usage, to analyze server health and efficiency.
3. Context Propagation: Ensure context propagation across different parts of the server and services, allowing us to correlate related telemetry data accurately.
4. Compatibility: Guarantee compatibility with popular telemetry backends, such as Jaeger, Prometheus, and Zipkin, by adopting the OpenTelemetry standard.

Describe alternatives you've considered
Without adopting OpenTelemetry, we might have to rely on custom telemetry solutions or third-party libraries that could lack standardization and interoperability. By embracing OpenTelemetry, we align with industry best practices and facilitate better integration with existing monitoring and observability tools.

Additional context
Incorporating open telemetry compatible telemetry will significantly improve our server's observability, making it easier to detect and diagnose issues. Any specific preferences or considerations for telemetry backends or data exporters should be discussed to ensure seamless integration.

Add Open API Spec

Is your feature request related to a problem? Please describe.
The server API lacks proper documentation and a standardized way to define its endpoints, request/response formats, and authentication requirements. This makes it challenging for developers to understand and interact with the API effectively.

Describe the solution you'd like
I would like to request the addition of an OpenAPI Specification (formerly known as Swagger) for the server API. By providing an OpenAPI Spec, we can describe the API's capabilities in a machine-readable format, including details on each endpoint, the expected input parameters, possible responses, authentication methods, and other relevant information. This will not only improve the API's documentation but also enable developers to generate client libraries, perform automated testing, and explore the API using various tools.

Describe alternatives you've considered
There are some alternatives to the OpenAPI Spec, such as API Blueprint and RAML, but OpenAPI has gained widespread adoption and has a rich ecosystem of tools and support. Without a standardized API specification, developers may have to rely on ad-hoc documentation or struggle with understanding the API through trial and error.

Additional context
Let's use the latest OAS, if possible

Improve the granularity of the method middlewares are assigned to endpoint groups

Is your feature request related to a problem? Please describe.
The current approach to passing middlewares during router initialization has limitations, particularly when we want to configure middlewares on a per-endpoint basis. Presently, it is either an all-or-nothing scenario, where all middlewares are added to a certain endpoint group or none are added at all. This lack of flexibility makes it challenging to customize middleware behavior for specific endpoints.

Describe the solution you'd like
I propose an improvement to the way middlewares are passed during router initialization. The goal is to provide more granular control over middleware configuration for individual endpoints. Here are some suggested options to achieve this:

1. Endpoint-Specific Middleware: Allow the ability to specify middleware functions or middleware arrays for each endpoint separately. This way, we can define unique middleware chains tailored to the needs of each endpoint.

2. Middleware Configuration Object: Introduce a configuration object that maps endpoints to the middleware functions or arrays they require. This object would allow us to easily configure middleware chains for different endpoints in a structured manner.

3. Middleware Priority: Enable setting priorities or ordering for middleware execution at the endpoint level. This ensures that specific middleware functions are executed before others, providing greater control over request processing.

4. Default Middleware: Retain the option to specify default middlewares that will be applied to all endpoints, but also allow overriding or extending these defaults at the endpoint level.

Describe alternatives you've considered
The current approach of passing middlewares as an array during router initialization is straightforward but lacks the flexibility needed to configure middleware behavior on a per-endpoint basis. The suggested options aim to address this limitation while maintaining backward compatibility.

Additional context
By improving the way middlewares are passed to the router initialization, we can achieve a more flexible and modular approach to request handling. This will enhance the server's ability to handle different types of endpoints with specific middleware requirements. Any further suggestions or considerations for the proposed changes would be valuable for discussion and implementation.

Add user management

Is your feature request related to a problem? Please describe.
Currently, the server lacks a dedicated user service and user storage system. As the number of users grows, it becomes challenging to manage user-related operations, such as user registration, authentication, profile management, and access control. This leads to code duplication, potential security vulnerabilities, and difficulties in maintaining user data consistency.

Describe the solution you'd like
I would like to propose the addition of a user service and user storage module to the server. The user service will act as the central component responsible for handling user-related operations, while the user storage module will manage the persistence and retrieval of user data.

The user service should offer the following functionalities:

1. User registration: Allows new users to sign up and create an account.
2. User authentication: Provides secure authentication mechanisms for users to access their accounts.
3. Profile management: Enables users to update their profiles, including personal information, preferences, and settings.
4. Access control: Implements role-based access control to manage permissions for different user types (e.g., admin, regular user).
5. Password management: Includes features like password reset and password strength requirements to enhance security.
6. User search and retrieval: Supports searching for users based on specific criteria.

The user storage module should be responsible for securely storing and retrieving user data, including user credentials, profiles, and related information. It should integrate with the database or any other data storage system to ensure data persistence.

Describe alternatives you've considered
Without a dedicated user service and user storage, user-related functionality might be scattered across different parts of the server codebase. However, implementing a separate user service can lead to better code organization, easier maintenance, and improved security.

Additional context
The whole functionality doesn't have to be implemented in one go, so feel free to break it down into smaller deliverables as needed.

In-memory challenge storage is leaking if the client requests a challenge and never comes back

Describe the bug
The current implementation of the challenge storage is prone to memory leaks if operated during the long period of time.

To Reproduce
Steps to reproduce the behavior:

1. Run server with the standard config.
2. Request challenge by hitting any endpoint behind the Proofer middleware.
3. Repeat the step two from different IP addresses and don't come back with solutions.
4. The challenges stay in the storage until they are solved/server is stopped.

Expected behavior
Challenges have TTL and are cleaned up even if not solved

Screenshots
If applicable, add screenshots to help explain your problem.

How do you run the server (please complete the following information):

• on OS: any OS
• on arch: any arch
• using User-Agent: any User-Agent

Additional context
This could be solved with TTL for in-memory starage and/or Redis