Web programming noob with questions

[Spacerat]

I all, I am experienced in c#, but new to web & mvc. My app has its own user management module where you create & manage users etc. Many the MVC examples use the WebSecurity class to manage users, accounts, etc.

Now seeing that my app backend does all this (login, authentication, etc) do I have to use the WebSecurity class, or can I just take it out and slot my own API into the controller methods? The ASP.NET/MVC frameworks do not depend on the usage of this class?

The next question is then: How does the framework then evaluate the methods with
[AllowAnonymous]
[ValidateAntiForgeryToken]. I.e. how does it know the user is anon or not?

TIA

 

[envo]

It's pretty easy. Much like a joint. Roll your own.

They do give you nice pre-built stuff, but you don't have to use them. Programming stays exactly the same, it's only the pattern that changes (and the nice "don't have to think about it" thing). But since you're not used to web, you won't notice the difference

Form -> submit -> Controller/Model -> set FormsAuthentication cookie yourself -> profit.

 

[shauntir]

WebSecurity is the old way to handle authentication. So yes, you can change your security backend to whatever you like.

However, I am pretty sure that what you are talking about in terms of the app already doing login and authentication is based on ASP.Net Identity.

From the MSDN docs, AllowAnonymous simply marks the region to skip the authorization. All it means is it does not matter then if the person is already authenticated or not, it will still skip the check in that region.

 

[Spacerat]

However, I am pretty sure that what you are talking about in terms of the app already doing login and authentication is based on ASP.Net Identity.

Dunno, it is completely home-rolled with a very extensive permissions model (diff from role-based). All own tables, APIs etc

From the MSDN docs, AllowAnonymous simply marks the region to skip the authorization. All it means is it does not matter then if the person is already authenticated or not, it will still skip the check in that region.

That is where my question comes from. How does the framework told that the user is auth'ed or not? What envo said about the cookie?

 

[shauntir]

Dunno, it is completely home-rolled with a very extensive permissions model (diff from role-based). All own tables, APIs etc

That is where my question comes from. How does the framework told that the user is auth'ed or not? What envo said about the cookie?

It doesn't need to know if you're authenticated for the AllowAnonymous. But to answer your questions, the framework knows if you are authenticated based on a concept called a session. When you're authenticated, your browser receives a cookie which is usually a hash that is a key to the server side session. The session can hold your user details. Once your session expires or is removed, the cookie is no longer valid.

 

[shauntir]

Also, with regards to the permissions model, are you talking about claims based authentication?

 

[Spacerat]

It doesn't need to know if you're authenticated for the AllowAnonymous. But to answer your questions, the framework knows if you are authenticated based on a concept called a session. When you're authenticated, your browser receives a cookie which is usually a hash that is a key to the server side session. The session can hold your user details. Once your session expires or is removed, the cookie is no longer valid.

OK got that, but something on the server needs to dump the cookie on the browser. But somehow this needs to be triggered from somewhere on the server side. That is still the gap in my mind.

My Auth API has a method LoginResult Login(string username,string password);
When the login is successful, the LoginResult contains my own SessionKey. After that all calls to any API needs the SessionKey as 1st parameter. The SessionKey is used to id the (previously logged-in) user that initiates the call and some other info. E.g.

ServiceResult result = myApi.GetData(SessionKey sessionKey,otherParams);

The entire domain model and back-end sits behind a services layer that exposes several APIs. The controllers will only talk to the services layer. It is designed like this to serve many different channels of interaction. So after login, my SessionKey will have to be stored in the Session if I read correctly so that the View can post that back to the controller Action, so that the controller Action method can use it in calls to the services layer

Also the logout api is:
ServiceResult Logout(SessionKey sessionKey);

After the call to logout, my SessionManager will remove the SessionKey and all calls with that SessionKey will fail. Obviously something in the ASP.NET framework needs to happen as well. E.g. flush cookie.

Also, with regards to the permissions model, are you talking about claims based authentication?

Not sure. The permissions model is based on user configurable Permissions. You then assign a set of Permissions to a User. You also assign a set of Actions to each Permission. Each action is basically an action on the front-end. So out of the total set of Actions in the application, each Permission would represent a subset of Actions (typically a business function). Permissions could overlap in their assigned Actions. So when you assign Permissions to Users, the User can execute the Actions that correspond to the union of all Permissions' Actions. E.g. View Users but not edit them. Don't know if I explain clear enough. It allows very fine grained control over what users can do and not and also easy to change profiles on the fly.

It also allows fine-grained control over Delegation of Authority where a User can (temporarily) delegate certain functions to another user and then revoke afterwards.

The Permissions also make provision for field level control. Each field on each entity can be Invisible/Visible/Visible&Editable. This is attached to Permissions so you can set up who sees what and who edits what fields.

Permissions also control the subsets of Reports, Pivots and Dashboards a particular User can run.

 

[_kabal_]

I am assuming this is how it works, because this is how it works in spring security.

There will be an interface, something like AuthenticationManager. You implement this and register it with the security framework.

use constructor injection to DI your existing security handler into the new implementation, and in the overridden methods, call the equivilent methods on the injected class.

 

[Spacerat]

I am assuming this is how it works, because this is how it works in spring security.

There will be an interface, something like AuthenticationManager. You implement this and register it with the security framework.

use constructor injection to DI your existing security handler into the new implementation, and in the overridden methods, call the equivilent methods on the injected class.

likely yes, i will check it out

 

[Spacerat]

OK so I have been reading up and experimenting with MVC.
A typical page of the app has the
header: logo, faves, login, cart, etc,
some content
and the footer (contact, etc etc).

All pages are a variation of this where mostly the content section will change. So my idea is to create an object model of all pages. The page base class will have the header and a footer where the header and footer objects provide the Model for those sections of a page.
All pages then derive from this and provide the object representation for the specific content sections.
Then the controller simply returns an instance of this page model class.

e.g.

public class PageBase
{
Header
Footer
}

public class HomePage:
PageBase
{
HomePageContent
}

Now the view can bind to this composite model
Any comments on this?

 

[Hamster]

Web is not my speciality, but isn't this what masterpages are for?

 

[Spacerat]

Web is not my speciality, but isn't this what masterpages are for?

Dunno, isnt masterpages the views rather than the models?

 

[Hamster]

Dunno, isnt masterpages the views rather than the models?

They are. I was more referring to the end result of what you are trying to achieve, but now that I read it again I'm not so sure I understood you correctly last night.