Closed (fixed)
Project:
Hosting
Version:
6.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
3 Aug 2011 at 20:25 UTC
Updated:
12 Jun 2014 at 08:59 UTC
Jump to comment: Most recent
Validation of the client form (node/add/client) is checking the internal name, but flagging the client name.
To replicate, create a client named 'qwerty'. Verify that the auto-generated internal name is also 'qwerty'. Create a second client named 'ytrewq', but manually add the internal name 'qwerty' (intentionally duplicating the first client). The client name is highlighted by the form_set_error, rather than the internal name.
Also, I assume that we want to prioritize uniqueness of internal names, but non-unique human-readable names are problematic as well. For example, the "Associate a client to this user:" auto-complete widget in the user form.
Comments
Comment #1
ergonlogicOk, having looked at this a bit further, I realize I was wrong about the nature of this bug. I think the real issue is that currently, you can create a client with a duplicate human-readable name (title), by manually inputting a unique internal name.
To replicate, create a client named "Ziggy". Verify that the auto-generated internal name is "ziggy". Attempt to create a second client also named "Ziggy". Assuming you've apllied the patch in #1237178: hosting_client_validate_suggest() appears broken You should get: "Client name already in use, try Ziggy0." Now, keeping the client name (title) "Ziggy", add an internal name of "ziggy1". The form will validate and you now have two clients with the same human-readable name.
Comment #2
ergonlogicHere's what I've done:
* disabled the internal name field on client creation
* check against duplicate sanitized titles in hosting_client_validate()
* added a check of hosting_get_client_by_uname() in hosting_client_update()
I've committed this to my dev repo: http://drupalcode.org/sandbox/ergonlogic/1226310.git/commit/f6f9a7532778...
Comment #3
steven jones commentedHmm...I think I like the approach, but just disabling the field and not letting the user know that we're doing this on purpose seems a bit odd to me. Could we change the description to let the user know that we're going to autogenerate the internal name the first time, and they can change it later.
Comment #4
ergonlogicHow's this: http://drupalcode.org/sandbox/ergonlogic/1226310.git/commit/ed6ab3acc4ca... ?
Comment #5
ergonlogicI think we'll need to explicitly check for duplication of $node->title... Changing the client prefix allows for the creation of duplicate human-readable client names (titles).
Comment #6
steven jones commented#4 is looking better.
Yeah, it'll be a bit weird if we have mulitple clients with the same name anywhere. There are modules that do this already, but I suspect they are mostly UI code, so we could steal the useful parts of one of those, or just roll our own?
Comment #7
anarcat commentedMaybe we could make the autocomplete forms look at the internal name instead of the client name? Or look at both but enter the internal name in the field?
Comment #8
ergonlogicFixed in f699566.
Comment #9
anarcat commentedi am not sure I like this infinite loop:
the reason this was breaking after 10 attempts was that we had a ceiling of 10 requests to check suggestions. we could raise that by a few order of magnitudes if you want, but think about it: if we set the limit to 1000 requests, that means that there will be 1000 SQL requests for a single HTTP query - that's huge, and that's if the limit is at 1000. If there's no limit (as the patch does), we could simply DOS the MySQL server.
Also, don't return in function hosting_client_validate(). We want to validate all fields so that the user sees all the error in the form in one shot, and not have to fix one error, submit the form, fix the other error, submit the form, etc.
Comment #10
ergonlogicFixed in 1fc8aa1
Comment #11
anarcat commentedfatal: ambiguous argument '1fc8aa1': unknown revision or path not in the working tree.
Comment #12
ergonlogicRebase messed with me. Try a27c73059
Comment #13
anarcat commentedsorry to be picky, but please bring back the for (;;) loop :)
Comment #14
ergonlogicFixed in 60b5918.
Comment #15
anarcat commentedgood, thanks.
Comment #16
anarcat commented