This project has moved and is read-only. For the latest updates, please go here.

Katana / ASP.NET Identity - Bad architectural design

Apr 27, 2015 at 11:01 AM
Edited Apr 27, 2015 at 1:37 PM
I've never seen before such awkward and cumbersome attempt to implement authentication/authorization:

Manually editing config files, manually creating user manager classes, manually creating and retrieving OWIN context services, IAppBuilder::CreatePerOwinContext<>() looks generic but is still only valid for dedicated constructors due to its parameters ...

Gee, what a mess!

I feel like in a first draft concept demo. ... Will there be some "jQuery on Katana" in the near future to get ASP.NET Identity feasible to use?

And who came up with the idea to add system infrastructure items to a config file's <appSettings> section? OWIN is NOT a programmer's application, it's platform infrastructure! Neither OWIN nor MVC should be allowed to add anything to a config file's <appSettings> section. They are supposed to create their own configuration sections.

Who's the architect responsible for this cumbersome and awkward design? Is there anyone at all?
Apr 27, 2015 at 5:59 PM
Apr 27, 2015 at 7:56 PM
Edited Apr 27, 2015 at 7:57 PM
Thanks for replying.

Yery interesting! Yeah, that looks much better. But, still, why is initialization split into service configuration and application configuration?

If I were supposed to add, e.g., Google authentication I would want to enable and configure it at the same place, then I can easily delete it again whenever I don't want to support it anymore. So, what's the benefit in splitting it?

Just one more thing I'd like to mention here although it's off-topic, but it's in the sample you've pointed me to: EF7 requires the programmer to hard code the storage environment. This way it's impossible to switch storage environments by just changing configuration.
Apr 28, 2015 at 10:51 AM
What about configuring OWIN then?

Will it still be configured in the appSettings section of web.config/app.config? I wouldn't need OWIN if I targeted a second, a console front-end for instance, for my application.

I woudn't suggest administrators to bother with system settings in the application settings section.

So I strongly suggest to move the OWIN configuration from the <appSettings> section to a separate configuration section in web.config/app.config, fore no one will be able to tell what's required for an application to run and what isn't.