Initial core bot activity library, CI, and extensibility

[rido-min]

This pull request introduces the foundational structure for the new Microsoft.Bot.Core library, establishing core activity and schema types, build configuration, and initial unit tests. The changes set up the basic serialization/deserialization logic for bot activities, extensibility for custom properties, and the CI workflow for automated builds and tests.

Core Library and Schema Implementation:

• Added the initial implementation of the CoreActivity class and supporting schema types (ActivityTypes, ChannelData, Conversation, ConversationAccount, and extensibility for additional properties) in the Microsoft.Bot.Core.Schema namespace, including JSON serialization/deserialization logic and reply creation methods. [1] [2] [3] [4] [5]
• Introduced a placeholder for AddBotApplication in Hosting for future extensibility.

Build and Solution Configuration:

• Added core.slnx solution file referencing the main project, unit test project, and solution items for centralized configuration.
• Established common build properties and targets in Directory.Build.props and Directory.Build.targets, including code analysis, documentation, and versioning with Nerdbank.GitVersioning. [1] [2]
• Configured the main project (Microsoft.Bot.Core.csproj) to target both .NET 8 and .NET 10, with appropriate package references for authentication and identity.

Continuous Integration:

• Introduced a GitHub Actions workflow (core-ci.yaml) for building and testing the core library on push and pull requests to the next/core branch.

Unit Testing:

• Added a unit test project (Microsoft.Bot.Core.UnitTests) with dependencies on xUnit and coverlet for code coverage, and a test suite validating extensibility and serialization/deserialization of custom activity types. [1] [2]Add .NET solution for extensible bot activity schemas with modern serialization, extension data, and reply support. Includes CI workflow, semantic versioning, and comprehensive unit tests for schema evolution and custom fields.

[heyitsaamir]

Putting this at the bottom most layer means that more space will be used up in the payload

[rido-min]

yes, but not too much. I think it's ok for now

[heyitsaamir]

Adding a note: Should this exist here or be in the client layer?

[rido-min]

added a new optional param to set the type

In general, to fix log forging issues you ensure any user-controlled values going into logs are normalized so they cannot inject extra log entries or otherwise confuse log parsers. For plain-text logs this typically means removing or replacing newline (\r, \n) and other control characters from user input before logging.

For this codebase, the best focused change is to sanitize the correlation vector value returned by HttpRequestExtensions.GetCorrelationVector so that any consumer (including the logging in BotApplication.ProcessAsync) receives a cleaned value. We do this centrally in the extension method, rather than modifying all call sites. A minimal, non-breaking sanitization is to strip \r and \n characters (and optionally trim surrounding whitespace) from the header value; this preserves the content for correlation purposes while preventing log forging in plain-text outputs.

Concretely:

• In core/src/Microsoft.Teams.Bot.Core/HttpRequestExtensions.cs, change GetCorrelationVector from a single expression-bodied member to a block that:
  • Returns string.Empty if request is null.
  • Retrieves the first header value as before.
  • If it is null, returns string.Empty.
  • Otherwise removes \r and \n characters (using Replace) and optionally Trim()s the result.
• No changes are required in BotApplication.cs because it will automatically get the sanitized value when calling GetCorrelationVector.

No new external dependencies are needed; we only use string.Replace and Trim, which are part of System.String.

In general, to fix log-forging issues, any user-controlled value that is written to logs should be sanitized so that it cannot inject additional log entries or otherwise break log formatting. For plain text logs this usually means stripping CR/LF and related control characters; for HTML logs it means HTML-encoding before logging.

Here, the problematic value is the correlation vector obtained via HttpRequestExtensions.GetCorrelationVector(). The best fix with minimal behavior change is to sanitize this value at the point it is read from the headers, so that all usages (current and future) get a safe version. We can update GetCorrelationVector so that it strips carriage returns and newlines from the header value before returning it. This leaves the observable token value almost unchanged for legitimate clients (correlation vectors should not contain these characters anyway) while protecting the logging calls in BotApplication.

Concretely:

• In core/src/Microsoft.Teams.Bot.Core/HttpRequestExtensions.cs, change GetCorrelationVector from a single expression-bodied member that returns request.Headers["MS-CV"].FirstOrDefault() to a small method that:
  • Returns string.Empty if request is null.
  • Reads the header value into a local variable.
  • If null or empty, returns it as-is.
  • Otherwise removes \r and \n characters (and we can safely also strip \u2028 and \u2029 if desired, but at minimum CR/LF) via Replace.
• No changes are necessary in BotApplication.cs because after this change httpContext.Request.GetCorrelationVector() will already be sanitized when passed into _logger.LogInformation and _logger.BeginScope.

No new imports are required; string.Replace is in System, and we are already in C# with no additional dependencies.