The Artima Developer Community
Sponsored Link

Weblogs Forum
Don't Let Users Confirm Via HTTP GET

21 replies on 2 pages. Most recent reply: Mar 27, 2006 7:04 PM by bug not

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 21 replies on 2 pages [ « | 1 2 ]
Bill Venners

Posts: 2244
Nickname: bv
Registered: Jan, 2002

Re: Don't Let Users Confirm Via HTTP GET Posted: Mar 21, 2006 1:36 PM
Reply to this message Reply
Advertisement
> Rules are a good thing, and followin them in general is
> also a good thing. But they are NOT religious dogma, the
> better you get to know the technology and the limitations,
> and the more you work with it, the better you can estimate
> the "why" of the rules and come to a true understanding.
> What I was saying was, that there exist certain situations
> where it is more beneficial to break a rule, than to
> blindly follow it "just 'cause".
>
> It's like arguing people never should have used tables and
> blind-gifs for design, instead they should have waited a
> few years until CSS was ready. In the meantime everybody
> should have used visually unappealing sites, "just
> 'cause".
>
I see your point not. I agree with it in general, but don't agree that this particular case of email confirmation is one in which we should violate the rule. Clicking twice to confirm something via an email is not as bad a usability hit as you would have taken by not using tables and blind gifs in the old days.

> > You could invent
> > something tomorrow that uses GETs in a way no one has
> yet
> > imagined, because the standard says that doing GETs
> should
> > always be "safe," and for the most part people follow
> > that.
>
> Like I said very constructed. How does that affect the
> very specific problem at hand: A link in an email, which
> activates an account and leads to a page, where you can
> undo the activation? Tell you what: Deal with the problem
> when it arrises, because as it is -> the "cost of failure"
> is so incredibly low. It's not like I am advocating
> sending money via clicking on links for a banking site.
> ;)
>
For me it is important. You are signing up to receive email from Artima. I never want to send an email to someone who didn't ask for it. That's spam. Even if it is very unlikely that the scenario I described involving Google Web Accelerator is going to happen, I'd rather avoid the possibility that it would happen, or something else like an link from an email somehow escaping onto the web and getting followed by a crawler. The cost of preventing that is simply that the must user click twice to confirm. It's not very onerous for the user.

> Think about this: Do you also advocate not using cookies
> at all? DO you also argue that access-logs in webservers
> break the rules and should be abolished?
>
I would prefer to avoid using cookies and especially URL rewriting for authorization sessions, because they break the REST model when backing up, and because they can easily allow authorization to be hijacked by sniffing on the network or cross-site scripting attacks. But it is hard or impossible to duplicate what you can do with cookies and URL rewriting with the standard HTTP authentication. With HTTP auth:

1) it is hard to do single sign on
2) it is hard to give the user a nice user-friendly login page
3) it is hard or impossible to log a user off a browser beyond asking the user to completely quit the browser application (that's more than user-unfriendly, it makes you're site look dumb, because every other site can log you off)
4) it is hard to personalize pages (like Welcome, Chuck. If you're not Chuck, click here.) if they are logged in, but show a guest version of the page if they aren't. As far as I can see, HTTP authentication requires me to basically ask people to authenticate when they hit a certain realm. I can't tell if they've logged in or not before I ask them to authenticate (without using a cookie).

So in the HTTP authentication case, it just has too many usability problems. I think I've figured out a way to do 1), 2), and 3) if JavaScript is enabled, but not 4). So we're planning on doing the usual cookies/URL rewriting for authentication in our new architecture (but we may use HTTP auth for administration login).

I also think logging is OK, and I mentioned it in the blog post. I tried to point out that the kind of state change that you should avoid doing via GET is when the user is agreeing to something, such as agreeing to receive email newsletters.

> > What I recommend is if possible send an HTML
> confirmation
>
> HTML emails are the devil. Congratulations, you have just
> created a lot more problems than you have solved. "just
> 'cause"

HTML email is something I've always avoided sending. We alway send plain text, but I'm been trying to figure out if we should either switch to HTML, or add an option to allow people to select whether they receive HTML or plain text email. I noticed Yahoo seems to send HTML confirmation emails. Why do you think HTML email are the devil?

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: Don't Let Users Confirm Via HTTP GET Posted: Mar 21, 2006 2:13 PM
Reply to this message Reply
> Rules are a good thing, and followin them in general is
> also a good thing. But they are NOT religious dogma, the
> better you get to know the technology and the limitations,
> and the more you work with it, the better you can estimate
> the "why" of the rules and come to a true understanding.
> What I was saying was, that there exist certain situations
> where it is more beneficial to break a rule, than to
> blindly follow it "just 'cause".

Some technologies are based on specifications, and the whole point of the specification is that there is an expected behavior that users (clients) can rely on. The implementation may not always be perfect, and the specification may also be faulty, but when there is a specification, it really defines how things should work. To break such rules just for convenience or to take a shortcut is counter-productive. It may help in the short run, but will almost certainly lead to problems down the road, because it so happens that incorrect solutions often don't scale.

That's because correctness really applies only within a given system, and a system only matters when it applies to enough existents to make a difference (is large enough to matter). For instance, it is possible to come up with a system that applies to a small subset of elements of a larger system that appear to have rules beyond those applicable to the larger system. But those rules, while valid within the smaller system, may not scale to all elements of the larger system. By the same token, "breaking the rules" of the larger system just to create/maintain a smaller system will cause that smaller system to reach limitations as it grows.

But some of us are just so busy building smaller systems that we seldom think of what will happen when the system grows and the rules applicable to the smaller system cease to apply. The trick is to balance long and short term objectives such that achieving the short-term goals does not violate the rules we must obey to achive the longer goals. Almost all meaningful systems are built that way.

I've seen this principle being violated many times, with almost always leading to the demise of the longer-term goals. For instance, releasing software that violates some specifications just because that was the convenient thing to do, will almost always result in technical support problems. Suppose you do use GETs to change application state, and suppose that a crawler comes along and changes some data for a small percent of your users. If that small percent is only 2-3 people, you really don't care. But then your site grows and that small percent becomes a few hundred a month, and then you decide to fix that problem. However, by that time your competitors that took care of the problem at the beginning are building features, while you're spending your resources fixing bugs. You thought that by now you'll have enough money to solve this problem in style, but you were wrong. You're losing users, and increasing expenses that do not lead to revenue at the same time. This is a sorry predule to a typical going-out-of-business scenario.

>
> It's like arguing people never should have used tables and
> blind-gifs for design, instead they should have waited a
> few years until CSS was ready. In the meantime everybody
> should have used visually unappealing sites, "just
> 'cause".

A better example would be to not place closing table tags in a table because some browsers can fix that problem, and inserting those closing tags would be too much trouble. So you're breaking the rule to get things out the door. This allows you to save time, and it works for some customers. But when your site has 5,000 pages and some pages have closing tags and other pages don't, who's going to clean that up? You think with that many pages you're going to have money in the bank to pay someone to do that. What if you don't?

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: GET, SET, and how a simple thing turns into a nightmare Posted: Mar 22, 2006 6:25 AM
Reply to this message Reply
> There is a difference between correctness and unnecessary
> complexity. If a specification clearly states that
> something works a certain way, and we are too busy or not
> caring enough to follow that instruction, we almost
> certainly set ourselves up for failure.

If a specification clearly states something, then tools should enforce conformity with the specification.

What is the benefit for one to define a referentially transparent protocol like GET, if it can be violated by the receiver?

The problem of 'GET' is the same problem as the problem of typing in C++: what is the purpose of adding 'const' or access control to attributes, when I can simply cast any type in my own type and get access to everything?

Specifications must be enforced by the tools. Is this Java code a response for GET? fine, it shouldn't change any state. If it does, the program should not compile.

Bill Venners

Posts: 2244
Nickname: bv
Registered: Jan, 2002

Re: GET, SET, and how a simple thing turns into a nightmare Posted: Mar 22, 2006 1:53 PM
Reply to this message Reply
> > There is a difference between correctness and
> unnecessary
> > complexity. If a specification clearly states that
> > something works a certain way, and we are too busy or
> not
> > caring enough to follow that instruction, we almost
> > certainly set ourselves up for failure.
>
> If a specification clearly states something, then tools
> should enforce conformity with the specification.
>
> What is the benefit for one to define a referentially
> transparent protocol like GET, if it can be violated by
> the receiver?
>
> The problem of 'GET' is the same problem as the problem of
> typing in C++: what is the purpose of adding 'const' or
> access control to attributes, when I can simply cast any
> type in my own type and get access to everything?
>
> Specifications must be enforced by the tools. Is this Java
> code a response for GET? fine, it shouldn't change any
> state. If it does, the program should not compile.

Your comments remind me of my very first blog post, which was also inspired by a conversation with Elliotte Rusty Harold:

http://www.artima.com/weblogs/viewpost.jsp?thread=4204

I agree that where possible create tools that guide people down the one true path. It's very much part of Artima's philosophy of software development and content too. But in some systems it isn't practical to enforce the rules. In the blog post I talk about how JVMs reject any bytecodes that are not compliant with the specification, but browsers accept and try to do the best they can with all sorts of invalid HTML. RSS readers generally are also very forgiving.

As far as Frank suggesting we set ourselves up for failure if we don't follow the rules in what we produce, I think it depends on if the system is sloppy and forgiving or strict. If I were to distribute Java bytecodes that are invalid, chances are I'd hit problems very quickly. But if I were to distribute slightly invalid HTML from this website (which I'm sure I do), chances are I'll be fine. The reason I'm confident we aren't producing perfect HTML from this site is because so far my only check has been: does it work in a browser. In our new architecture, we're going to set up a tool to automatically test that the produced pages are valid XHTML and adhere to a bunch of other rules.

In the case of not changing state on a GET, I think for the most part people do adhere to this rule, which enables things like search engines to crawl the web. So this particular social system of how GETs are used is pretty strict. Even though in some cases you'll find GETs that change state on a server, for the most part, GETs don't. That's why I think that in the case of changing state on GETs in your own applications, Franks' comment of setting yourself up for failure is valid. Not just because it is a rule, but that it is a rule that's mostly being followed by everyone else.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: GET, SET, and how a simple thing turns into a nightmare Posted: Mar 23, 2006 5:24 AM
Reply to this message Reply
> I agree that where possible create tools that guide people
> down the one true path. It's very much part of Artima's
> philosophy of software development and content too. But in
> some systems it isn't practical to enforce the rules. In
> the blog post I talk about how JVMs reject any bytecodes
> that are not compliant with the specification, but
> browsers accept and try to do the best they can with all
> sorts of invalid HTML. RSS readers generally are also very
> forgiving.
>

The real problem with IT is the philosophy of C: "90% correctness is acceptable". But that's where most of the problems come from. Correctness should be 100% ...correct, or it is not correctness at all. If a protocol is too heavy, then it should be simplified instead of coding around it. Initially, it may cost more to change the protocol than to code around it, but in the end the savings from the new and improved protocol would be immense.

Peter Kellner

Posts: 10
Nickname: pkellner
Registered: Feb, 2002

Re: GET, SET, and how a simple thing turns into a nightmare Posted: Mar 25, 2006 12:12 PM
Reply to this message Reply
Thanks for pointing this problem out. I hadn't thought about it before and will use your artima suggestion as a future design pattern for sites I build.

bug not

Posts: 41
Nickname: bugmenot
Registered: Jul, 2004

Re: Don't Let Users Confirm Via HTTP GET Posted: Mar 27, 2006 7:04 PM
Reply to this message Reply
> I see your point not. I agree with it in general, but don't
> agree that this particular case of email confirmation is one
> in which we should violate the rule.

Let's agree to disagree then. I see where you are coming from and as you point out we put different "weight"/importance to different aspects, which is not an unusual thing.

> Why do you think HTML email are the devil?

Well, acutaly it was only a figure of speech. ;) j/k
Seriously though, there is plenty written on that topic, and i don't want to hijack this discussion, this here: http://www.georgedillon.com/web/html_email_is_evil.shtml can serve as a startin point to epxlore that topic. Funny fact aside: The point where I really started hating them was when when I had to a) implement a client that sends such mails in a way that works for the majority of clients and b) compsing mails that render somewhat ok across most clients (feels like being back in the mid-nineties...).


Frank, thank you for provin my point. You spend most of your time aguing, that we have to follow the specs, because specs are important to follow. And then you slip in an example which I have now distances myself from twice in this discussion ("suppose that a crawler comes along and changes some data for a small percent of your users" - I wouldn't do that, nor am I advocating doing that). But you do get bonus points for a slippery slp fallacy, whereby nt following a spec leads to "a typical going-out-of-business scenario." Not only is it far-fetched, but there's probably more examples of people breaking the spec and thereby driving innovation and ultimately creating new specs, then there are companies who went out of business, only because they missed to follow the spec.

> Correctness should be 100% ...correct, or it is not
> correctness at all. If a protocol is too heavy, then it
> should be simplified instead of coding around it.

I would like to live in such a fairy land, where everybody agreed that correctness is the single most important thing that matters. Really. It would make life sooo much easier. Unfortunately it's a bit removed from the acutal world we all have to deal with everyday.

Flat View: This topic has 21 replies on 2 pages [ « | 1  2 ]
Topic: PyCon TX 2006 (Part 1) & A Return to the Blogosphere Previous Topic   Next Topic Topic: Python Directions and the Web Framework Problem


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us