Unique fields in tl_member

[zag]

Hi all,

I've added a few custom fields to tl_member and created a form that can be used by people to sign up to the organisation, with their details then being stored in tl_member.

But now I noticed that 'username' isn't unique, so two people can sign up and choose the same username. How does this work ? I know that the 'id' field is unique and is the real identifier for individual records, but for login purposes people will be using the non-unique 'username' field.

We have to have non-unique email addresses also as in this organisation we could have a parent registering 2 children and both would be contactable via the parents single email address.

We could end up with a situation where we have the following three users -
a) id = 34, username = johh.smith, email=mr.smith@gmail.com, password=johnsmith
b) id = 76, username = john.smith, email=parent.smith@hotmail.com, password=johnsmith
c) id = 77, username = mary.smith, email=parent.smith@hotmail.com

So, either user 76 or 34 can login with the same username and password - how will typolight determine which user is actually logging in ?

And if John & Marys parents forget the password and request a new one, what happens when they request a password reset based on the email address parent.smith@hotmail.com ? Which account does it relate to - 76 or 77 ?

The first of these can presumably be overcome by making sure that username is unique, but it looks like it's not that way out of the box. Am I missing something, or do I just set it to unique ?

Thanks,

z

[acenes]

There must be something broken in your installation.

When I try to register the same username again, I get an error Duplicate entry in field "Username"!

Edit:

Maybe because "johh.smith" is not the same as "john.smith" ?

[ramjet]

I see what you mean, the Lost Password assumes a unique email address entry, whereas the field is not set to unique.
Not sure what happens in this case...potentially its a bug.

But now I noticed that 'username' isn't unique

The members username is already set to unique in the tl_member DCA , so you shouldn't be able to have duplicates.
If you can theres a need to report this in the Ticket system as a bug... you'd better doublecheck.

		'username' => array
		(
			'label'                   => &$GLOBALS['TL_LANG']['tl_member']['username'],
			'exclude'                 => true,
			'search'                  => true,
			'sorting'                 => true,
			'flag'                    => 1,
			'inputType'               => 'text',
			'eval'                    => array('mandatory'=>true, 'unique'=>true, 'rgxp'=>'extnd', 'nospace'=>true, 'maxlength'=>64, 'feEditable'=>true, 'feViewable'=>true, 'feGroup'=>'login')
		),

[ramjet]

I've had a look in the old forum and in the ticket system, and I can't find anything re the lost password module.
Strange no-ones picked this up yet.

It would make more sense that the password module asks for the username instead of (or as well as) the email address, because the username is unique, wheras the email address isn't.

Personally I think you should post a ticket about this.

[zag]

Thanks for the replies. I've checked in the DCA file and it is as it appears above, with "'unique'=>true" set, so as you say it should be unique from this perspective. But when I check in the database backend it's not set to unique. If my understanding of typolight is correct then the database.sql file should have a line in it which sets the value in the database (and not just the DCA) to unique.

Here's what tl_user looks like and you can see that the username (for a user) is set to unique in the database -

CREATE TABLE `tl_user` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `tstamp` int(10) unsigned NOT NULL default '0',
...SNIP...
  `currentLogin` int(10) unsigned NOT NULL default '0',
  `lastLogin` int(10) unsigned NOT NULL default '0',
  PRIMARY KEY  (`id`),
  UNIQUE KEY `username` (`username`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Here's what tl_member looks like and there is no corresponding 'UNIQUE' entry at the bottom -

CREATE TABLE `tl_member` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `tstamp` int(10) unsigned NOT NULL default '0',
...SNIP...
  `currentLogin` int(10) unsigned NOT NULL default '0',
  `lastLogin` int(10) unsigned NOT NULL default '0',
  PRIMARY KEY  (`id`),
  KEY `username` (`username`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

So, I reckon the problem here is that the line should be
UNIQUE KEY `username` (`username`)
with the result that the database field is marked as unique, but I am not familiar enough with how typolight hangs together to be sure that this is definitely correct.

I'm happy enough to add the change into my config, but if it is actually a bug I'll flag it up wherever the official place is if someone points me in the right direction.

I'm still a little mystified as to how my forms made it past the 'unique' setting in the DCA though. I can only guess that somehow the DCA isn't being applied to the data in the form that I created. I know that the fields are being updated in the database no problem and appear when I go into the member list in typolight, complete with non-unique usernames.

z

[acenes]

No, you simply misspelled the name in one case, as I pointed out above.

[zag]

Sorry, I had a typo in the lines above, but these were just example values I was giving and were not taken directly from the table. They should both have read "john.smith" As it stands I am able to input multiple identical values for 'username' using a form generated by a combination of typolight & efg.

My work around for the moment is going to be to change the database.sql (or create a new module and do it there) to include the unique indicator to make sure that no matter what way the records are generated, they can't get written to the database if they contain non-unique values. Right now the acid test for me is whether the database backend reports that the field is set to unique and right now it's not.

I don't know whether to raise it as a bug as this involves me knowing whether the existing config is 'by design' and I don't know that, but I have a strong hunch that it's not by design. If it was then there would need to be a good reason why users have unique usernames but members don't and I can't see that reason at the moment.

z

[acenes]

If you had mentioned that you are using custom form (instead of TYPOlights native User Registration module) the case would have been clear in first place.

DCA constraints of TYPOlight are enfoced on application level, so if you replace the member registration by a custom form it is up to your form to do the necessary validations. This is clearly not a bug of TYPOlight, but a bug of your custom forms logic.

[ramjet]

Acenes is right (i didn't realise it was efg either...which i've never used).
There is a forum topic for extensions (EFG has its own one i think) where you're better off asking stuff re EFG there, as chances are the writer of the module will see it.
Bug reports are for Core only.

I think the Lost Password may be a bug though, as I can't see how Typolight could determine the difference if you allow duplicate emails (which you can allow).

[acenes]

I think the Lost Password may be a bug though, as I can't see how Typolight could determine the difference if you allow duplicate emails (which you can allow).

I dont agree this to be a bug.

The normal case of the lost password module is to have input of the username enabled in the module config, so basically you need to enter both, username and email, to get a new password. Leo writes in his book that disabling the username input is not recommended. You should only disable input of the username when you on the other hand make sure that the email address is unique (in DCA or in your custom registration form).

[ramjet]

Youre quite right Acenes.
I didn't realise there was a 'Skip Username' field in the module setup (although I must have ticked it at some stage...Altzeimers I think)....

So no bugs Zag ... (hope I haven't put you wrong re posting a Tickets) :?