Thanks Dan for the reply. Without taking up too much of your time, could you explain the organization of your projects, what type of projects they are (Web, MVC, etc), where and how exactly you are capturing the login info, and how are you passing those credentials around the various projects, to ensure all controller actions are not exposed to public use? I undertand the attributes you're using for ensureing authentication prior to use, but more interested how this all works when split out across all the projects that I see people are doing.

My solution is a typical n-tier business app built on Extjs, Asp.net MVC, NHibernate/RhinoCommons/Castle Windsor stack.

I've got a Commons project with bits and bobs I use across all my projects, Core with my domain entities and business logic, Data.Nhibernate contains some Repository<T> extensions and things event listeners for Auditing and Soft-Deletes, Unit Tests, then the web bit... I have split my controllers out into a separate class library, so my Web project contains nothing but HTML, CSS, JS and images. I use the WindsorControllerFactory from MVCContrib for this, I really recommend doing it as it can be a pain in the arse scrolling up and down all the time looking for your controllers.

So in my case a User is an Entity defined in the Core/Domain project containing the logic for validating passwords, etc. In your case it could be something retrieved from a 3rd party app across a firewall or whatever. It really is up to you how you want to do it.. in my case i store the users PK as the forms auth identity.
As you can see there's an [Authorize] on the ChangePassword action, if you tried to hit that without having logged in Asp.net kicks back with a "302 Found" and redirects to the Forms Auth login screen. You could override this to provide a {success = false, message = "You're not allowed to do that!"} JSON object as per links provided in previous post. This is how i handle authenticated but unauthorized requests, I use RhinoSecurity for that.

It really is that simple, the great thing about mvc is that you're not tied into using things like the crappy Membership Provider API, Login Controls etc etc and you can even do it without a single .aspx page if you wanted to.

One of the things I like about ext direct is that if it can serialize and deserialize dtos from C# to JS quite happily, I can't remember the last time I had to parse e out of a FormCollection.

Hope this helps?

PS: I highly recommend getting you hands on ExtJSInAction, chapters 16 and 17 deal with how to build and organise a "big application" and I found them indispensable.

Wow Dan, thanks for you time on that...seriously. That all makes perfect sense, although I am not familiar with NHibernate, RhinoSecurity, OR Castle Windsor stack I usually use the "hand roll everything from scratch" approach, but might be time for a change. I think I really need to just get an ASP.NET MVC app with Ext.Direct and authentication up and running first, then decide how to incorporate all these new gadgets.

Also, are you doing anything with Roles at all? I would like to be able to use roles in the Authorize attribute so wondering where that is best to do. In ASP.Net, I did this in the Application_AuthenticateRequest where I would check if authenticated and if so, then pull out the encrypted roles from the cookie and rehydrate a custom security principle and attach that to user's context. Where/how should this be done in ASP.NET MVC?

REST like support

REST like support

Hi,
I'm new to Ext.Direct and I'm trying to migrate my views from an MVC project to extjs.
Question is: why I can't have 2 methods in same controller with different HttpVerb
For example if I have:
public virtual ActionResult MyResource()
{
var modelVM = ServiceFactory.New<MyModel>();
/..
return View(modelVM);
}

Because Ext.Direct.Mvc generates proxy methods in JavaScript for all your controller actions. And if you have multiple methods with the same name, Ext.Direct wouldn't know which one to call. On the client method names must be unique. If you absolutely have to have actions with the same name on the server, then give them different aliases by marking them with ActionName attribute. Ext.Direct.Mvc will use them instead of the actual method names when it generates client-side proxy methods.

I am playing around with setting up an MVC project with Ext.Direct.Mvc. I have split my projects into Controller, Model, and Web projects. I have added the ext.direct section to the Web.config of the Controller project and added the script tag to the header section of the Default.aspx in the Web project. But where does the call "Ext.Direct.addProvider(Ext.app.REMOTING_API);" supposed to go? I tried to put it in the Application_Start of the Global.asax of the Controller project but there is no addProvider method in the Ext.Direct namespace? What am I doing wrong here, am I using the wrong version of the Ext.Direct.Mvc (downloaded from 1st page "latest") for .Net 4.0?

Thanks for your help and this MVC direct stack!

UPDATE: Ooops, ok...in the OnReady of the JS files to access the API...duh.

Well, I'm trying to work my way through this without bothering you guys by looking at the demo, but still having some issues.

Not really understanding the "<script type="text/javascript" src="/Direct/Api"></script>" code. I have put that ref in my main aspx file (head section) in my UI Web project, knowing that it is supposed to generate the client side proxy. But do I have to manually create this directory structure in the web project first, so the code can generate and store the proxy there, or is that done on the fly?

Also, how do I know if there is a problem generating the proxy? Right now I am getting an error on the addProvider method of ext-all.js, leading me to believe that the proxy generation is blowing up or something. Looks like the provider param is null when passes into the addProvider method. Kinda stuck here in trying to figure out what the problem is with generating the proxy.

Also, is the latest Ext.Direct router compatible with ExtJS ver 3.3? That is what I am using.

Ok, guess the best way to learn is first completely confuse the cr#p out of yourself, then slowly work back towards the light. I was getting so concerned with separation of responsibilities that I had my controllers in one MVC project and the web UI in another ASP.NET project thinking that I need to separate my controllers from the UI. However, this essentially creates two webs which is not smart as this was confusing the script ref to the API as it was trying to ref the API which was essentially being served by a separate web. If you must separate your controllers out, do it the smart way (as suggested by dan_b) which is to make them class libraries.

I love publishing my idiocracy...but who knows, it might helps others in the same boat