minor issues with the latest UI improvements
Hi all, trying out the latest and greatest, here are couple of minor UI issues. All were tried on a recent clone (upto rev 3315:ac6e08aed7d4), without any modifications (just "sh setup.sh" and "sh run.sh"). 1. It is still possible to share histories without having a public name. ( maybe rev 3255:ea652508497a doesn't catch all possible cases ? ) the shared history gets a URL of "http://localhost:8080/u//h/unnamed-history" (which gives a "404 not found"). 2. The URL of a shared history contains the name of the history as the last part (e.g. "http://localhost:8080/u/gordon/h/unnamed-history"). But changing the history name (and unsharing + sharing again) does not update the URL. It will always use the original history name - very unfriendly if I publish first and then notice the bad name. 3. The opposite of 2: changing the "public user name" will cause a change in the shared history's URL. Since there's nothing preventing users from changing their public names, the published URLs are very volatile. If some day I will want to change my public name from "Gordon" to "Dr. Gordon", all the URL that I've sent or published (except on the "published histories" page) will become invalid (come to think about, the "Dr." part will never happen, so it's not critical (: ). 4. What stops a user from using somebody else's public name ? On my local galaxy I was able to give the same public name to two different email accounts. Worse: I was able to create two accounts with the same public name, and have them both public histories with the same name. Both histories got the same URL, and both appeared in the "published histories" view (but clicking on both got my to the same history). I'm not sure with public name take precedence, but if it's the last one set, then somebody can hijack all the published histories of a user by setting his public name to the other user's public name. 5. Taking items 2,3 and 4 together, I really dislike any public URL system that relies on user changeable information. I think the previous way (of using a hashed history ID) was much more robust. 6. Annotation feature: I was able to set annotations) for histories, workflows and workflows-steps, but not view them anywhere. Maybe that's just an alpha feature. but please note that I can put HTML code in the annotations, and it will be used without escaping/sanitzing. Example: create an empty history. Click on "Edit Tags and Annotation/Notes". Paste the following code in the annotation edit-box: <iframe src="http://cnn.com"></iframe> Press ENTER to save the annotation. The immediate refresh is probably done by AJAX or Javascript, so you see the HTML code. but click "refresh" and you'll see CNN inside an <iframe>. If you're going to display annotation/notes as part of published histories (where one user can publish his malicious history and other users will just view it without being able to block it) - it will be dangerous. 7. The "Edit Workflow Attributes" button is mis-placed on Firefox 3.0.6/Linux, see attached image. 8. Not UI issue, but still a bug: After uploading a wiggle file, I noticed a new file conversion option saying "Index Wiggle for Track Viewer" - obviously I clicked it ;) and got: Traceback (most recent call last): File "/home/gordon/temp/uitest/lib/galaxy/datatypes/converters/wiggle_to_array_tree_converter.py", line 8, in from bx.arrays.array_tree import * ImportError: No module named array_tree That's all for today, keep up the good work, -gordon
1. It is still possible to share histories without having a public name. ( maybe rev 3255:ea652508497a doesn't catch all possible cases ? ) the shared history gets a URL of "http://localhost:8080/u//h/unnamed-history " (which gives a "404 not found").
No, a history has to have a public name to be shared. However I'm not sure that is the problem in this case. This history has the name "unnamed-history". Have you enabled import for this history?
2. The URL of a shared history contains the name of the history as the last part (e.g. "http://localhost:8080/u/gordon/h/unnamed- history"). But changing the history name (and unsharing + sharing again) does not update the URL. It will always use the original history name - very unfriendly if I publish first and then notice the bad name.
A fix for this is planned -- it will be possible to edit the identifier used in the URL for histories (and workflows, and pages) from the sharing management page.
3. The opposite of 2: changing the "public user name" will cause a change in the shared history's URL. Since there's nothing preventing users from changing their public names, the published URLs are very volatile. If some day I will want to change my public name from "Gordon" to "Dr. Gordon", all the URL that I've sent or published (except on the "published histories" page) will become invalid (come to think about, the "Dr." part will never happen, so it's not critical (: ).
I don't think that preventing people from ever changing this is a reasonable option. However, we don't expect people to change the public username except in very special cases. We need to display a clear warning message that changing the public username will break all stable urls.
4. What stops a user from using somebody else's public name ? On my local galaxy I was able to give the same public name to two different email accounts. Worse: I was able to create two accounts with the same public name, and have them both public histories with the same name. Both histories got the same URL, and both appeared in the "published histories" view (but clicking on both got my to the same history). I'm not sure with public name take precedence, but if it's the last one set, then somebody can hijack all the published histories of a user by setting his public name to the other user's public name.
Definitely a bug, it should be checking the public usernames are unique.
5. Taking items 2,3 and 4 together, I really dislike any public URL system that relies on user changeable information. I think the previous way (of using a hashed history ID) was much more robust.
I think we can address these issues. You are right however that it *is* now possible for a user to change the url to a history. This is deliberate. There are a number of problems with the ID hashing approach we were using, primarily that ID stability relies of a secret key.
6. Annotation feature: I was able to set annotations) for histories, workflows and workflows-steps, but not view them anywhere. Maybe that's just an alpha feature.
Yes, it is, these and the following issues are being addressed. Thanks!
Hi James, James Taylor wrote, On 02/02/2010 07:27 PM:
1. It is still possible to share histories without having a public name. ( maybe rev 3255:ea652508497a doesn't catch all possible cases ? ) the shared history gets a URL of "http://localhost:8080/u//h/unnamed-history" (which gives a "404 not found").
No, a history has to have a public name to be shared. However I'm not sure that is the problem in this case. This history has the name "unnamed-history". Have you enabled import for this history?
The history had a name, it's my registered user which didn't have a public name (in the URL, the part between the /u/ and the /h/ is empty).
I think we can address these issues. You are right however that it *is* now possible for a user to change the url to a history. This is deliberate. There are a number of problems with the ID hashing approach we were using, primarily that ID stability relies of a secret key.
I actually liked the hashed-id very much... it was stable and reproducible, and supposedly safe (assuming the galaxy admin replaced the "changethisinproductiontoo" in the INI file). You're still going to use hashed-id for public datasets and workflows, aren't you? Thanks for your reply, -gordon
The history had a name, it's my registered user which didn't have a public name (in the URL, the part between the /u/ and the /h/ is empty).
Ahh, I see. Yes, this needs to be fixed (in the form of a warning or documentation).
I think we can address these issues. You are right however that it *is* now possible for a user to change the url to a history. This is deliberate. There are a number of problems with the ID hashing approach we were using, primarily that ID stability relies of a secret key.
I actually liked the hashed-id very much... it was stable and reproducible, and supposedly safe (assuming the galaxy admin replaced the "changethisinproductiontoo" in the INI file). You're still going to use hashed-id for public datasets and workflows, aren't you?
We're trying to remove reliance on hashed ids where possible. For workflows this has already been changed. (Old identifiers will continue to work).
Thanks for the feedback Assaf. Some updates:
2. The URL of a shared history contains the name of the history as the last part (e.g. "http://localhost:8080/u/gordon/h/unnamed-history"). But changing the history name (and unsharing + sharing again) does not update the URL. It will always use the original history name - very unfriendly if I publish first and then notice the bad name.
Editing page identifiers is possible as of changeset 3327.
4. What stops a user from using somebody else's public name ? On my local galaxy I was able to give the same public name to two different email accounts. Worse: I was able to create two accounts with the same public name, and have them both public histories with the same name. Both histories got the same URL, and both appeared in the "published histories" view (but clicking on both got my to the same history). I'm not sure with public name take precedence, but if it's the last one set, then somebody can hijack all the published histories of a user by setting his public name to the other user's public name.
Unique public names are required as of changeset 3328.
6. Annotation feature: I was able to set annotations) for histories, workflows and workflows-steps, but not view them anywhere. Maybe that's just an alpha feature. but please note that I can put HTML code in the annotations, and it will be used without escaping/sanitzing. Example: create an empty history. Click on "Edit Tags and Annotation/Notes". Paste the following code in the annotation edit-box: <iframe src="http://cnn.com"></iframe> Press ENTER to save the annotation.
This and similar problems have been fixed in changesets 3318, 3321, and 3327. We're also working on the other items discussed in this thread. More updates to come. Best, J.
participants (3)
-
Assaf Gordon -
James Taylor -
Jeremy Goecks