I have my configuration in web.config and it works fine.
<configuration>
<system.identityModel.services>
<federationConfiguration>
....
</federationConfiguration>
</system.identityModel.services>
</configuration>
How do I move this out of web.config to a custom config file and load it from code?
I want to use the same structure of this configuration so that I do not have to change anything in code if I have to change this configuration file.
You can tap into the WIF event from your global.asax
void Application_Start(object sender, EventArgs e)
{
// Code that runs on application startup
FederatedAuthentication.FederationConfigurationCreated += FederatedAuthenticationOnFederationConfigurationCreated;
}
In that handler you can adapt the configuration at runtime. Here is some code to give you an idea. The end code will be more complex.
private void FederatedAuthenticationOnFederationConfigurationCreated(object sender, FederationConfigurationCreatedEventArgs args)
{
var identityConfiguration = new IdentityConfiguration(loadConfig:false);
identityConfiguration.SecurityTokenHandlers.Clear();
//...
identityConfiguration.SecurityTokenHandlers.Add(new Saml2SecurityTokenHandler());
//...
var configuration = new FederationConfiguration(loadConfig: false)
{
CookieHandler = new ChunkedCookieHandler(),
//...
IdentityConfiguration = identityConfiguration
};
args.FederationConfiguration = configuration;
}
If you have any doubts on what value to give to which object, you can always temporarily switch back to the configuration and inspect the runtime values through the same event. Don't underestimated the complexity and richness of the configuration delivered by WIF out of the box.
In general, you migth want a mixture of "code config" and "web.config config" were the web.config is still used to configure certain more variable parts of the config and the code is used for the more unchangable pieces...
Related
This is my default Serilog configuration
SeriLogLevelSwitch.MinimumLevel = LogEventLevel.Information;
Log.Logger = new LoggerConfiguration()
.MinimumLevel.ControlledBy(SeriLogLevelSwitch)
.MinimumLevel.Override("Microsoft", LogEventLevel.Warning)
.MinimumLevel.Override("Microsoft.Hosting.Lifetime", LogEventLevel.Information)
.Enrich.FromLogContext()
....
How can i change the loglevel to Debug for a specific namespace at runtime when the default is Information?
Each of your MinimumLevel.Override can have its own LoggingLevelSwitch, which allows you to control the log level for each particular override at run-time.
Create individual LoggingLevelSwitch for each override that you intend to modify whilst the app is running, and store these instances in a place that you can access from other parts of your application, which will allow you to change the MinimumLevel of these LoggingLevelSwitch(es).
e.g.
public class LoggingLevelSwitches
{
// Logging level switch that will be used for the "Microsoft" namespace
public static readonly LoggingLevelSwitch MicrosoftLevelSwitch
= new LoggingLevelSwitch(LogEventLevel.Warning);
// Logging level switch that will be used for the "Microsoft.Hosting.Lifetime" namespace
public static readonly LoggingLevelSwitch MicrosoftHostingLifetimeLevelSwitch
= new LoggingLevelSwitch(LogEventLevel.Information);
}
Configure your Serilog logging pipeline to use these LoggingLevelSwitch instances:
static void Main(string[] args)
{
Log.Logger = new LoggerConfiguration()
.MinimumLevel.Override("Microsoft", LoggingLevelSwitches.MicrosoftLevelSwitch)
.MinimumLevel.Override("Microsoft.Hosting.Lifetime",
LoggingLevelSwitches.MicrosoftHostingLifetimeLevelSwitch)
.Enrich.FromLogContext()
.CreateLogger();
// ...
}
Then somewhere in your application, for example, in the code that handles your application configuration that can be changed at run-time, update the LoggingLevelSwitch instance(s) to the new LogEventLevel that you want:
public class AppSettings
{
void ChangeLoggingEventLevel()
{
LoggingLevelSwitches.MicrosoftHostingLifetimeLevelSwitch
.MinimumLevel = LogEventLevel.Error;
LoggingLevelSwitches.MicrosoftHostingLifetimeLevelSwitch
.MinimumLevel = LogEventLevel.Warning;
// ...
}
}
As you can see, the LogEventLevel is controlled by the LoggingLevelSwitch instances, so it's up to you to decide where in your application (and how) these instances will be modified, to affect the logging pipeline.
The example above I'm assuming you have a screen (or API) in your application that a user would be able to configure the logging levels.
If you don't have that, then another approach is to have a background thread that periodically checks a configuration file, an environment variable, or query a database, etc. to determine what these logging levels should be.
If you're using a .NET Core Host, you can use the Options pattern which can handle the refresh of the configuration for you, and allow you to execute code when the configuration changes (where you'd change the MinimumLevel of your LoggingLevelSwitch(es) you have.
You can use an environment variable paired with another MinimumLevel.Override to change the loglevel to Debug for a specific namespace at runtime like so:
using System;
...
SeriLogLevelSwitch.MinimumLevel = LogEventLevel.Information;
Log.Logger = new LoggerConfiguration()
.MinimumLevel.ControlledBy(SeriLogLevelSwitch)
.MinimumLevel.Override("Microsoft", LogEventLevel.Warning)
.MinimumLevel.Override("Microsoft.Hosting.Lifetime", LogEventLevel.Information)
.MinimumLevel.Override(Environment.GetEnvironmentVariable("SPECIFIC_NAMESPACE"), LogEventLevel.Debug)
.Enrich.FromLogContext()
....
Then, ensure the environment variable SPECIFIC_NAMESPACE is accessible by your application at runtime. Note that "namespace" is synonymous with "source context prefix"
Environment.GetEnvironmentVariable
One of my TopShelf-hosted Windows services is creating duplicate log files that look like this:
myapp.20140729.log
myapp.20140729.log.20140729.log
A similar problem has been described on StackOverflow before - the solutions in 10639682 didn't work for me, but 579688 suggests it could be caused by initialising the logging system twice.
I'm using the TopShelf Log4Net plugin, but I'm also doing my own log4net logging and need access to the ILog instance before the service has actually started, so my code looks like this:
public static void Main(string[] args) {
XmlConfigurator.Configure();
var log = LogManager.GetLogger(typeof(MyService));
var container = new Container();
RegisterComponents(container, log);
log.InfoFormat("Starting MyService");
RunService(container);
}
public static void RunService(Container container) {
HostFactory.Run(x => {
x.Service<PortalAdaptor>(s => {
s.ConstructUsing(name => container.Resolve<MyService>());
s.WhenStarted(f => f.Start());
s.WhenStopped(f => f.Stop());
});
x.RunAsLocalService();
x.SetDescription("My Service");
x.SetDisplayName("My Service");
x.SetServiceName("MyService");
x.UseLog4Net();
});
}
I've done a little digging, and it appears that calling x.UseLog4Net() in my RunService method is actually running XmlConfigurator.Configure() again - see Log4NetLogWriterFactory, line 62 in the TopShelf code.
So...
Am I correct in thinking that calling XmlConfigurator.Configure() twice could be the cause of my duplicate log file issues?
If so - how can I either inject an existing config into TopShelf, OR get the TopShelf initialization to run before I start my service so I can start logging before the service starts?
Call Hostfactory.New instead of HostFactory.Run to get a reference to the host, do your logging, then call the Run() method on the host:
var host = HostFactory.New(configureService);
var log = LogManager.GetLogger(typeof(MyService));
log.InfoFormat("Starting MyService");
host.Run();
An alternative approache would be that once you have done your initial logging, call LogManager.ResetConfiguration to clear the configuration and allow TopShelf to reload it:
Resets all values contained in the repository instance to their
defaults. This removes all appenders from all loggers, sets the level
of all non-root loggers to null, sets their additivity flag to true
and sets the level of the root logger to Debug. Moreover, message
disabling is set to its default "off" value.
I've been using ImageResizer.net just fine in our web app, but now I need it to resize and serve images that don't (and cannot) have a file extension, like this one:
http://localhost:58306/ClientImages/Batch/2012/12/10/f45198b7c452466684a4079de8d5f85f?width=600
In this situation, I know that my files are always TIFF's, but they wont have a file extension.
What are my options?
/resizer.debug.ashx: https://gist.github.com/raw/9c867823c983f0e5be10/4db31cb21af8b9b36f0aa4e765f6f459ba4b309f/gistfile1.txt
Update
I followed Computer Linguist's instructions:
protected void Application_Start()
{
Config.Current.Pipeline.PostAuthorizeRequestStart +=
delegate
{
var path = Config.Current.Pipeline.PreRewritePath;
var clientImgsRelPath = PathUtils.ResolveAppRelative("~/ClientImages/");
var isClientImageRequest = path.StartsWith(clientImgsRelPath, StringComparison.OrdinalIgnoreCase);
if (isClientImageRequest)
Config.Current.Pipeline.SkipFileTypeCheck = true;
};
// other app start code here
}
http://localhost:58306/ClientImages/Batch/2012/12/10/92d67b45584144beb5f791aaaf760252?width=600 just responds with the original image with no resizing.
This was also asked about here: http://imageresizing.net/docs/howto/cache-non-images#comment-571615564
This is happening during development with the Cassini or Visual Studio web server or whatever you want to call it.
First, you MUST be using IIS7 Integrated mode. Classic mode will not work; it does not permit ASP.NET access to extensionless requests
ImageResizer can't know that extension-less URLs are images unless you explicitly tell it.
This doc explains:
http://imageresizing.net/docs/howto/cache-non-images
Essentially, you'll end up performing logic (usually String.StartsWith) on your URLs to find out if ImageResizer should treat the file as an image.
Config.Current.Pipeline.PostAuthorizeRequestStart += delegate(IHttpModule sender, HttpContext context) {
string path = Config.Current.Pipeline.PreRewritePath;
//Skip the file extension check for everything in this folder:
if (path.StartsWith(PathUtils.ResolveAppRelative("~/folder/of/images"),
StringComparison.OrdinalIgnoreCase)){
Config.Current.Pipeline.SkipFileTypeCheck = true;
}
};
You should register this event handler in Application_Start in global.asax.
I got Unity interception working using a HadlerAttribute and an instance of ICallHandler. To get it working all I have to do is decorate the class with the [Trace] attribute, and the interceptor works great.
[Trace]
public interface IPersonService
{
string GetPerson();
}
However I would like to have interception working for all my methods in a couple of assemblies. So I am using Unity AutoRegistration to set up my container as follows:
private static IUnityContainer BuildUnityContainer()
{
var container = new UnityContainer();
//container.AddNewExtension<UnityInterfaceInterceptionRegisterer>();
container.
ConfigureAutoRegistration().
ExcludeSystemAssemblies().
LoadAssemblyFrom(typeof(PersonService).Assembly.Location).
Include(If.ImplementsITypeName, Then.Register()).
ApplyAutoRegistration();
return container;
}
Works great, except when I attempt to setup global registration as per this post:
http://unity.codeplex.com/discussions/281022
I have a UnityContainerExtension configured as follows, where MVC4Unity is my DLL:
public class UnityInterfaceInterceptionRegisterer : UnityContainerExtension
{
protected override void Initialize()
{
base.Container.AddNewExtension<Interception>();
base.Container.Configure<Interception>().
AddPolicy("LoggingPolicy").
AddMatchingRule<AssemblyMatchingRule>
(new InjectionConstructor("MVC4Unity")).
AddCallHandler(new TraceCallHandler());
base.Context.Registering += new EventHandler<RegisterEventArgs>(this.OnRegister);
}
private void OnRegister(object sender, RegisterEventArgs e)
{
IUnityContainer container = sender as IUnityContainer;
if (e != null && e.TypeFrom != null && e.TypeFrom.IsInterface)
{
container.Configure<Interception>()
.SetInterceptorFor(e.TypeFrom, e.Name, new InterfaceInterceptor());
}
}
}
Unfortunately it is always throwing a StackOverflowException (!) when it goes into the OnRegister method.
The question then is, has anyone implemented assembly or even namespace wide interception using Unity, and was this the way to go?
[EDIT]
It seems that no matter what I add in the AddMatchingRule line below, that the OnRegister handler is invoked for all included assemblies as well! ( for example even the Microsoft.* namespace assemblies!)
base.Container.AddNewExtension<Interception>();
base.Container.Configure<Interception>().
AddPolicy("LoggingPolicy").
// see what other types of matchings rules there are!
AddMatchingRule<NamespaceMatchingRule>
(new InjectionConstructor("MVC4Unity.*")).
AddCallHandler(new TraceCallHandler());
base.Context.Registering += new EventHandler<RegisterEventArgs>(this.OnRegister);
I'm late with my answer, but maybe someone will find this useful.
If I understood the problem correctly you need to apply one matching rule to multiple assemblies. For these kind of tasks you can use AssemblyMatchingRule (MSDN).
container.Configure<Interception>()
.AddPolicy("logging")
.AddMatchingRule<AssemblyMatchingRule>(
new InjectionConstructor(
new InjectionParameter("YourAssemblyName")))
.AddCallHandler<LoggingCallHandler>(
new ContainerControlledLifetimeManager(),
new InjectionConstructor(), new InjectionProperty("Order", 1));
In your last code snippet i think you need to remove dot asterisk in the end of namespace in order to add MVC4Unity namespace to your NamespaceMatchingRule.
For additional information please check this link - Policy Injection MSDN
What is the preferred way to remove a default pipeline contributor (OpenRasta 2.0.3)?
I haven't found a lot on that on the net, but one way seems to be writing a custom DependencyRegistrar, i.e. deriving from DefaultDependencyRegistrar and then e.g. overriding AddDefaultContributors(). Apart from that I doubt that it's the best way to remove just a single pipeline contributor, it seems to need additional per-host (ASP vs. InMemory) work, whereas I would consider messing with pipeline handlers to be a host-agnostic affair.
But even if I'd go this route, this guy here seems to have tried it without success: http://groups.google.com/group/openrasta/browse_thread/thread/d72b91e5994f402b
I tried similar things, but so far couldn't make my custom registrar replace the default.
So what's the simplest and best way to remove a default pipeline contributor, preferable in a host agnostic way? Is there a working example somewhere?
No, you just need to derive from the registrar and use the protected members that are available to imperatively remove the types you don't want auto-registered.
The registrar needs to be registered in your container before you provide it to OpenRasta, otherwise the type has been resolved already.
Answering myself with working code snippets as they might be helpful to others.
So it looks like removing default pipeline contributors cannot be done
in a host agnostic way (although I don't see why OpenRasta could not
be modified to allow for easy deletion of handlers in the future).
The 2 classes that need to be written are in fact independent of the
host(s) used:
public class MyDependencyRegistrar : DefaultDependencyRegistrar
{
protected override void AddDefaultContributors()
{
base.AddDefaultContributors();
PipelineContributorTypes.Remove(typeof(HandlerResolverContributor));
// If we remove the only contributor for the 'well-known'
// IHandlerSelection stage, like done above, we need to add
// another one implements IHandlerSelection, otherwise
// we'll run into errors (and what's the point of a pipeline
// without a handler selector anyway?). So let's do that here:
AddPipelineContributor<MyOwnHandlerResolverContributor>();
}
}
In order to make that Registrar available, we need to create an accessor
like the following, which then needs to be set in the various hosts:
public class MyDependencyResolverAccessor : IDependencyResolverAccessor
{
InternalDependencyResolver resolver;
public IDependencyResolver Resolver
{
get
{
if (resolver == null)
{
resolver = new InternalDependencyResolver();
resolver.AddDependency<IDependencyRegistrar, MyDependencyRegistrar>();
}
return resolver;
}
}
}
For Asp.Net, this seems to work for me:
public class Global : System.Web.HttpApplication
{
void Application_Start(object sender, EventArgs e)
{
OpenRastaModule.Host.DependencyResolverAccessor =
new MyDependencyResolverAccessor();
For InMemoryHost, which I use for integration testing and in-process access
of my handlers, I haven't found a way around copying the whole class
InMemoryHost and modifying it to my needs. In fact, we don't need
MyDependencyResolverAccessor in this case, as InMemoryHost implements
IDependencyResolverAccessor already. So here's how it could look like. Only the
last line was actually added to the existing code in InMemoryHost:
public class TwinMemoryHost : IHost, IDependencyResolverAccessor, IDisposable
{
readonly IConfigurationSource _configuration;
bool _isDisposed;
public TwinMemoryHost(IConfigurationSource configuration)
{
_configuration = configuration;
Resolver = new InternalDependencyResolver();
Resolver.AddDependency<IDependencyRegistrar, MyDependencyRegistrar>();
...