When navigating to a new webpage, is there a "Best Practice" for passing Ids around.
For example, a person registers to use a website, they get given an Id, this needs to be passed around the rest of the website/pages where it is used to retrieve relevant data from a database.
If the Id is passed in the url: http://myWebsite.com/User/Details/1234, the user could change it to
http://myWebsite.com/User/Details/4567 and potentially retireve a different user's details.
Putting this value in a hidden field and then POSTing wouldn't be great either as "view source" would display the value.
Many thanks
That's why you should always verify that this id belongs to the currently authenticated user. The currently authenticated user is stored in the forms authentication cookie and is something that the user cannot change because the value is encrypted. This cookie is emitted when the user logs in and you can access it everywhere where you have an instance to HttpContextBase (which is pretty much almost anywhere in the V and C parts of the MVC pattern).
For example, like this:
[Authorize]
public ActionResult Foo(int id)
{
string currentUser = httpContext.User.Identity.Name;
// TODO: go ahead and check in your backed that the id
// belongs to the currently connected user
...
}
Obviously writing those checks over and over again in all controller actions could quickly become boring, not to mention the DRYness of the approach. That's why it is recommended to write a custom Authorize attribute which will perform those checks before even entering into the controller action. Then you will decorate your controller actions with this custom attribute and you will know for sure that if the code has reached inside the action it means that the current user is the owner of the id passed as parameter. The way this id is passed as parameter doesn't really matter. Could be route data, query string, POST, whatever. The user can modify it as much as he likes. The important part is that you ensure that the value he entered is coherent with your domain authorization logic.
So:
public class AuthorizeOwnerAttribute : AuthorizeAttribute
{
protected override bool AuthorizeCore(HttpContextBase httpContext)
{
var authorized = base.AuthorizeCore(httpContext);
if (!authorized)
{
// the user is either not authenticated or not authorized
// no need to continue any further
return false;
}
// at this stage we know that the user is authenticated and
// authorized (in roles), so let's go ahead and see who this
// user is
string username = httpContext.User.Identity.Name;
// now let's read the id. In this example I fetch it from
// the route data but you could adapt according to your needs
string id = httpContext.Request.RequestContext.RouteData.Values["id"] as string;
// Now that we know the user and the id let's go ahead and
// check in our backend if the user is really the owner
// of this id:
return IsOwner(username, id);
}
private bool IsOwner(string username, string id)
{
// go ahead and hit the backend
throw new NotImplementedException();
}
}
and then:
[AuthorizeOwner]
public ActionResult Foo(int id)
{
...
}
Related
Say you have a repository method to update a Document:
public Document UpdateDocument(Document document)
{
Document serverDocument = _db.Documents.Find(document.Id);
serverDocument.Title = document.Title;
serverDocument.Content = document.Content;
_db.SaveChanges();
return serverDocument;
}
In this case, the entity has two properties. When updating a Document, both of these properties are required in the JSON request, so a request to PUT /api/folder with a body of
{
"documentId" = "1",
"title" = "Updated Title"
}
would return an error because "content" was not provided. The reason I'm doing this is because, even for nullable properties and properties that the user doesn't update, it seems safer to force the client to specify these fields in the request to avoid overwriting unspecified fields with nulls serverside.
This has led me to the practice of always requiring every updatable property in PUT and POST requests, even if it means specifying null for those properties.
Is this cool, or is there a pattern/practice that I haven't learned about yet that might facilitate partial updates by sending only what is needed over the wire?
The best practice in API design is to use HTTP PATCH for partial updates.
In fact, use cases like yours are the very reason why IETF introduced it in the first place.
RFC 5789 defines it very precisely:
PATCH is used to apply partial modifications to a resource.
A new method is necessary to improve interoperability and prevent
errors. The PUT method is already defined to overwrite a resource
with a complete new body, and cannot be reused to do partial changes.
Otherwise, proxies and caches, and even clients and servers, may get
confused as to the result of the operation. POST is already used but
without broad interoperability (for one, there is no standard way to
discover patch format support).
Mark Nottingham has written a great article about the use of PATCH in API design - http://www.mnot.net/blog/2012/09/05/patch
In your case, that would be:
[AcceptVerbs("PATCH")]
public Document PatchDocument(Document document)
{
Document serverDocument = _db.Documents.Find(document.Id);
serverDocument.Title = document.Title;
serverDocument.Content = document.Content;
_db.SaveChanges();
return serverDocument;
}
Is this cool, or is there a pattern/practice that I haven't learned
about yet that might facilitate partial updates by sending only what
is needed over the wire?
A good practice of doing a POST or PUT is to only include values that you need for that specific request. In doing the UpdateDocument you should ask yourself what "really should be done here"? If you have a hundred fields on that object do you need to update all of them or only part of them. What "action" are you really trying to do?
Let's have an illustration for those questions, say we have a User object that has the following fields:
public class User {
public int Id {get;set;}
public string Username {get;set;}
public string RealName {get;set;}
public string Password {get;set;}
public string Bio {get;set;}
}
You then have two use cases:
Update the profile of a User
Update the password of a User
When you do each of those you will not, or it's a good idea to, have one update method that will do both. Instead of having a generic UpdateUser method you should have the following methods:
UpdateProfile
UpdatePassword
Methods that accepts fields that they just need, nothing more, nothing less.
public User UpdateProfile(int id, string username, string realname, string bio) {
}
public User UpdatePassword(int id, string password) {
}
Now comes the question:
I have a use case that a "user action" allows for an update on
multiple fields where some of the fields can have "no input" from the
user but I don't want to update that field in my model.
Suppose a user updates his/her profile and provided values for Username, RealName but not for Bio. But you do not want to set Bio as null or empty if it has a value already. Then that becomes a part of your application's business logic and that should be handled explicitly.
public User UpdateProfile(int id, string username, string realname, string bio) {
var user = db.Users.Find(id);
// perhaps a validation here (e.g. if user is not null)
user.Username = username;
user.RealName = realname;
if (!string.IsNullOrEmptyWHiteSpace(bio)) {
user.Bio = bio;
}
}
I have an MVC3 application that uses the standard accountcontroller that comes with visual studio to authenticate users.
I want to share specific parts of my program with people, much like google shares documents in google docs when you do that via email; in other words I don't want to give anyone access to the pages (In which case I could just remove the Authorize attributes) but I do want users to share pages based on a url with a hash in it, and have them skip the login.
I think I would like to generate the hash based on a page and link it to an anonymous user, which would then have to be auto-logged in if the hash is correct
How would I do that?
Create a table in database with shared pages information(controller, action, documentId, hash, expiresAt, etc)
Override Authorize attribute and in OnAuthorizationvalidate url params in your database.
public class SharedAuthorize:AuthorizeAttribute
{
public override void OnAuthorization(AuthorizationContext filterContext)
{
var documentHash = int.Parse(filterContext.RouteData.Values["hash"].ToString());
if (!HashRepository.CanWeRead(documentHash,controller, action, documentId))
{
return false;
}
return true;
}
}
This is just an idea=))
I am working on creating a custom membership class for my asp.net project. In the MembershipProvider class, function for user validation is defined as follows.
public abstract bool ValidateUser(string username, string password);
The problem is validation can be failed for several reason, so I want to provide more detailed description as to why login failed (e.g., user is lockedout etc) but that cannnot be done via a bool return type. I certainly can create one of my method for validation as follows
public RichStatusDetailsEnum ValidateUser(string username, string password);
Problem with above is that I will not be able to call this method in a generic way (just by Membership.ValidateUser). Rather I will have to instantiate object of my custom membership provider etc etc. Does anyone else has encountered same issue and if there are any better ways of handling this type of situation?
As per this MSDN resource, the return will tell you if it is valid. There are only two parameters (username and password). If it is a false return, then you know one of them is off. You can always test if the UserName is correct by calling Membership.GetUser(). If the MembershipUser object returned is not null, then you know the UserName is correct. In which case, that would lead you to believe that if ValidateUser() fails, it is a bad password.
To see if the user is locked out: for the MembershipUser object that gets returned from GetUser(), you can test if the user is locked out by the property Membershipuser.IsLockedOut.
Description
One way to get this done is
Store the reason, why the validation failed, in the HttpContext.Current.Items Collection
If ValidateUser failed, get the data and do something (like add an error to ModelState.AddModelError("Property","Message");
Sample
public override bool ValidateUser(string username, string password)
{
// your custom logic goes here
HttpContext.Current.Items["ValidateUserResult"] = ValidateUserFailed.UserNameWasWrong;
return false;
}
public enum ValidateUserFailed
{
UserNameWasWrong, PasswordWasWrong, BecauseIDontLikeYou
}
your other class
More Information
MSDN - HttpContext.Items Property
MSDN - ViewDataDictionary.ModelState Property
MVC best practices state that the model should handle input/data validation. Let's say that we have a model that creates new user accounts, with the following fields and constraints:
Username - not null, not already in DB
Password - not null, alphanumeric only
E-mail - not null, not already in DB, valid e-mail format
We have an AccountModel with a CreateNewUser() function:
component
{
public void function CreateNewUser(string username, string password, string email)
{
// create account
}
}
Then we have a controller that processes a form post and tells the model to create the account:
component
{
public void function NewUser()
{
var username = event.getValue("username");
var password = event.getValue("password");
var email = event.getValue("email");
var accountModel = new AccountModel();
accountModel.CreateNewUser(username, password, email);
event.addResult("UserCreated");
}
Now I want to add validation. If the user fails to provide input for all three fields, the application should show the user three validation error messages. This is easy enough to do in the controller:
// assumes that ValidateInput() is a function on the controller that returns an array
var validationErrors = ValidateInput(username, password, email);
// if there were any validation errors, return a ValidationError result
if (len(validationErrors)
{
event.setValue("validationerrors", validationErrors);
event.addResult("ValidationError");
}
else
{
event.addResult("UserCreated");
}
And the view will pull the validationerrors variable and display the error messages.
However, this logic is supposed to reside in the model. How do I do this? I can think of two ways:
Method 1: Move ValidateInput() from the controller to the model. Now the controller has to call ValidateInput() first before CreateNewUser(). If the programmer forgets to do this, CreateNewUser() will throw a validation exception. The downside to this is that now every data operation that requires validation will need an if/else block.
Method 2: Forego having to call ValidateInput() and just call CreateNewUser() directly. If there were any validation errors, an exception will be thrown and it will contain the error message array. This method would work in C#, but it looks like ColdFusion does not support returning of data with the exception, only an exception message and type. Also, every data operation will require a try/catch block.
Method 3: ??
How would you handle validation in this case? Is method 1 what most people do when it comes to validation in the model? Or do people typically use method 2? Or is there a method 3 that I'm not thinking of?
I don't think you should couple the validation of the user's data entry to the creation of the user's account: they are too different things.
If you couple the two together, it means you're basically doing form validation every time you create an account, which doesn't seem right to me.
I see form validation as a UI concern, more than a concern of the objects that might be ultimately created from that data. Obviously your createNewUser() method has its own business rules (which will probably closely mirror that of the validation for a create-new-user form, but they are still separate concerns).
It is possibly a bit unorthodox, but I will put a validateUserData() (or something) method in my User CFC which the form-validation model then calls to help with the validation. This means the business rules for a user are in the same place, and can be called separately. Thereafter, createNewUser() works on a garbage-in/garbage-out principle.
Sidenote: createNewUser() is a bit of a tautological name, innit? What other sort of user would you be creating other than a new one? Also, if it's in your Account.cfc; is it a new user or a new account that's being created? If an account and a user are not synonymous and an account might exist without a user (or vice-versa), perhaps you ought to have a User.cfc too. Then again, this code you've given us could simply be for the purposes of illustration, and you've got all this covered.
So I want to create a login page where when you enter your login credentials as a admin you get acces. If you are not a admin you get redirected back to the login page. In my database I have a field of boolean type:
isAdmin <--datatype(byte")
So how can you the best way do this?! I would like to do this in the repository pattern way as it gets easier to unit test it then.
I have googled this a lot and starting to get a bit confused on the matter. How many classes, models etc should I have?! I'm guessing one controller would do. Anyone got any good ideas?! I've read some on the DCI pattern about user roles but as it basically "only" to check that boolean in the database maybe it is overkill? Thankful for all feedback.
If I understand correctly, I had a similar issue. It seems from your question that you are not using the default membership provider (at least as is). I didn't either. So what I did was create a new authorization attribute. In your case it could look something like this:
public class AdminOnlyAttribute : AuthorizeAttribute {
IUserRepository _UserRepository;
public SimpleUser SimpleUser { get; set; }
public AdminOnlyAttribute() {
_UserRepository = new SqlUserRepository(new DbContext());
}
protected override bool AuthorizeCore(HttpContextBase httpContext) {
bool baseAuthorized = base.AuthorizeCore(httpContext);
if (!baseAuthorized) {
return false;
}
//Here you use your repository to check if a user is an admin or not
bool isAdmin = _UserRepository.IsAdmin(int.Parse(httpContext.User.Identity.Name));
if (!isAdmin) {
return false;
}
return true;
}
}
The repository method IsAdmin could be as simple as a query to check the boolean corresponding to the supplied user's ID. Something like this (please double check if SingleOrDefault() is necessary or not):
public bool IsAdmin(int userID) {
bool isAdmin = (from user in db.Users
where user.ID == userID
select user.isAdmin).SingleOrDefault();
return isAdmin;
}
And then use this in the action you want like so:
[AdminOnly]
public ActionResult Index(){
//Code here...
}
When this returns false, your ActionResult will be an HttpUnauthorizedResult which in theory should redirect to the login page.
You should create a custom Membership Provider and check the user isAdmin as part of ValidateUser.
Alternatively if other users are allowed in, use a custom role provider.
The following link is a good place to start
http://theintegrity.co.uk/2010/11/asp-net-mvc-2-custom-membership-provider-tutorial-part-1/
Is your isAdmin column a bit or a byte? It should probably be a bit. You could just create a query that checks the credentials and the IsAdmin column. If a row is returned then the login was successful.