> > The only way I could see for the keepers of log4net to solve > this problem would be to go back and try to re-fetch > credentials at the point you log events to adoappenders in > your code ... or any point after application startup. Might > be possible, dunno. Prolly very expensive in performance, > though, if it's even possible. I'd hafta think about it.
The AdoNetAppender does have a ReconnectOnError property which will force the appender to try to reconnect if the connection is not open. The AdoNetAppender holds open a single connection to the database (it does not take advantage of the builtin connection pooling, that's a separate discussion). The appender tries to open the connection during configuration, typically this is done with the process credentials and not with the credentials of any of the site users. Setting ReconnectOnError to true (<ReconnectOnError value="true" />) will force the appender to attempt to reconnect for each logging event that arrives at the appender until the connection is established. Therefore this mode could be used to allow the AdoNetAppender to wait until a user with permission to connect to the database uses the site (and is impersonated), then that user's credentials would be used to open the persistent connection. Note that this is a 'bad idea' as it relies on a user logging in and also all further database access by the appender is does in the name of that user (according to the database). The right way to do isn't always possible due to system constraints, but this is the way that I try to do it (assumes IIS6). Create a new user account for the application to run under, do this on the domain so that it is known on the web server and DB server (or create matching local accounts with the same passwords). Create an AppPool in IIS6 for the web app to run using. Set the AppPool to run using the new user account created for the application. Setup the DB to allow access by the user account and restrict access to only the required database and only inserts into the right tables (or even better just a single stored procedure). Then the application will have, through its process credentials, permission to connect to the database and to write to the log table. Cheers, Nicko
