>> Also, how does the "standard solution" deal with GETs? > > You can put the secret parameter in the URL query string, thus > defeating the porpoise. > > More to the point, GETs are supposed to be idempotent and safe. Updating > your server's configuration does not fall into that category. Use only POSTs > for changes in state, just like the HTTP spec says.
But "safe" != "public". Part of the control panel may (side-effect-freely) show information that's supposed to be private to the node operator, like comments they've entered about other servers, or their remaining $ balance with a commercial server operator. It sounds like the usual framework's reliance upon ambient cookies leaves this uncovered, or assumes that Same-Origin-Policy protects them because the usual ways to avoid it don't make it easy to get data back out. Hrm. > Hilariously, the Ruby community found this out the hard way when Google Web > Accelerator (a cacheing proxy just like any other) prefetched links in Rails > apps like Delete Item and Buy Now and Blow Up Everything. (Note that > browsers also prefetch now, too.) Yeah, I had a similar lesson ten years ago when I stupidly used GET links to delete records in a Petmail server that I put online. The Google spider deleted every address record ever published there, one at a time. Awesome. > If you crave the visual style of text links, you can always give them > JavaScript event handlers: > > <a onclick="deleteAccount()">Delete Account</a> Hrm, so mandatory JS. I'll think about it. thanks! -Brian _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
