[
https://issues.apache.org/jira/browse/LOG4NET-565?focusedWorklogId=669594&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-669594
]
ASF GitHub Bot logged work on LOG4NET-565:
------------------------------------------
Author: ASF GitHub Bot
Created on: 25/Oct/21 15:03
Start Date: 25/Oct/21 15:03
Worklog Time Spent: 10m
Work Description: tschettler commented on pull request #73:
URL: https://github.com/apache/logging-log4net/pull/73#issuecomment-951019204
Thank you for the feedback @fluffynuts!
I understand your security concerns and completely agree with you. My
initial commit was just to provide a standard way to create instances, without
regard to whether they _needed_ to be created using a custom activator. I think
the changes could be pared down based on your feedback and additional changes
could be made to circumvent the security concerns you have outlined. Here are
the following two areas that I think would cover most use cases:
1. **A DI-enabled Appender.**
One scenario here would be when someone would like to use a managed ORM to
log to a database. An existing DI container manages the scope and creation of
these dependencies, possibly because all data access for an application needs
to be configured and managed in a specific manner. Enabling this would just
require the change within `XmlHierarchyConfigurator`.
2. **A DI-enabled Pattern Converter.**
Consider wanting to use a pattern converter to log items from the
HttpContext in ASP.NET Core. A standard method to retrieve HttpContext
information is to inject `IHttpContextAccessor`. `ConverterInfo` only provides
the converter type and there's no way to intercept the creation of the pattern
converter to provide this dependency. Enabling this would just require the
change within `PatternParser`.
Along with limiting the scope of changes to just be for these two classes,
the `IActivator` implementation type could be registered with the log4net
config and `ActivatorProvider` could perform a validation check against this
type to ensure it matches. Once the instance is set, it could also protect the
instance from being changed to something else.
If you would allow me, I can build out the changes as specified. With
consideration to reducing the changes to account for just these scenarios,
implementing some additional logic for validating the activator instance type,
and locking down from further changes, what remaining security concerns would
you have?
Thanks!
Travis
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 669594)
Time Spent: 0.5h (was: 20m)
> Dependency Injection support appender and logger types
> ------------------------------------------------------
>
> Key: LOG4NET-565
> URL: https://issues.apache.org/jira/browse/LOG4NET-565
> Project: Log4net
> Issue Type: Improvement
> Components: Appenders, Core
> Reporter: Hitesh Chauhan
> Priority: Major
> Labels: Enhancement
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I have seen demand for dependency injection support in log4net. I have added
> that behavior to my local repository. And I would like to push that to
> log4net library.
> e.g. appender configuration
> <appender
> name="ServiceAppender"
> type="LoggingServiceAppender"
> serviceLocatorType="Log4NetServiceLocator">
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
