Programmatic configuration?

[alexdresko]

One of my projects is too dynamic to configure everything in the web.config. Is there no way to configure NWebsec programmatically?

[alexdresko]

To clarify, I know that some configuration can be done at OWIN startup, but I have configuration that needs to change outside of that event.

[RehanSaeed]

If you are using MVC, use the NWebsec.Mvc NuGet package. It contains a bunch of filters, which you can add to the global MVC filters collection or to individual controllers or actions. Find out more here.

[klings]

Yes, the MVC attributes might be helpful. Other than that, it's not currently possible to change/supply configuration programmatically.

NWebsec has been moving in a direction where this would be easier to support in the future. If you have a scenario where this would be helpful I'd appreciate some more details. I might add the possibility in a future release, if there are good reasons.

[alexdresko]

From what I can tell, your core redirect validation logic happens in RedirectValidator. However, the AllowedUris are stored in RedirectValidationConfiguration, RedirectValidationConfigurationElement, and RedirectValidationOptions. Effectively, the OWIN, attribute, and config-based data stores are all separate, maintaining their own list of AllowedUris.

What if AllowedUris (and all of NWebSec's configuration for that matter) were stored in some static context that could be accessed from anywhere, and shared from everywhere? That would, for example, allow initial configuration from OWIN, but later allow something like:

NWebSec.Context.Current.RedirectValidationOptions.AllowedUrls.Add("http://someurl");

If you want to talk about how you're thinking about proceeding, I can whip something up in my fork..

[klings]

Yes, the web.config and OWIN config are two separate config stores (there's no MVC attribute).

I'll probably have to do some more restructuring of NWebsec to support ASP.NET vnext (dnx), and I think it would be a good idea if I kept this issue in mind while doing that. I'm pretty sure it is simpler to first do the work related to vnext, and then consider dynamic config (not the other way around).

I have to admit that I'm not completely sold on the idea yet, as it would increase the complexity of NWebsec. I still need a good reason to add it. Perhaps you could explain your scenario in some more detail? If you're not comfortable sharing it here, perhaps you could give me a ping at nwebsec at nwebsec dot com

[alexdresko]

Where do you anticipate the complexity exists?

I'm sure that centralized, configurable configuration will add a little complexity, but I don't think it's actually complicated. In my opinion, it's better to have complexity than the redundancy you have currently. Having two config stores is also confusing to a developer who is trying to use NWebSec for the first time. First question I asked myself is, "Why?". Also, I'm not the first to ask: http://nwebsec.codeplex.com/discussions/543272 :)

And if you use a static configuration context, it won't have any impact on ASP.NET 5. That much works the same.

In my situation, we have a database table of approved URLs... basically a key/value pair. We need to load this into ApprovedUris at startup... But since that list can change at runtime, we need to be able to modify ApprovedUris.

Hope that helps. I'm happy to keep discussing this with you until an agreement is made. Better to make sure we're all on the same page before any code is written. :)

[alexdresko]

Happy Monday, everyone! I just popped back in here, and it still doesn't appear to be possible to configure the redirect validation URLs at run-time.

Is that something I can help with?

[klings]

NWebsec currently validates all config at startup, which is straightforward. Error handling is also straight forward, simply throw an exception. Dynamic configuration means that NWebsec also needs dynamic error handling, and needs to take care to not introduce synchronization issues when the configuration changes. That would introduce quite a bit of new complexity.

I do understand that you have a scenario where this functionality would be convenient, but I'm not sold on the idea, and I'm not sure that this is something I'd want to maintain.

Right now I'm wrapping up a new release, and when that's done I'll get started on ASP.NET 5 support. After that, there are a few more features on the horizon too. I'll have to prioritize those over this. We can leave this issue hanging if you want, and I'll have another look at it when the calendar clears up.

[alexdresko]

Thanks for taking time to respond, @klings. I especially appreciate you being patient with me while discussing a potential solution.

I like simplicity as much as the next developer, and I also appreciate your tendency to maintain that simplicity.

As you ponder if/how to complete this request, here are a few more things I've been thinking about:

• Every change to any part of NWebsec's configuration requires a restart of the server for those changes to take effect. Many of the most important configuration options in NWebsec are of the type that necessitate repeated, frequent changes, especially at first when you're trying to get everything configured correctly (CSP is probably the biggest culprit, but redirect validation isn't far behind).
• In my mind, it is not necessary for you to maintain any sort of component that requires careful consideration of synchronization issues. I imagine NWebSec supporting a modular "data store"/provider model where in different implementations can be injected at startup. If someone wants to use the web.config for their data store, inject a web config data store into NWebsec's configuration. The OWIN configuration might be changed to simply construct some sort of object data store behind the scenes. In both of those cases, you wouldn't have to worry about synchronization issues. However, if I want to inject a database-based data store, and if I want to take on the onus of dealing with synchronization issues, that's for me to deal with. In any case, NWebsec would simply rely on the data stores to return an object model to work with.
• Validation would merely have to be moved from "load time" to "access time" validation. Any time NWebsec needs to access configuration, it requests it from the data store and validates it there. I understand that requires an extra resource load performing validation on every access, so I'm interested to know what you think about that.
• When a validation error occurs, you still just throw an exception as you currently do.

I hope that makes sense.

It just occurred to me that your proposed/potential solution likely involves building some sort of thread-safe, observable object/collection to handle validation as the object model is modified... and yeah, that does seem complicated. Though I'm sure there's a good example of a thread-safe observable object/collection somewhere out there on the internet to handle the bulk of that workload.

No rush to respond.. Just wanted to continue to put my thoughts into writing... I enjoy design talks like this and I assure you I'm not trying to argue.

[alexdresko]

Does that mean you implemented this feature?