Details

Description

When accessing futon from a vhost (where "/" doesn't return a json description of the server), you unnecessarily get an "error" popup (containing the entire html of the "/" page).
Since many CouchApps link into futon as a way for end users to edit their profiles, they get the impression that the app is "broken".

Jan Lehnardt
added a comment - 29/Oct/11 14:46 I agree that this is a usability issue, but I don't think treating any error case as a possible vhost is the the right approach.
I'd be happy to go on record to say that for the time being vhosts/rewrites don't support Futon (or vice versa) until we find a way to get this fixed.

I'd like to address the second issue you've raised first, because it's much more critical: You can't disable a user's ability to change own profile, and the current "de facto standard" (i.e. what you get from "couchapp generate" and therefore - 99% of the couchapverse) is that "edit profile" is a link to /_utils/document.html?_users/org.couchdb.user:myusername
Even if in the future a non-futon solution for "edit profile" emerges, we'd still have to leave a clue to users of legacy couchapps there (it's acceptable if they get a warning or two along the way, but we'd still need a "we've moved here" link somewhere).

Now for the issue of "treating any error case as a possible vhost": we're taking about a specific case. The function that might "fail" here is discovering the server's version. If the error is a result of something more serious than "we're on a vhost", then other alerts would (or at least should) trigger. All we need is to change the comment in the code "either it's a vhost, or things are so bad user has already figured out there's a problem and doesn't need yet another popup right now"

A more elegant way to solve this would be to use a vhost-agnostic /_version or something instead of / for fetching the version, but my patch works on localhost. The fact that I don't have it at - say - iriscouch (because it's not "official") is frightening my users, so pretty please - either do it properly (/_version) or accept this simple and harmless patch so that they can relax.

The Dod
added a comment - 03/Nov/11 17:53 I'd like to address the second issue you've raised first, because it's much more critical: You can't disable a user's ability to change own profile, and the current "de facto standard" (i.e. what you get from "couchapp generate" and therefore - 99% of the couchapverse) is that "edit profile" is a link to /_utils/document.html?_users/org.couchdb.user:myusername
Even if in the future a non-futon solution for "edit profile" emerges, we'd still have to leave a clue to users of legacy couchapps there (it's acceptable if they get a warning or two along the way, but we'd still need a "we've moved here" link somewhere).
Now for the issue of "treating any error case as a possible vhost": we're taking about a specific case. The function that might "fail" here is discovering the server's version. If the error is a result of something more serious than "we're on a vhost", then other alerts would (or at least should) trigger. All we need is to change the comment in the code "either it's a vhost, or things are so bad user has already figured out there's a problem and doesn't need yet another popup right now"
A more elegant way to solve this would be to use a vhost-agnostic /_version or something instead of / for fetching the version, but my patch works on localhost. The fact that I don't have it at - say - iriscouch (because it's not "official") is frightening my users, so pretty please - either do it properly (/_version) or accept this simple and harmless patch so that they can relax.