I have a MVC project that uses OwinConnectorFactory and ConnectorBuilder in startup.cs to create a connector, using the passed-in IAppBuilder. How do I access the connector after startup? Let's say, during authentication?
I've tried the http owin context but couldn't find connectors in request/response items. I didn't know where else to look.
TIA
One approach how to do it is via IoC, if you are using it in the project. Initialize you container right in the class marked by OwinStarutup attribute where all middle layers are wired up too.
Add these instances into the container and leave DI to inject them where ever required.
Related
I am trying to figure our where the code for configuring my dependency injection container for my domain repository services lives.
My initial thought was to let the client configure all services, but then the client needs to be aware of the repository service, which I don't want to expose in the client.
I was thinking that each layer could configure its own service dependencies via an exposed configuration method or class?
My initial thought was to let the client configure all services, but
then the client needs to be aware of the repository service, which I
don't want to expose in the client.
What I tend to do is still follow the Composition Root pattern, where my web project would be the first place where the IoC wiring-up would start (i.e. the usual sort of 3rd party library that would hook itself into the controller factory). But I then configure the rest of my IoC bindings by referencing an IoC module (in my case I usually use Ninject, so I reference a NinjectModule from my web project). But I put this NinjectModule in a separate infrastructure project.
I can then reference this IoC infrastructure project from my web project and the IoC project can reference every other project in the solution.
This way I don't have to create project references in my web project to things I might not want my web project to access, like my repository layer.
The answer has already been given in comments, I'm just wrapping it up in a proper answer here.
Unless you use a special-purpose architecture like a plug-in architecture, you should always configure the DI container at a single place, as near to the application entry point as possible. This is called the composition root.
It doesn't matter if the configured type is a repository, factory, domain service or application service. All DI configuration should go in one place.
See this blog post for a good introduction on the details of composition roots.
I am currently developing an ASP.Net MVC web application that requires username and password authentication. I started looking into using ASP.Net Identity for this however I have a very important requirement, the requirement is that the web application itself has no direct access to any databases, all DB Access is to be exposed to the application via an internal REST service. This is due to certain security polices we follow.
I realise that ASP.Net identity is capable of supporting external authentication methods but my question is split into 2 parts.
1) How would I configure ASP.Net Identity to use my custom REST service for authentication?
2) How would I go about developing a service that can be used by Identity for authentication ? (what would need to be returned from the service to ASP.Net Identity)
Any help on this would be most appreciated.
I just did what you are asking about. First, as FPar suggested, you need to implement an IUserStore and pass that to your UserManager. Your custom IUserStore will implement the interface, I used Resharper to generate stubs, but instead of using entity framework, you will use HttpClient to make calls to your REST service.
The REST service will have one action on a controller, I called my identityController, for each of the interface methods you actually need. I implemented the userstore, userloginstore and the rolestore, with code for about 10 calls I actually used. The identitycontroller then is what actually accesses the database.
I also retained the fully async pattern, using async REST calls and Database looks, both with and without entity framework. A shortened version of my data access code is in another question here, regarding IUserLoginStore::AddLoginAsync. In that class I actually used the original entityframework implementation of the user store for part of work, and eventually settled on plain (except for async) ado.net for the parts I couldn't make work that way. The tables are simple enough, using your ORM of choice would not take a lot of time.
Good luck!
You want to implement your own IUserStore and then pass a reference to the UserManager. Look into the Startup and the IdentityConfig files in the standarad ASP.NET MVC with individual user account authentication, to see, how to use them.
You can look here for an IUserStore implementation with entity framework. This is a template, you could start from and change it to your needs. However, you don't have to implement all interfaces, just implement the interfaces, you really need. The UserManager is able to handle that (it throws an exception, if you call a method, that requires an interface, that you don't implement.)
These are two excellent articles on this subject:
http://www.asp.net/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server
http://www.codeproject.com/Articles/762428/ASP-NET-MVC-and-Identity-Understanding-the-Basics
After getting an advice about using ServiceStack for my asp.net MVC website
(Maintaining state in Asp.Net MVC website), I started implementing it in my project - but some stuff is still unclear for me.
Currently I have two projects: one is the asp.net MVC project and the other is the BL project (a class library that holds all the business logic).
All controllers in the MVC project make calls to classes/functions in the BL project.
For now, the mvc project loads the BL's DLL, but in the future when the website will grow, the BL's project will run on separate machines.
I would like to use ServiceStack for session management/caching and authentication (which both of them usually depended on each other).
My questions:
1) Is it possible to use only these two features without the functionality of message based web service? ServiceStack need to be initialized, and it throws me an error when initialized twice (in both projects).
2) Is it possible to split the implementation of ServiceStack between the two projects? I would like to maintain the process of authentication in the BL project using the ServiceStack's authentication providers, but handle all the UI/cookies by myself (or with the help of ServiceStack) in the mvc project.
3) I would like to use ServiceStack's caching in the BL project, but I guess that I still need to maintain some session cookies to receive the session id. What is the right way to do it? Are there any built-in helper functions for this purpose?
Thanks in advance!
1) Is it possible to use only these two features without the functionality of message based web service? ServiceStack need to be initialized, and it throws me an error when initialized twice (in both projects).
If you install the latest ServiceStack.Mvc NuGet package you will get the base ServiceStackController which is an MVC Controller providing convenient access to ServiceStack's built-in providers. Although you still need to auto-wire your controllers with the dependencies it needs, e.g. an injected ICacheClient.
Although even if you're not using ServiceStack's WebFramework, having an AppHost is a convenient place to register your dependencies. ServiceStack is triggered by ASP.NET's IHttpHandler mappings specified in the Web.config, so if you don't have any mappings specified ServiceStack is never able to be called externally, but the registered dependencies are still able to be accessed internally with:
var cache = AppHost.Resolve<ICacheClient>(); //Get ICacheClient for SS IOC
2) Is it possible to split the implementation of ServiceStack between the two projects?
If you do have an AppHost, you cannot have more than one instance in a host project (by design) since an AppHost should be analogous to a host project where all your service dependencies should be registered and settings configured that apply to your entire web application or service.
You can however split the implementation of your services across multiple assemblies and have ServiceStack scan them all by specifying them in your AppHostBase constructor, e.g:
public class AppHost : AppHostBase
{
public AppHost() : base("My Service",
typeof(AServiceInDll1).Assembly, typeof(AServiceInDll2).Assembly/*, etc.*/){}
}
2) cont. I would like to maintain the process of authentication in the BL project using the ServiceStack's authentication providers, but handle all the UI/cookies by myself (or with the help of ServiceStack) in the mvc project.
Look at the ServiceStack.UseCases CustomAuthenticationMvc example project for an example of using MVC but authenticating with ServiceStack.
3) I would like to use ServiceStack's caching in the BL project, but I guess that I still need to maintain some session cookies to receive the session id. What is the right way to do it? Are there any built-in helper functions for this purpose?
You can use any of ServiceStack's Caching providers just like any other C# class, i.e. have your Business Logic binded to ICacheClient and inject the concrete implementation in your IOC.
For sessions you can use the base.SessionAs<T> method in the ServiceStack.Mvc ServiceStackController to access the session. To Save back the session you can use the IHttpRequest.SaveSession() extension methods. Although both these methods require the ASP.NET context (it uses ASP.NET's HttpContext singleton if not provided) to work since it relies on ServiceStack's ss-id/ss-pid cookies that are automatically instructed to be added on the client (by the server) whenever you access the Session.
If you don't want your business logic services to have a dependency on ASP.NET's System.Web I recommend accessing and saving the session to be done in your controllers and passed to your business logic.
I recommend reading the Sessions Wiki Page for more background info on how ServiceStack's sessions work.
Integration of ASP.NET Context between ServiceStack and ASP.NET or MVC
I'll add this info since it's useful for anyone doing advanced integration between ServiceStack and ASP.NET or MVC as some of ServiceStack's extension methods rely on these built-in types.
You can create a ServiceStack IHttpRequest or IHttpResponse (within any HTTP/Controller request) with:
var ssHttpRequest = System.Web.HttpContext.Current.Request.ToRequest();
var ssHttpResponse = System.Web.HttpContext.Current.Response.ToResponse();
Finally you can create a complete request context (that encapsulates both a IHttpRequest and IHttpResponse) with:
var ssRequestContext = System.Web.HttpContext.Current.ToRequestContext();
Not sure I fully grasp your questions and how you would like to split the projects across multiple servers. I'll try my best to answer your questions...
Is it possible to use only these two features without the functionality of message based web service? ServiceStack need to be initialized, and it throws me an error when initialized twice
It seems like you're trying to run 2 instances of ServiceStack (maybe even 2 websites) within one solution (one in your web project and once in your BL layer). I don't think that's possible. Your BL layer can share ServiceStack libraries and you can configure (within AppHost.Configure method) those in your web project that references your BL project.
Is it possible to split the implementation of ServiceStack between the two projects?
I think the answer is yes, but you would have have one instance of ServiceStack used by both the projects. This would share the Session state across the projects. There might be a way to have two projects with there own instances of ServiceStack...see https://github.com/ServiceStack/ServiceStack/wiki/Self-hosting.
I would like to use ServiceStack's caching in the BL project, but I guess that I still need to maintain some session cookies to receive the session id.
If ServiceStack is being used across both projects you can access all session data in UserSession (https://github.com/ServiceStack/ServiceStack/wiki/Sessions). If you MVC Controllers inherit from ServiceStackController you can use SessionFeature.GetSessionId() to get the session Id. In your ServiceStack Service (classes that implement Service) you can get the session data from using base.Session.
Hope this helps.
My ASP.NET MVC 2 controllers are currently instantiating service objects in their constructors by passing repository instances that are instantiated by Castle Windsor. I have unit tests that call the controller actions after passing Moq instances of the repositories to the controller's constructor.
I want to allow a third-party UI to access these service objects through WCF.
It occurred to me that converting my existing Service layer into Web services or even adding a new Web service layer between the UI and the existing Service layer will break my unit tests unless I find a way to bridge that gap.
I was trying to work out a solution where my UI was coded against an interface of the service layer (it already is) and I could use DI to pass the Web service implementation at run-time and pass the existing implementation during unit testing. The Web service implentation would simply call the existing implementation.
Questions:
Is such an approach advisable / possible?
Are there any examples of this in a tutorial or open source project?
EDIT:
I believe I have a workable solution now thanks to the suggestions below. I created a WCF Service Application that uses the existing service interfaces from my domain model. The WCF implementation is a class where the constructor takes repository instances from Ninject's WCF extension and creates an instance of the service from the domain model. Each method/function in WCF simply calls the same method/function from the existing service layer.
There were some caveats. For example, I can no longer pass a reference to my ASP.NET MVC ModelState when I create the service in the controller (actually, I use Ninject to create an instance of the WCF service and supply that to the controller's constructor). The reason is that WCF is a messaging platform - changes must be explicitly communicated back with each call (i.e. my validation errors are now communicated back as reference parameters on individual functions/methods).
I also had to add some serialization/servicemodel references to my formerly POCO Core project.
Also, I switched from Castle to Ninject because Castle's WCF solution has a maturity level of low and I wasn't comfortable using that at this time.
Can you explain in more detail why your tests would break?
I do this type of development all the time. Services as classes => services as WCF services.
Your tests shouldn't break. A WCF Service is almost 100% contract, the underlying business code and logic shouldn't have to change.
Check out the Web Services Software Factory created by the Patterns & Practices team. It is a good way to structure your services into contract projects (data, message, service) and "business code". Once you get a better understanding of how to structure your code, you can refactor their style to something that fits you a little better. Their example tends to separate everything into lots of VS projects, which can be a little overkill for most shops. Example, I don't see many shops sharing data contracts across projects. Yes, in a perfect world, you should probably share a lot os types (like address) across projects, but I don't see it done very often. So, I tend put all my contract stuff in one VS project.
If your services are already defined as interfaces then you've got a head start.
Pass the services into the controllers as constructor dependencies, rather than the repositories. Let your DI container A) provide the repositories to the services, and B) provide the services to the controllers.
If you want to stand up your service layer as wcf services to be accessed by other applications, you'll want to use the wcf service factory to pull the concrete service implementations out of your DI container. Here's an example with windsor, it should be easy to adapt to whatever container you use.
At this point you can modify your website to either A) continue to invoke the services directly, or B) have them call back to the web services using service clients. There are pros and cons to both methods.
I have a prototype ASP.NET-MVC website which uses Ninject as a IoC container. All service-classes and repository-classes used by MVC Controllers are properly injected by Ninject. This is great.
The next thing I need to add there is Silverlight (version 3 to be more precise).
Silverlight will be connecting to my server using WCF service, hosted in ASP compatibility mode, to the same ASP.NET-MVC website.
What Silverlight needs is to 'download'/'get' a kind of ViewModel using WCF (the better name would be Client-Side Model). This is also possible - I imported WCF service and setup all security-related xml configuration files.
Here is the stuff I want to know....
Is that OK that model returned by WCF service is rather complex and includes arrays and inheritance (at array items' level)... or maybe there is another and better way to send it from server to client?
At Server-Side for regular asp-mvc stuff all service-classes used by controllers are injected by Ninject. How to inject services for WCF-service classes?
Do WCF service has an access to HttpContext.Current.Items? I need to grab from here logged User Id and a few profile-related data (regular forms auth. stuff).
EDIT
Ad 3. It's possible enabling AspNetCompatibilityRequirements
Has anybody ideas for point 2?
For the 1st Question.
Yes it is okay to return a complex structure, provided you have explicitly applied the '[DataMember]' attribute to each and every needed property of the Object/s.