Validation for User Login field

[Dmitry A.]

Hi guys,

I propose to add Validation for user Login field using Regular Expression.

I believe, it's safer to limit the Login field to alpha-numeric symbols ONLY.

Let me know what you think.

DA.

[Phil -- wbtc.fr --]

Idea is good, could this regular expression be manually changed in an advanced user management? This would give full flexibity on this, what do you think?

2011/1/3 Dmitry A. <dand...@gmail.com>

[Dmitry A.]

Hi Phil,

The problem with making it within DB is that it's additional variable while it's more better to have this hardcoded, but can be changes via Custom PHP code as always.

The matter of fact is that you haven't changed that before and most likely won't be changing it as often now, but it's better to have this as PHP constant.

Alex, what do you think?

DA.

[Alexander Obuhovich]

No need for constant, we just can hardcode it in users_config.php file.

What about existing users. They will get "not validated" error next time they will try to update their profile.

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Dmitry A.]

Yes, you have a good point about Validation after the upgrade.

I am not sure what we can do here, what are your thoughts?

DA

[Alexander Obuhovich]

I propose to add OldStyleLogin field to PortalUser table and set it to 1 for users, whose Login field doesn't match new style logins.

For users, who have OldStyleLogin field set don't perform Login field validation. Perform Login field validation for new user registrations.

Based on OldStyleLogin field make Login field editable on my profile page.

All mentioned above should happen, when "email as login" option is enabled.

Also maybe, when "email as login" option is enabled, then don't copy email to login field, as we are doing for now.

[Dmitry A.]

Yes, I like the proposed idea with OldStyleLogin field

Now we need to look into the exact logic where the Login field is used and properly right out the development plan for this.

I'll try to do this within this week.

DA

[Phil -- wbtc.fr --]

Dmitry,

does your idea was about field validation for email, or for all types of logins? email have they own regexp to be validated, and you'd like to add a alphanumeric regexp for non-email logins, that's it?

p

2011/1/4 Dmitry A. <dand...@gmail.com>

[Alexander Obuhovich]

We have 2 login modes:

1. by email
2. by login

In case, when "EmailAsLogin" configuration is enabled, then email is copied into login field.

Since we add validation to login field, then we shouldn't validate it when email is copied there. Also email coping seems a bit odd, so I propose not to copy email into Login field at all.

[Dmitry A.]

Yes, I suppose Alex's idea NOT copying Email into Login field when first one is used.

I think all this can be summarized into one task related to Login field changes. What do you think?

DA

[Alexander Obuhovich]

Yes, seems to be pretty clear plan on how we should do this.

[Phil -- wbtc.fr --]

yup, nothing to add

2011/1/5 Alexander Obuhovich <aik....@gmail.com>

[Dmitry A.]

Here is a task for this:

964: Improvements to user Login field

http://tracker.in-portal.org/view.php?id=964

NOTE: the title has been changed to accommodate both improvements described here. 

DA

[Alexander Obuhovich]

One problem appeared after this task was implemented. Since "Login" field is no longer required during a registration, then it's impossible to user "user selectors", like one in order general tab.

Any ideas on how to solve this? We won't be coping Email into Login field as before, that's for sure.

Maybe we can select user login this way:

SELECT IF(Login = '', Email, Login)

FROM PortalUser

[Alexander Obuhovich]

I've found more elegant solution: use Email instead of Login field in all user selectors.

Since e-mail is filled in any case, then it will be more useful.

Dmitry, what you think about that.

[Dmitry A.]

I believe this would solve described problem very well!

In any case we would need to run a couple of tests once we have your idea implemented, plus it goes into 5.2.0 so we have room for tests.

DA

[Alexander Obuhovich]

So what option is better to be implemented:

1. use e-mail instead of login in all user selectors
2. use e-mail, when login isn't available for all user selectors

?

Please also describe pros/cons of each approach.

Also maybe we can enable "use e-mail as login" option by default now for new installations? And always show Login field on registration/my profile forms, since now we hide it completely when registration is performed by e-mail.

[Alexander Obuhovich]

Ping to Dmitry.

[Dmitry A.]

Hi,

I believe we should do - 2. use e-mail, when login isn't available for all user selectors

The idea is that websites/projects can have different creation when to use Login field and when Email field are primary identifier for their users. In real live we can't fully predict this.

Lately we see that more and more projects require Email address as their primary identifiers for the user, but still there are some projects that use Login field too.

For this reason I believe we should:

a. use Email field when Login isn't available

b. enable "use e-mail as login" option by default now for new installations

c. add Validation for user Login field using Regular Expression (as originally described)

Make sense?

DA

[Alexander Obuhovich]

Yes.

I've created a task  http://tracker.in-portal.org/view.php?id=1363, but changed e-mail to be default value for user selector, because you suggested to make e-mail registration default one.

[Dmitry A.]

Will it still work of we change it to use Login/username (not email) as primary?

DA

[Alexander Obuhovich]

Yes, Email is required field. But it will also work if we decided to make e-mail non-required too.

On Mon, Jul 23, 2012 at 7:19 AM, Dmitry A. <dand...@gmail.com> wrote:

Will it still work of we change it to use Login/username (not email) as primary?

DA

[Alexander Obuhovich]

Here are the patches.

Ready for testing.