this, but even more.

dave, are you suggesting one completely avoid putting any parameters in a url? urls are the api to web applications. what you are talking about, in itself, isn't generally tricky or dangerous. the kinds of security bugs you're talking about have more to them.

What is this principle called?

That data validation should be done at the public borders of an API and only there. Once inside, data is assumed to be sanitized.

Came up in a code review where someone had designed an object with a single public API method that accepted possibly bad string data. Inside, the public API method delegated to a number of private internal objects to do its work. There was a null check and other validation at the start of the public API method, which was correct, but then each of the nested method calls being delegated to had their own null checks and validation, so the work was being done over and over, rather than one time in a single place.

I don't use facebook, so I'm guessing that by state in this situation, you are saying that you want to see your timeline at 9:43pm on April 1, 2014 and have a cold link to it?

If it is about preventing hotlinks in the general case, I don't understand the argument.

They seem unnecessary in most cases. Why have this:

site/article=id?12345

instead of:

site/my-clean-url

I also don't understand why this makes sense:

site/user-id=12345

instead of just hiding that away and allowing the cookies or sessions exist internally.

And then it gets more mysterious because sometimes they show user ids, cookie numbers, and all that other stuff that I think is extraneous and.. is that a possible flaw?

I think about how google does it, and it appears they run the query in the search url (along with a bunch of yucky information), but is that something they do for asynch and speed concerns?

clean urls are prettier than querystring format, but nothing makes them inherently safer. in many frameworks, eg, the route definition just maps them into the same "params" hash that they would go into as GET or POST vars.

agree having a userid is not a good idea and it should be in an encrypted session cookie.

i don't know the intracacies of why google and amazon have those huge URLs, i assume there's a good reason but you never know....

I don't really know about Facebook but I'm thinking of something a little more useful like putting a picture id in a URL to link directly to that specific picture.



Well, it depends. But maybe you want all article requests to go through one specific controller. Or maybe you don't want to wire up a bunch of routes for specific urls or whatever. Differentt frameworks have different limitations. Or maybe you want people to be able to easily reference the article id in other places.

I agree with you here. We never put PII (and we consider user ids PII) in the URL.

The query makes sense to me, again that's useful as a link but I don't really know about a lot of the other stuff. My guess is that a lot of time it's other encoded state information they want preserved.

Right, fundamentally, I don't see a huge difference between clean urls and param urls when considering GET and POST, but I'm a little confused about the reasons for stuffing all that extra information into a POST when hiding it away can do just as well, plus it seems like it's easier to handle the information since you can instantiate so much on the server and not have to worry about checking so many permutations of valid urls and all that, though I guess I can't be sure unless I learn to crack that stuff.

Does that really have to be a parameterized url? I guess there is no real difference between using something like:

/site/my-picture-id

and

/site=?my-picture-id

and I can accept that I am playing semantics here.

Fair enough. I didn't think of the idea that people would want to route them differently -- and read from the database differently? --based on parameters, but that does create quite a few interesting situations.

using both are equally easy these days and done for you out of the box in any framework and, in the case of querystring params, are automatically put into an array in default no-framework php, so it couldn't be any easier.

PII = ??

guessing "personally identifiable information"

Ah lol that makes sense...I parsed it as P2

lol so did I at first, olde worlde hardware bias

This.

CBC (Canada's BBC) News just told me that I should look for the little padlock in my browser to know if a site has been affected by Heartbleed. Seems rather irresponsible.

dave,

At a basic level index.php?module=blog&id=3 and /blog/cool-title are the same thing. I've put together a few no framework sites and the difference between the first and second one is nothing more than a rewrite rule in your web server's config file.

Also for a general rule you could say POST when you are changing something on the server and GET when you are just looking. I would never store a session ID in the url though, that should always be transferred in another way.

Imagine if 2+2 didn't save the thread information in the url, how would you be able to link to a specific thread on your own? It makes a lot of sense to store some state in the url.

and if we're being pedantic, isn't it POST for create new resource, PUT for change existing one, and GET for viewing one?

Agreed, and its actually useful to follow that. Especially since if used properly browsers can help users avoid doing stupid things like reloading POSTS.

Don't forget about DELETE!

jj,

To combat double posts I always just redirect.

Sounds too much like programming. Why wouldn't they use a dict or map or whatever the curly bracket thing is called in PHP land?

Yes, I get that you want the url's but fundamentally, that doesn't have anything to do with choosing parameter urls over clean urls.

I was trying to ask specifically about the security issues that many larger sites seem to run into with it, and for this reason, I don't understand why smaller sites using some otb framework wouldn't shut this feature off.

I'm still not sure I understand. Are you asking why we don't assign a human readable URL every time?

Like, what would you think 2+2 should do for post/thread links?

they do. it's what i meant. but we're having a high level discussion, so this comment is kind of missing the point. i could have just as well said "they stuff it into some convenient data structure..."

The paramterized url doesn't need to be there. I think I'm just bothered by certain urls more than others. When you log out of 2+2, this site explicitly says your cookies have been removed, so the parameters seem a bit redundant.

I never tried changing that number to see what happens or where the comment ends up.

If you go to youtube and search for stuff on SQL injection, the first thing they do is tell you to look for urls with '?=' in there. Obviously, I know you want to sanitize this, but I still don't see a compelling reason to have this information in the url when it is fine sitting in the server. (and yes I know that you want to sanitize the pretty stuff as well)

This is getting a little far afield. I think we all agree that this isn't inherently bad and there is some benefit to it, just don't put in unencrypted cookies, user ids, session ids, or whatever in it, and I can accept that the "safe" stuff is a matter of personal taste, limits of the framework, or whatever. Stackoverflow does it one way, HN does it the other, etc. Not worth losing sleep over.

A limitation of cookies/session storage is that you can't have multiple tabs open. I can have somewhere between 1 and 10 2+2 tabs open at any given time.

2+2's params have nothing to do with your session? For example, this page:

http://forumserver.twoplustwo.com/19.../index877.html

877 is the page number (flat view for life!)
1006555 is the thread ID
191 is likely some forum ID

They just happen to include both the ID and friendly words. The words are useful for SEO purposes and is human readable.

Stackoverflow does something similar but with an extra bonus, for example here's a random javascript question I found on the front page.

http://stackoverflow.com/questions/2...n-folder-in-pc

The 23030613 is the question ID but the title after that is isn't even relevant when it comes to pulling the question out. Go ahead and keep the ID the same but remove a few words from the title. You'll get redirected to the proper name.

This is what I do for most of my sites. I go with a format of: 82-hello-world. You get nice URLs for search engines, it's human readable and you can still do a db lookup on the ID. Rails also makes it very simple to do this.

Sometimes on big monster sites like ours you get different groups that put cruft in URL to track various things like reporting, tealeaf sessions, campaigns, etc. We've got ours whittled down to just some reporting parameters – but I'm actively trying to get rid of those.

Just out of curiosity, what do you use instead?

I haven't gotten very deep into the tracking/metrics stuff we do but I think different urls is the main way we track the success of different tweets, blogs, whatever's.