Impact for implementing String hash code for Screen Name

[Shashant Panwar, geändert vor 11 Jahren.]

Hi,
I am implementing a change where I need to update the screen name with the String hashcode value(earlier screen was original username) in liferay db.I want to store the hash code in liferay db because it does not support special characters like (_,@,etc).
I was wondering how to handle the scenario where hashcode of string is same as groupId value or userId value because all are numeric values except my generated code is int and others are long.
Can any member or someone from liferay staff explain me the impact of doing this? I don't future hassles in future as it will impact the whole application.

Thanks & Regards,
Shashant

[David H Nebinger, geändert vor 11 Jahren.]

Screen name is not really used for anything real besides the login. It is not a key field, so it is not an FKEY used by any other table, such as group id and whatnot. I often use the screen name in logging because a) it's unique and b) it is shorter than the full name.

Changing the screen name to a hash code is, IMHO, pointless, as no one would remember it for logging in and it is worthless when using in a logging statement.

Sounds to me like you're really asking if you can steal the username away from Liferay and use it for your own purposes. I'd recommend not doing that; stick to approved ways for adding custom fields to the User object, i.e. expandos.

[Shashant Panwar, geändert vor 11 Jahren.]

Hi David,
Thanks for replying.
Actually I am making this change because I want to allow users to enter special character.I already implemented custom attributes but in order to change the existing screen name I have to make this change, Liferay "validateSceenName" method checks if screen Name is numeric then it validates screen Name(it should not be equal to userId or groupId value).

Thanks,
Shashant

[David H Nebinger, geändert vor 11 Jahren.]

Again, screen name is not really visible anywhere in the Liferay system, outside of allowing it to be used for login. Most sites typically use the email address for the login, and in those cases screen name doesn't really need to exist at all.

Now, that being said, you don't need to override anything to affect this change. There's a property that you can add to portal-ext.properties, users.screen.name.validator, which has the class Liferay should use for screen name validation. You would just need to implement your own class (see com.liferay.portal.security.auth.DefaultScreenNameValidator or LiberalScreenNameValidator for examples) and specify it in the file.

However, unless you're using screen name for the login, I wouldn't worry about what the screen name actually is.

[Shashant Panwar, geändert vor 11 Jahren.]

Thanks David, references cleared my doubts

[Siby Mathew, geändert vor 11 Jahren.]

Hi David,
Actually there is an issue with the liferay implementation of the screenname validator.
If you see UserLocalServiceImpl.validateScreenName(), the method is doing some extra validation even after invoking the screen name validator instance.
Due to this, I think the users.screen.name.validator might not work.

Thanks,
Siby

[Praveen Acharya, geändert vor 8 Jahren.]

We have a requirment to hash the screenName and store in the User_ table. Question is:
1. When creating the new user which file to change for hashing and storing in db.
2. When login which file to change for the login to work. The user is going to enter plaintext screenName but db will have hashed screenName.

And as mentioned, if screenName is not used anywhere else in Liferay. hopefully just the above two will keep Liferay stable and unbroken in all other respects.

Thanks