Asp.NET MVC Customer Application

I'm designing (and developing) web software that will allow the general public to sign up for a service, become a customer, and exchange fairly sensitive data.

I'm working through the documentation and the tutorials, and of course the RESTful pattern adopted by the default routing in ASP.NET MVC is to do URL's like this: /customer/edit/3487.

I guess I am a little squeamish about displaying such technical details as customer ID in the URL bar.

What do the smart kids do these days? Does RESTful have to mean "put your record ID's on display"?

Edit: In an ASP.NET WebForm I would have stored this in the session, I think. But I'm finding that this is discouraged in ASP.NET MVC.

Edit: I do not intend to rely on security through obscurity.

That still doesn't mean its a good idea to give the users any ideas, or any information about the underlying data. Let's say I have an app that's publishing information about the different business in a Chamber of Commerce, to be arbitrary. Once you are logged in, you have an administrative right to click on every business in the directory and see them all - but the application is supposed to spoon feed them to you as search results or the like. Just because the user technically is allowed to access 开发者_开发问答all records, this doesn't mean it should be trivial for you to write a screen scraper that downloads all of my content in a few minutes. As well, the user can just look at customer ID's and make a guess about how many customers I might have. There's lots of good reasons not to display this.

As long is there is proper authentication and authorization being done on server side then displaying ids is not an issue.

Otherwise just try to encrypt the particular id or username in the URL, this way it will be difficult for the attacks.

You don't have to put the Id in the Url, you just need to use a unique value or unique combination of values to find the data you want to display.

I'd think that the actual bussinesses name would be good and also look good in the Url. So you would have something like this:

/Business/View/theouteredge/

Or if the business name is not unique you could use a combination of business name and zip/postal code.

/Business/View/theouteredge/78665/

You would have to write a new route to handle this.

routes.MapRoute(
  "Bussiness",
  "Business/{Action}/{name}/{zip}/",
  new { controller = "Business", action = "Index", Name = "", PostalCode = "" }
);

All this action would need to be secured with the [authorize] attribute, or the controller its self.

If you also decorate your actions with [authorise] then if another user does use the id from another user, they will automatically be challenged for a login.

It's 6 of one and 1/2 dozen of the other as to whether you use an ID or a Name. Eventually they both resolve to a record.

The important thing is to only allow authorised persons to view the data by allowing them to log in.

I've got a site which has sensitive data but only if you are the holder of that info can you see it and I do that by decorating my actions and checking rights etc.

I think that putting an ID in a url is fine -- as long as it is a Surrogate Key. The key has no value, except to identify a record. Just make sure that the requester is authorized before you send sensitive data back to the client.

Update:

I can see how having a number as part of your URL is undesirable. After all, a URL for a web app is part of the user interface, and exposing such internal details can take away from the UI's elegance. However, you are faced with limited options.

Somehow, you have to identify the resource that you want to get. The crux of REST (IMO) is that a request to a server for a particular resource must be described entirely by the request. The key for the item you want has to be encoded into the HTTP GET somehow. Your options are: put it into the URL somehow, or add it to a cookie. However, adding a key to a cookie is frowned upon.

If you look at this site you will see the question id in the url. If you view your profile you will see your username. So you would probably want to use usernames intead of an id.

If you're really concerned about it you can use a Guid, which isn't very user friendly but would be very hard to guess. :)

If you use some other way than customer id simply because you're concerned about security, then that means you're using security through obscurity, which is a bad idea. Proper authorization would require something like you either 1) have to be logged in with that customer id, or 2) be logged in as an admin, to have that request succeed.