tags:

views:

531

answers:

10

Having friendly URLs is generally a good thing. However, there are sometimes when it seems like a bad idea. What is your rule of thumb?

For instance, consider a situation where I want to show a Registration Success page. I want all of the underlying logic to be the same. However, depending on how they registered, I may want to display a different message for someone who registered under a certain type of role.

Here are a few, off-the-cuff examples of "hackable" (as described in link) URLs:

All of these seem bad since I don't want the URLs to be discoverable. On the other hand, I hate to do something more complex just to modify the success message slightly.

How would you handle this?

A: 

With a post submission?

If you don't want information in the URL, don't put it in the URL.

It's not always easy to do...

Karl
A: 

I would say that pages that you want to be easily indexed by the search engines use URL Routing. This includes high traffic pages.

For other pages where the users will only visit few times a month or year you can leave those to be normal urls.

azamsharp
A: 

If you must absolutely use the URL for private/personalized data, you'd probably be better off generating a random unique identifier on the server and using that in your URL. Kind of like confirmation e-mails where you have to click a link.

Otherwise, if there's any other way to not include data in the URL, you shouldn't. In the case of a successful registration, either the person just registered and you should be in a current session, or you should require them to login before they see the customized page.

a_hardin
A: 

Why not make "registration success" message be a last step, but not change pages?

You can use Ajax or Server.Transfer() to do that.

David Vidmar
+3  A: 

You can either POST the data, or, if that's not an option, set the value in a Session variable and then read the value in the success page. The actual complexity of code using the Session is about the same as using the query string.

Jeromy Irvine
+19  A: 

Bear in mind that obfuscating URLs is NOT a security measure. You should never trust outside input - filter, sanitize and implement restrictive logic. No matter how clever you believe your obfuscation scheme to be, people have cracked much more complicated security schemes with relative ease.

As a general rule of thumb - there is no good reason to obfuscate URLs intentionally. Use URLs to communicate read operations (a path to a resource). Use POST requests to communicate write operations (adding/modifying data). If a user isn't supposed to be able to do something through the URL, it should be regulated server side and through the request method.

Eran Galperin
Absolutely true. But displaying a slightly different message (a READ) isn't a high risk scenario in this case. However, it would be nice to parametrize the page in a simple fashion.
Larsenal
This answer misses the point. OP never mentioned security as a reason for wanting to obfuscate URLs for his application, and presumably he's comfortable with his input filtering. Obfuscating can be a good technique for improving usability regardless of its impact on security.
Chris Stevens
He was worried about security - his reasons for obsufcating were to protect his URLs from being "hacked".. he shouldn't trust that data in the first place, so that shouldn't be a problem
Eran Galperin
I should not have used the term "hacked" since it's ambiguous. People talk about making "hackable" URLs to say that you can and are supposed be able to figure out how to change the URL to get what you want.
Larsenal
In general, there is no good reason to obfuscate URLs intentionally. If a user isn't supposed to be able to do something through the URL, it should be regulated server side and through the request method
Eran Galperin
Probably a good rule of thumb. Add that to your answer and I'll give it the green checkmark.
Larsenal
Edited my answer
Eran Galperin
A: 

You could make some sort of checksum or hash on the querystring items, so if they mess around with the URL, the checksum fails and it kicks them out to the main page.

Mark
Unless you do something more what's keeping someone from just re-evaluating the checksum?
Allain Lalonde
@Allain Lalonde: The secret salt.
phihag
Could someone explain what's so bad about this? It doesn't sound like the OP particularly cares if people see their own id or parameter in the URL, he just doesn't want people fooling around by guessing them.
Mark
A: 

I could check from a whitelist of referring URLs so that they can't just type in a different URL. That might eliminate obvious "hack" from a passerby.

(Obviously, you can get around this if you're a nerd.)

Larsenal
Keep in mind referrer headers may be disabled due to security considerations or filtered.
phihag
Also, referer headers are easily spoofed: curl --referer http://white.listed.url/here http://attack.against.url/here
jamuraa
Yes, they're easily spoofed but the scenario here isn't critical to security. We're talking about seeing "Thanks for registering" vs "Thanks for registering for Product XYZ."
Larsenal
+1  A: 

Ok, if you don't think this is a security issue since you are only displaying a different message, then why do you care if its hackable or not?

Most users won't wouldn't notice the url is editable, so why obfuscate? The "elite hackers" will get a slightly different message, big deal.

The general answer to, "Should I obfuscate...?" is no. If its for security, hell no, otherwise why are you obfuscating? Most likely, you are wasting time.

Pyrolistical
Just doesn't feel right. Could be just me.
Larsenal
You have to remember you are not "normal". Most people who use computers are not technical like you and me, so don't worry about it.
Pyrolistical
+1  A: 

URL's are for uniquely referencing content. When the contents are the results of a process that involves several steps of dialogue, these contents can't really have a URL, because the URL does not reproduce the process.

I would forward them to RegistrationSuccess.aspx and present contents there based on the state of the session.

If somebody comes to that URL without the suitable session state, I would forward them to the front page after 5 seconds of looking at a friendly message explaining that there is nothing to see.

A better choice yet, may be to forward them to MyRegistration.aspx which is something they would perhaps like to make a favourite out of. Coming from the Registration process, it may have a box explaining that they have successfully registered. If they not coming there from the Registration process, this box is not presented. The rest of the page is the summary of all earlier Registration processes for that user.

Guge