i keep hearing that i shouldn't be using primary keys in my asp.net mvc url
for example: /Users/Edit/1243
what is the issue here?
what is the alternative, putting in user names? as you want it to be unique, it seems like primary key is the cleanest option
thoughts?
I don't see any problem with putting the primary key on the URL (neither do the creators of Stack Overflow and countless other sites either for that matter). One thing that is often done is to supply the primary key and also supply a SEO and user friendly "slug" that is a human-readable title of the data that the identifier links to.
If you intend to identify a resource (in your case, a user account) you will have to supply a unique identifier on the URL. Even if you decide to not use the primary key you must still choose an identifier that cannot change.
One of the issues with putting (numeric) primary keys in the URL is someone (or some search engine) could start replacing the number with other numbers to see what you've got in your db. Often this isn't a problem, but if...
you have a situation where users are only supposed to edit or see their own data
you have content in your db that you are "hiding" by not linking to it on your website
etc...
...you have to make sure you do permission checking in your Action method to ensure no one sees data they shouldn't. As long as you are doing the proper permission checking on each request - primary keys shouldn't pose a problem.
There could be two reasons
- Security consern
- SEO Optimization
putting usernames seems to be a good alternative
I think you should keep that primary key - otherwise how will you identify your entity.
Two points:
SEO - it's better for Google & Co to read text. Why not put ID + name in the URL
Security: But it is a must to check in your BL if the current user has access rights to the requested entity.
There's no real issue with using the primary key, especially if it's int (guids make for ugly urls).
An edit is a bad example, what if you had something like
www.example.org/users/1234
That doesn't really tell you much. and if it's a profile page it's awfully counter-intuitive.
The right URL for the right job.
Related
I have been inspecting a variety of websites recently and keep encountering URLs containing strings like this, sometimes capitalised, sometimes not:
c8e700e6-4166-11e7-82b6-896b95f30f58
Does anyone know the significance or origin of this? Is it an encoding schema, something to do with the webapp framework, or something else?
Thanks
In technical terms, it's called a UUID or a universally unique identifier (aka GUID). The purpose is almost always to ensure that the page loaded by the browser is a unique URL and therefore not cached, but it can also be used to uniquely identify a session with the server.
It's not usually considered to be best practice to do it this way.
This is a GUID, use for better future unity.
Remove the possibilities of conflict on database of two companies.
PS:Sorry for my English.
Guys i'have a question.
I'm currently buiding a wizard that has 5 step's until being completed.
The user starts by the first step where he generates the entry id.
From there on i start passing the id over the url like this:
host.com/{controller}/{view}/{id}
This is how my url looks like after the step1,
------- currently at view step2 passing the id=120
host.com/{controller}/step2/120
This isn't safe because as you know, anyone can change the id and affect other users's entries. Ofc, it can be quickly solved by reading if the authenticated user is proprietary of the entry that he must be trying to access in each view.
Now, my question is... is there a better way to do this?
Any tips for future work?
Is what i'm doing enougth?
(begginer doubt praying for a expert awnser)
Cheers
...It can be quickly solved by reading if the authenticated user is proprietary of the entry that he must be trying to access in each view.
Yes, that's true. You should start there.
Here are some other things that you could do:
You could make your entry ids Guids instead, so that a would-be hacker would never try to guess an entry id.
Because using GET for sensitive data is a bad idea, you could, as endyourif suggests, pass the entry ids with hidden fields instead.
If you are truly concerned about the user altering the ID in the URL, then you must spend the additional time adding an "isOwnedBy" like functionality.
As an additional security measure, you could pass it via a hidden variable in the form so it is at least not as easy to change as well.
Edit: I like #LeffeBrune's suggestion of encrypting the idea as well. However, I still suggest that the validation is performed on the function to ensure the user owns the object. It's just good practice.
I'm defining a custom route for SEO and trying to decide whether the URL should look like site.com/user/userid/username vs site.com/user/username where user is the controller and the other two are self explanatory. Now, when I think about MS's Membership, it stores in the FormsAuthentication.SetAuthCookie the username and the user can be searched using it. I've read another article that says to keep the id and add the username or product name, what have you as having the id allows for faster lookups. What do you think is the best way to go? I'd rather not carry the ID in the url. When I set the authcookie, I could carry it in there instead of the username I guess but it just doesn't feel right that I'd call it with User.Identity.Name, but that's just me. What do you guys think?
Nobody will search for users by username on Google so from an SEO standpoint it doesn't matter. You only need to optimize those pages which have the potential to get (valuable) traffic.
Anyway, the search performance by name will be excellent as this column is indexed.
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.
Well, my question is simple.
Does the ID affect the position of a webpage on Google ?
I have links like this
http://example.com/news/title-slug/15/
and people say to me that I should remove the ID from the URL.
And I belive that is not true. By my logic, you can't depend on the title's slug. I know it should work perfectly fine if there aren't two pages that have the same title, but why should I remove the ID if there is no harm when it's there.
Yes, leave it there.
Google has no business trying to second-guess what each element of a URL represents and changing its index based on that.
URLs by their nature can map to any resource, and I'm pretty sure Google recognises that. All you should do is ensure that multiple URLs don't have the same content by using redirects. So, for example, http://example.com/news/wrong-title-slug/15/ should redirect back to http://example.com/news/title-slug/15/ rather than just echo back the same page. Google doesn't really like duplicate content.
It's fine.
But I would not put that behind the title-slug though. Some url might get more confusing than the others.
http://example.com/entry/how-to-solve-question-45/15
a better one would be :
http://example.com/entry/15/how-to-solve-question-45
Besides, you can't really rely on just the title-slug, because changing the title of an entry means breaking user's bookmark. Not to mention that it is faster to retrieve an entry from the database by an integer ID instead of an url-slug.
The problem here is not whether Google will accept it, but whether or not doing so is user-friendly.
A common reason for keeping the ID in a URL is to ensure that the URL is unique. For example, if two people on here were to create a question named "Jon Skeet Facts" we'd have a problem, whereas with the ID the users are aware that they are two different questions with the same title. This is the same as with relational databases where a unique identifier is required.
In essence, why care what Google thinks? The whole Search Engine Optimisation industry is a farce, and this is coming from someone who has been paid more than once as a SEO Consultant. Why follow what Google wants when you can map Google's intentions by making your website perfect for the user? If you make a good website Google will reward you. The ID has a reason to be there, so keep it in.
I think your fine leaving it in. Seems to make sense as you get the element for identification and the element for being descriptive. It is done on here after all.
Zeus won't strike you down for it. I prefer not to have meaningless numbers in there because it's not very attractive or semantic.
Having the id will NOT hurt your SEO rankings. Having the slug there ensures that the page's main keywords will be indexed so it's all good.