I want to know if its possible and how to do the following , i have a basic MVC application (ASP.Net) that i have modified to work for me. Now the application already handles authentication perfectly fine but i need to use this authentication in another app.
Without creating a webservice is it possible for me to make calls to the applications authcontroller , if so how
You can't directly call a controller in another application because it is in a separate AppDomain. If you just want to reuse the existing code, you could refactor it into a separate assembly (library project), include that assembly in your new application, and just reference it from your logon controller. If you are trying to do single-sign on, then you may want to look at existing SSO solutions, such as JA-SIG CAS 2.0.
Authentication is a cross-cutting concern that shouldn't be embedded into a single use case/controller. AOP afficionados would say it should be encapsulated in an aspect.
Whoa guys slow down , im still beginning MVC and all its related details , the single sign on looks promising , the reason i dont want to go that route yet or even refactor the code and include it in the second project is because its way too simple a project.
Related
I am trying to build a new MVC Project. The thought is I will have a parent domain, and I will be hosting multiple sub products at different sub domains.
[ For Users it will be totally different products.. like: life.insurance.com and general.insurance.com].. and it is also possible that two different teams work on these two child products and they may have different Release Date.
Main thing is, I want to change my Web Project Layer. The Domain Layer, DAL Layer, etc will be common. I was searching for some best Industry Practices in MVC.
Thoughts that I have in Mind:
Create different MVC Areas in Web Project. But what if I want to send product A code to Production but not the Product 2 Code. [How to Resolve this]
Use different Web Projects and change the dll only at Production.
Please suggest. or any New way to handle this scenario?
Under Main Project solution, Create Separate MVC projects for each of the subdomains.
You can create multiple projects for DAL, DomainLayer, Crosscutting, DTOs, UI, Test etc. You can extend it as much as you need and you can find many sample architectures in different complexities. Considering your specific questions, you can route requests using Area as you pointed. In addition, you can implement Areas in different projects which enable you extend your solution without modifying the web project. However; you need to take into consideration that once you add DLL references to your web project, you cannot directly change specific DLLs without rebuilding the whole web project. In order to achive that, you need to resolve your plugin assemblies in runtime. So, you can use Assembly.Load that will help you load specific DLLs anytime you wish.
I have some code used to determine if a user is logged in and I want to put this on every page in an ASP.NET website so that only logged in users can view it. The problem is that the site is split into multiple projects/solutions so maintaining the single piece of code might be hard.
I was thinking I could create a class that inherits for System.Web.UI.Page and overrides Page_Init, but that would require changing all pages so they inherit from new new class. Also I don't think this will work across projects.
So then I thought approaching the problem from a different side: using AOP. I have never used Aspects before but it looks like I could use PostSharp to write an Aspect that injects code before every Page_Init (or maybe Page_Load?). This might work as a quick solution but I might run into problems if I need a page to not perform the authentication check (available to everyone).
Just to clarify, I already have a login solution; I am just looking for a checking that login on each page.
Look into HttpModules. The asp.net framework is already programmed so that a module runs on every page request, you just have to write it and add it to web.config.
http://msdn.microsoft.com/en-us/library/zec9k340(v=vs.71).aspx
EDIT: Here's a better link that demonstrates handling the BeginRequest event
http://msdn.microsoft.com/en-us/library/ms227673(v=vs.85).aspx
As #jrummell mentioned, there's MembershipProvider which is a great option, but if you're creating custom login solition, check this link which has a pretty simple login implementation step by step
Since you seem to have your login solution handled and working, creating a class that overrides the page_init sounds like your best option. This can work across other projects by simply creating that class in a separate project that you can included in your other solution(s)... To be honest, that's the easiest way to span the logic across multiple projects.. This will also be easily maintained because you'd only have to update one location going forward.
If you are using MasterPages, you wouldn't have to hit all of the pages, you could just include it on specific MasterPage(s) and set all the pages you want authentication to use that MasterPage.
Windows Identity Foundation can solve this for you. See http://msdn.microsoft.com/en-us/security/aa570351 for details on WIF. No need to reinvent the wheel. If you had only one Web application, Forms authentication would suffice.
I know there are actually a number of questions similar to this one, but I could not find one that exactly answers my question.
I am building a web application that will
obviously display data to the users :)
have a public API for authenticated users to use
later be ported to mobile devices
So, I am stuck on the design. I am going to use asp.net MVC for the website, however I am not sure how to structure my architecture after that.
Should I:
make the website RESTful and act as the API
in my initial review, the GET returns the full view rather than just the data, which to me seems like it kills the idea of the public API
also, should I really be performing business logic in my controller? To be able to scale, wouldn't it be better to have a separate business logic layer that is on another server, or would I just consider pushing my MVC site to another server and it will solve the same problem? I am trying to create a SOLID design, so it also seems better to abstract this to a separate service (which I could just call another class, but then I get back to the problem of scalability...)
make the website not be RESTful and create a RESTful WCF service that the website will use
make both the website and a WCF service that are restful, however this seems redundant
I am fairly new to REST, so the problem could possibly be a misunderstanding on my part. Hopefully, I am explaining this well, but if not, please let me know if you need anything clarified.
I would make a separate business logic layer and a (restful) WCF layer on top of that. This decouples your BLL from your client. You could even have different clients use the same API (not saying you should, or will, but it gives you the flexibility). Ideally your service layer should not return your domain entities, but Data Transfer Objects (which you could map with Automapper), though it depends on the scope and specs of your project.
Putting it on another server makes it a different tier, tier <> layer.
Plain and simple.... it would be easiest from a complexity standpoint to separate the website and your API. It's a bit cleaner IMO too.
However, here are some tips that you can do to make the process of handling both together a bit easier if you decide on going that route. (I'm currently doing this with a personal project I'm working on)
Keep your controller logic pretty bare. Judging on the fact that you want to make it SOLID you're probably already doing this.
Separate the model that is returned to the view from the actual model. I like to create models specific to views and have a way of transforming the model into this view specific model.
Make sure you version everything. You will probably want to allow and support old API requests coming in for quite some time.... especially on the phone.
Actually use REST to it's fullest and not just another name for HTTP. Most implementations miss the fact that in any type of response the state should be transferred with it (missing the ST). Allow self-discovery of actions both on the page and in the API responses. For instance, if you allow paging in a resource always specify in the api or the webpage. There's an entire wikipedia page on this. This immensely aids with the decoupling allowing you to sometimes automagically update clients with the latest version.
Now you're controller action will probably looking something like this pseudo-code
MyAction(param) {
// Do something with param
model = foo.baz(param)
// return result
if(isAPIRequest) {
return WhateverResult(model)
}
return View(model.AsViewSpecificModel())
}
One thing I've been toying with myself is making my own type of ActionResult that handles the return logic, so that it is not duplicated throughout the project.
I would use the REST service for your website, as it won't add any significant overhead (assuming they're on the same server) and will greatly simplify your codebase. Instead of having 2 APIs: one private (as a DLL reference) and one public, you can "eat your own dogfood". The only caution you'll need to exercise is making sure you don't bend the public API to suit your own needs, but instead having a separate private API if needed.
You can use RestSharp or EasyHttp for the REST calls inside the MVC site.
ServiceStack will probably make the API task easier, you can use your existing domain objects, and simply write a set of services that get/update/delete/create the objects without needing to write 2 actions for everything in MVC.
I have an interesting situation where I need to quickly provide a feature to a customer prior to our normal build schedule and outside of our normal build repository. I need it to go live tonight, without a recompile.
Our site is deployed with everything compiled into a DLL, besides the Views. This means that at anytime I can edit the Views on the fly in the middle of the day. Is there a way I can add a new page that can be invoked via HTTP GET or POST so that I can do some things I would normally do in a Controller without actually making a new Action, etc? I know this is not a good methodology and it won't be the long term solution, I just need a plan... business is business after all.
Edit: I also cannot edit the Global.asax routing table, it is also compiled.
The first thing you'd have to do is pull out your Routes into XML files so you could add routes on the fly (all it'd do is recycle the App-Pool). I also recommend pulling the Routes out of the web.config into their own .config file, that's referenced in the web.config.
The second thing is you would have to mix Webforms with ASP.NET MVC if you wanted to do this.
It's important to note that using UrlParameter.Optional is problematic with XML based routing, at least I never got it to work.
I believe because of the way routing works in MVC it will try to find a valid path using the Routing system first. Failing that it should look for the aspx page using the normal method of just looking for the file. Keep in mind that aspx files (or razor files) that are just asp.net pages should not be in the Views folder, as MVC apps are configured to refuse serving up files in that directory. I'm assuming your're just talking about a single page or two? Anything more complex than that and I would look at trying to separate them more strongly as in the article mentioned above.
You could mix classic webforms with MVC.
I'm almost positive you could add a new Controller class to the App_Code folder and it would get picked up without a compile needed.
I guess it all depends if you have a convention based route that will hit it or not.
I have two projects, the DLL project which has all my logic and data access stuff, and the ASP.NET project which does my forms etc.
I am a bit confused. I thought if I added the System.Web namespace reference to the DLL project I would be able to reference the Session state information of the ASP.NET page.
I could use each page to get the session info out and pass it to the DLL for the processing but would love to be able to process things directly from the DLL class(s).
Is this possible?
I have fiddled with the System.Web namespace and just seem able to get a reference to the Session variable.
Thanks all.
Jon
As long as the Assembly is loaded in the scope of the Session, it will have access.
Although this type of tight coupling isn't really recommended.
You should be able to use HttpContext.Current.Session
Edit
While yes I agree you should not tightly couple your Business Logic DAL or etc assemblies to ASP.Net session. There are plenty of valid cases for accessing HTTP Context outside of a web project.
Web Controls is probably one of the best examples, reusable HTTP modules, etc..
Now one option, if you want to have your DLL pull the stuff from Session, is to abstract out session. So you could define an interface like IStorage, that your library will know how to use. Then you can have a SessionStorage or MemoryStorage class and use IoC to inject the appropriate class into your library classes. This gives you the freedom to code it how you wanted it to be coded without tying your code to Session. Oh and one other benefit if done properly can be used to not tie your code to the session on the web either.
You can always use HttpContext.Current.Session in your DLL but this is considered as bad practice. A better approach would be to pass the values stored in the session dictionary to your DLL instead of it referencing the session. Another benefit you will gain is that the code in your DLL won't be coupled to the ASP.NET runtime meaning it will be easier to test.
As said by the others, you can always use HttpContext.Current.Session in your DLL, I assume it's your BAL, but you need to be really carefull. What if your DLL is later consumed by a windows service, or some other app that doesn't have an HTTPContext? Whenever I've done this it's always been in a property get method where I wrap the attempt to access HttpContext.Current.Session in a try catch block and if anything goes wrong I repull the needed data from the db.
Do not use HttpContext.Current.Session as your dll will not run always with the Web Application. It may run with any other application like Windows,Console itc.
It is better to use a Method which is actully accept a parameter, which will come form Session Value, if you are using ASP.Net Application, otherwise there will not be any dependency of the application. If your dll project already developed and you are trying to modify the exsiting business logic then no, dont modify your exsiting method, use an Overload method.