Re: usernames and case sensitivity
> (Now that I think of it, I'm somewhat surprised that Django's > contrib.auth allows mixed case usernames. Quickly scanning through it, > all examples seem to use all lower-case anyway.) Surprised me too, but I'm not a real web developer (I pay the bills by translating technical literature) so I thought there was maybe a best practice I was unaware of. If other people are caught off guard by it, maybe a ticket should be opened... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: usernames and case sensitivity
> Using the "iexact" option would fix this case. Take a look > at:http://www.djangobook.com/en/1.0/appendixC/ > towards the bottom, in the Field Lookups section. Yes, this is what I meant by "filter with case-insensitive queries whenever the username is URL param" -- I just couldn't remember the syntax :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: usernames and case sensitivity
> You've understood me perfectly. I was just being picky. I would > *like* to preserve the option of cased usernames, but if wikimedia > doesn't fuss with it, why should I? I'll just add a clean_username > method to the registration form that .lower() 's the name entered as > suggested. > Thank you for your input. Well, wikimedia isn't the official oracle, but it works fine as a good example. (As another example, trying logging in to your gmail account using some odd variation of lower and upper case letter; google/gmail doesn't care: it's all lower case behind the scenes.) And I'm just used to all lower-case usernames anyway, although that originates probably from the fact that I'm just used to working with computer systems that have their origins in the 70's, where everything was case insensitive anyway. Though I'm not sure if *nix simply doesn't allow upper case in account names, or that's more a standard rule. (Now that I think of it, I'm somewhat surprised that Django's contrib.auth allows mixed case usernames. Quickly scanning through it, all examples seem to use all lower-case anyway.) > 2) Validate new usernames for case-insensitive uniqueness and > filter > with case-insensitive queries whenever the username is URL param. >> def view(request, username, child=None, ...): username = username.lower() >> >>> The problem here is that that even if 'Charlie' and 'charlie' cannot >>> exist as usernames concurrently, 'Charlie' still can if he gets >>> there >>> first. So if that were the case and I had '/Charlie/' and passed >>> username.lower() to `widgets = >>> Widget.objects.get(owner__username=username), it is going to look >>> for >>> charlie and won't find it. At least I am pretty sure that >>> happened to >>> me last evening when I was trying this, though it was pretty late... >> >> Ok, but cannot you store owner.username in lowercase from the start? >> At some point, Charlie wants to create an account (or however you've >> set it up), and while you have a proper name (Charlie Someone), the >> username is (invisibly) charlie. If you put in a line on the sign up >> form or similar stating that the username will be lower case, that >> shouldn't be confusing. (Eg, wikimedia doesn't bother with case for >> user accounts on sign up and afterwards. In fact, it always >> capitalizes the first letter, even if the account would 'root', which >> is typically an all lower-case account.) >> For user friendliness, the username should be invisible to the user. >> The fact that you allow it in the URL is ok, but should otherwise >> still be invisible (You could even choose to redirect to an all >> lower- >> case URL). >> Though I fear I'm simply misunderstanding your problem (or missing >> some unknowns), so all my suggestions may be of not much use anyway! >> >> Evert > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: usernames and case sensitivity
On Fri, Mar 28, 2008 at 10:02 AM, Jonathan Lukens <[EMAIL PROTECTED]> wrote: > > Hi Evert, > > > > > 2) Validate new usernames for case-insensitive uniqueness and filter > > > with case-insensitive queries whenever the username is URL param. > > > > def view(request, username, child=None, ...): > >username = username.lower() > > The problem here is that that even if 'Charlie' and 'charlie' cannot > exist as usernames concurrently, 'Charlie' still can if he gets there > first. So if that were the case and I had '/Charlie/' and passed > username.lower() to `widgets = > Widget.objects.get(owner__username=username), it is going to look for > charlie and won't find it. At least I am pretty sure that happened to > me last evening when I was trying this, though it was pretty late... Hey Jonathan, Using the "iexact" option would fix this case. Take a look at: http://www.djangobook.com/en/1.0/appendixC/ towards the bottom, in the Field Lookups section. I *think* that: Widget.objects.get(owner__username__iexact='charlie') would get Charlie, charlie, or any other case variation... That way you could also the original username value in the template, complete with capitalization. Colin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: usernames and case sensitivity
You've understood me perfectly. I was just being picky. I would *like* to preserve the option of cased usernames, but if wikimedia doesn't fuss with it, why should I? I'll just add a clean_username method to the registration form that .lower() 's the name entered as suggested. Thank you for your input. On Mar 28, 1:22 pm, Evert Rol <[EMAIL PROTECTED]> wrote: > >>> 2) Validate new usernames for case-insensitive uniqueness and filter > >>> with case-insensitive queries whenever the username is URL param. > > >> def view(request, username, child=None, ...): > >> username = username.lower() > > > The problem here is that that even if 'Charlie' and 'charlie' cannot > > exist as usernames concurrently, 'Charlie' still can if he gets there > > first. So if that were the case and I had '/Charlie/' and passed > > username.lower() to `widgets = > > Widget.objects.get(owner__username=username), it is going to look for > > charlie and won't find it. At least I am pretty sure that happened to > > me last evening when I was trying this, though it was pretty late... > > Ok, but cannot you store owner.username in lowercase from the start? > At some point, Charlie wants to create an account (or however you've > set it up), and while you have a proper name (Charlie Someone), the > username is (invisibly) charlie. If you put in a line on the sign up > form or similar stating that the username will be lower case, that > shouldn't be confusing. (Eg, wikimedia doesn't bother with case for > user accounts on sign up and afterwards. In fact, it always > capitalizes the first letter, even if the account would 'root', which > is typically an all lower-case account.) > For user friendliness, the username should be invisible to the user. > The fact that you allow it in the URL is ok, but should otherwise > still be invisible (You could even choose to redirect to an all lower- > case URL). > Though I fear I'm simply misunderstanding your problem (or missing > some unknowns), so all my suggestions may be of not much use anyway! > >Evert --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: usernames and case sensitivity
>>> 2) Validate new usernames for case-insensitive uniqueness and filter >>> with case-insensitive queries whenever the username is URL param. > >> def view(request, username, child=None, ...): >> username = username.lower() > > The problem here is that that even if 'Charlie' and 'charlie' cannot > exist as usernames concurrently, 'Charlie' still can if he gets there > first. So if that were the case and I had '/Charlie/' and passed > username.lower() to `widgets = > Widget.objects.get(owner__username=username), it is going to look for > charlie and won't find it. At least I am pretty sure that happened to > me last evening when I was trying this, though it was pretty late... Ok, but cannot you store owner.username in lowercase from the start? At some point, Charlie wants to create an account (or however you've set it up), and while you have a proper name (Charlie Someone), the username is (invisibly) charlie. If you put in a line on the sign up form or similar stating that the username will be lower case, that shouldn't be confusing. (Eg, wikimedia doesn't bother with case for user accounts on sign up and afterwards. In fact, it always capitalizes the first letter, even if the account would 'root', which is typically an all lower-case account.) For user friendliness, the username should be invisible to the user. The fact that you allow it in the URL is ok, but should otherwise still be invisible (You could even choose to redirect to an all lower- case URL). Though I fear I'm simply misunderstanding your problem (or missing some unknowns), so all my suggestions may be of not much use anyway! Evert --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: usernames and case sensitivity
Hi Evert, > > 2) Validate new usernames for case-insensitive uniqueness and filter > > with case-insensitive queries whenever the username is URL param. > def view(request, username, child=None, ...): >username = username.lower() The problem here is that that even if 'Charlie' and 'charlie' cannot exist as usernames concurrently, 'Charlie' still can if he gets there first. So if that were the case and I had '/Charlie/' and passed username.lower() to `widgets = Widget.objects.get(owner__username=username), it is going to look for charlie and won't find it. At least I am pretty sure that happened to me last evening when I was trying this, though it was pretty late... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: usernames and case sensitivity
> I am writing an application that involves a number of nested parent- > child relationships, where users create objects that each in turn have > sub-objects. So far the URL structure looks like this: > > example.com/username/ > example.com/username/child1/, example.com/username/child2/ > example.com/username/child2/grandchild1, example.com/username/child2/ > grandchild2 > > As you could guess, keyworded URL parameters are used to filter > through each level of this structure. Usernames in Django are case- > sensitive; I think it could be a real problem to have case sensitive > urls, something like example.com/Bob/widget1 and example.com/bob/ > widget1, leading to user confusion. I can think of two ways to > circumvent this: > 1) Have an uneditable SlugField in a UserProfile that is saved when > the account is created that would save the username as > username.lower(); > 2) Validate new usernames for case-insensitive uniqueness and filter > with case-insensitive queries whenever the username is URL param. > > My hope is that there is a magically third option (I wouldn't consider > a patch very magical), but if not, which of these options is better? > My guess is the first. I'd opt for the second; there won't be no need for an extra field in eg the admin view (potentially confusing other admins). Besides, unless I understand your problem incorrectly, it would be easy to transform the username to lower case and use that throughout your view (and models). You catch it once in your args/kwargs in the first line (definition) of your view, than transform it: def view(request, username, child=None, ...): username = username.lower() Perhaps there is a way to even do this at the URL level (in the regex?), but I wouldn't know. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
usernames and case sensitivity
I am writing an application that involves a number of nested parent- child relationships, where users create objects that each in turn have sub-objects. So far the URL structure looks like this: example.com/username/ example.com/username/child1/, example.com/username/child2/ example.com/username/child2/grandchild1, example.com/username/child2/ grandchild2 As you could guess, keyworded URL parameters are used to filter through each level of this structure. Usernames in Django are case- sensitive; I think it could be a real problem to have case sensitive urls, something like example.com/Bob/widget1 and example.com/bob/ widget1, leading to user confusion. I can think of two ways to circumvent this: 1) Have an uneditable SlugField in a UserProfile that is saved when the account is created that would save the username as username.lower(); 2) Validate new usernames for case-insensitive uniqueness and filter with case-insensitive queries whenever the username is URL param. My hope is that there is a magically third option (I wouldn't consider a patch very magical), but if not, which of these options is better? My guess is the first. Thanks, Jonathan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
