I am writing ASP.NET MVC application.
When the user first logs in, the application should display a page for his acceptance of the Terms of Use. If the user does not accept the terms, he will be redirected to log in page. If he accepts the Terms, then he can continue using my app.
Where is the best place in the application where I can check this condition in order to call ReddirectToAction ?
I would store the 'Accepted T&C' flag on a User object.
I would then retreive the logged in user information, check the flag, and redirect appropriately in the Controller Action.
If you have a "BaseController" type class that all other controllers inherit from, override the OnActionExecuting method and make the check there.
ETA - Obviously the controller that presents the terms page wouldn't have that behavior or you would end up in a redirect loop, so you would need to have a "BaseLoggedInController" or some such thing that all the controllers except for the one that presents the terms/login pages would inherit from.
There are plenty of sample applications out there that have authentication/authorization examples in them. Barring a better suggestion, I would take a look at how they handle access to a restricted page (i.e. if not authenticated then redirect to login, if not authorized then redirect to error, otherwise display page). Then you could use the same technique to redirect if they have not accepted your terms.
Implement an AuthorizeAttribute which checks the acceptance flag set on user and redirects if appropriated. If it is not set the user will be sent to terms of use page. If he denies, he will be redirected to "you should accept page".
Implement an Controller base class which is an AuthorizeFilter. Implement the check in the OnAuthorization method.
Related
In my application users are able to transfer points between them. In my view, I check if user can transfer points from his account, if he can, I render something that allows him to do that. I would not like to check that again in my controller, so I need some mechanism, that will allow me to check if user that I rendered a viewpage for, is the same as the one that is sending a request to my controller.
So basically, I would like to check in my controller, if currently logged user is the same as the one that sent the request - and to do this, I think that I need something that works similar to ViewBag, but not from the controller to a view, but from view to a controller. Is that possible?
A proper way to do this will not be the transfer of such information between user requests. Every request shall be stateless but you trying to embed a state. This is a fair way to shoot yourself in a foot.
If your action requires authentication (you are who you say you are) you should do it using standard classic ASP net way. This will embed a standard authentication token to any further user requests. This way you will know that the user is authenticated or not.
For some actions that require authorisation (user has permissions to perform an action) you must validate that a user has the power to perform such action. This must be done for every request and it is usually a fast operation. No need to optimise things here by reducing your security barrier.
If you search for authentication and authorisation with classic asp, you will get a more fine grained answer on how to do the coding bit.
I wouldn't recommend, but you can still embed hidden information with
<input type="hidden" value="..."/>
For an application, I've users which have a profile. This application is only "with invitation", and I need that the user fills its profile before doing anything else.
I've a "IsCompleted" boolean attribute on its profile, so I've no problem to know if the user has to finish its inscription or not.
But how can I create something which check, on all page that the user has to be authenticated, that the user must be completed?
I thought to create an custom AuthorizeAttribute(in fact I've already one custom, which check some roles), but I don't know if it's the right place to make this kind of controls, and how can I distinct in the HandleUnauthorizedRequest if the request has been rejected because the login wasn't valid or because the user didn't fullfilled it's informations?
You could either:
a) Put them into a 'limited' role until they enter their profile, and let the base authorisation code handle it, then add them to a 'full' role on entry of details.
b) Override the OnActionExecuting method in your controllers (or better on base controller that you use), to check to see if the user has entered their profile, before processing the rest of the action.
IF I understood what you mean then you have that, simply use the standard authentication method. Do not forget you can use groups and roles so even if a user is authenticated it can be excluded from some pages.
So I read about how implementing your own authorization routines are bad!
http://www.nashcoding.com/2011/02/05/using-the-forms-authentication-membership-provider-on-appharbor/
And I got scared, because I've been implementing my actions as such (example, preventing access to account details if authenticated user is not the logged in user)
public ActionResult DisplayAccount(int someid){
Account a = context.Accounts.Single(a => a.id == someid);
// currentUserId() returns userid from FormsAuthentication
if (!a.owner == currentUserId()){
/* Not Authorised! */
}
}
Which apparently means it will break if ASP decides to cache my action (so the action doesn't even get executed).
So I'm now looking into using AuthorizeAttribute to do what I need to do, which is
prevent access to an action if not authenticated
check if authenticated user has access to the retrieved resource
However whenever I think about it, I can't think about how to implement the 2nd point. Roles don't work because its on a site wide level, but within the application there users have roles as well (e.g. Owner, Moderator, Contributor, User etc.), and they only have these roles within their respective parts of the application (e.g. owner of thread, contributor to wiki, moderator of forum etc.)
I have run into several examples of overriding AuthorizeCore. I can sort of imagine creating multiple AuthorizeAttribute subclasses for each resource I have (luckily not many), But just by looking at it, does that mean I have to query the database everytime I hit that action to ensure that the logged in user should be able to access that data, then query the database in my action to get the model, instead of doing that in my query?
So my questions are
am I getting too worried about caching too much? Will any of the following happen
website caches user A details, which is rendered on user B's screen?
website caches admin version of a page (with edit controls), and normal user sees cached version?
Using AuthorizeAttribute is a given, but how do I achieve what I need to do in point 2 without having to hit the database prior to the Action? Or what is the best way to achieve it in any case.
Or do I only use AuthorizeAttribute to determine if the user is logged in, and do other checking logic in my action?
Anyway, I hope this post isn't treading on any old paths (I couldn't find anything on this that I found definitive)
Edit: I guess, if I don't enable caching this problem wouldn't occur, is this correct?
Edit: for now, I am going to going to use vanilla AuthorizeAttribute, then check resource level access in my actions, then make sure I don't use caching for any authenticated actions. Hopefully will get more answers for this over the week.
I used the following approach in a recent project, by creating a DataRightsAttribute that used an enumeration for each supported model type. It works by first extracting the id from the route data, formcollection or querystring. Then it queried up the model type determined by the enum, and did the appropriate check to see if the current user is authorized to access it.
Usage was like this:
[DataRights(ModelType.Customer)]
This was used alongside AuthorizeAttribute (which we overrided), and never noticed any problems with caching.
How do miscellaneous account management pages fit into a RESTful design in Rails 3?
For example, a user registers (create action) and is then forwarded to a registration success page (? action) where they are asked to now verify their email address via a url with a token (emailed to them).
When they click the link in the email, technically they are "updating" their account as part of the verification process right? So I'm thinking that would somehow map to the "update" action but the update action is expecting a PUT request. Is that correct? How do you make that work via the email?
I'm also wondering how forgot password, reset password, etc also fit into a RESTful design? Just trying to wrap my head around this.
Just because you have a result design, doesn't mean you HAVE to restrict yourself to only CRUD verbs that map 1:1 to Get/Post/Put/Delete. That said, if you want to get really RESTful, you can start to think of some of these things in terms of being their own resources. For example user verification:
User signs up, and gets sent a verification email, you already have that all squared away RESTfully it looks like
Verification url looks like: http://app.com/user_verifications/new?token=foobar (GET)
They follow the url and maybe are presented with a "Hello Dan, welcome back! Click here to verify your account" at that point you submit a form to http://app.com/user_verifications to trigger the create action there. Now on the backend, you can perform whatever actions you want, updating the user, setting them to active, or actually creating a "UserVerification" model.
Not a perfect example, but the idea is that the RESTful interface you are providing has an additional resource, in this case "user_verifications" and a user is acting upon it via HTTP methods in order to achieve the user's goals. You can apply similar logic to reset/forgot password either with a "UserSession" type resource or even as specific as a specific "ForgotPassword" resource.
Success page is just create.html.erb file. Usually you are redirecting from create action, but here you can just render success template.
Verifying. If you want to stay REST you should add one more step: GET verify, where is the form with your token present, which will lead to PUT update action. User recieves a link to this page.
But I prefer to use simple GET request here, which will update information without any additional clicks.
The same way you work with restoring passwords and other functionality. You add a page to with form that gets email, then you send a letter with link to a page with form filled with tokens and so on.
I am developing a CMS like application using MVC 3 (RC2) and I am in crossroads at this point. I am unable to convince myself if my proposed approach is appropriate or not. I guess it is because I am aware that I am trying to cut some corners which will cost me heavily later down the line.
I will get right down to describing my problem:
1) I have a resource (lets call it A) which has to be made editable.
2) I have a custom permission system implemented which has 2 (of many) permissions:
Can Edit Own Resource
Can Edit Other Resource
3) Creator of resource A is free to edit it if they have 'Can Edit Own Resource' permission.
4) A separate user can only edit A if they have permission 'Can Edit Other Resource'
Now that the requirement is described, let me tell you my approach so far:
1) I have a controller called 'ResourceController'
2) I have a action called 'Edit'
3) The action has a attribute on it: [CustomerAuthorize(Perm.CanEditOwnResource, Perm.CanEditOtherResource, Any = true)]
4) I have a service class which takes care of domain validation.
So a user get call the action method if they have either the 'Can Edit Own Resource' or 'Can Edit Other Resource' permission.
How do I decide (and where should this decision be made) on whether the user has the right permission or not (depending on whether they own the resource?) Should it be in the controller action, in the resource service class, in a separate service class?
Waiting to hear different views...
Because of the nature of MVC, you will want to have your authentication checks at a variety of points.
For one, you'll need to be able to display visual cues on the UI (i.e. show the edit button or not show it), so the logic will have to be made available to your Views.
Of course, that's only for UI purposes. You'll want authentication/authorization on your controller actions as well, just in case someone goes around your UI to access it.
Finally, the most secure place to authenticate and authorize an action is right before you perform it. If you have a handler, for example, I would place some authorization logic there. You want to make sure that no one can write around your security logic by calling the service from somewhere else, and not knowing that there were restrictions on that service. This helps make the security options more granular as well.
One way to approach it is to have 2 actions, instead only "Edit", you have "EditOwnResource" and "EditOtherResource". You can then place a single permission on each of these.
Then if you are using the MVVM pattern you can bind the availability of these actions to wether it is an ownResource or otherResource. The setting of these values is done in the view model.