Phone number check algorithm has holes

Description

1. Create one user, and add him to be the friend of the default user--admin.
2. Now go to Contacts portlet, and click on the icon which will leads you to add contact info.
3. Now fill in the following in the phone-number-inputbox, "123232aadsfa" and "asdfasdfa", and you would see different result. Using the pure letter string, you would get the error message, but using the first one, you would get these letters got deleted directly without giving any warning message.

Activity

Show:

Cynthia WilburnMarch 12, 2012 at 2:19 PM

Reopening to add 6.1.1 CE GA2. Close as Fixed.

Manuel de la PeñaJanuary 24, 2012 at 2:21 AM

Phone number should be validated in a stronger way:

1) Is not null
2) Check type of PhoneFormat
2.1) if USAPhoneFormat: check alphanumeric, strip
2.2) else: check all characters are digits, don't strip

I suggest improving architecture, adding validateNumber(String) method to com.liferay.util.format.PhoneNumberFormat.

Then, I'd create a GenericPhoneNumberFormat implementing that interface, and modifying other implementations (USAPhoneNumberFormat and IdenticalPhoneNumberFormat) to include the new method.

com.liferay.util.format.PhoneNumberUtil also should include a new method to validate the number.

Juan FernándezMay 10, 2010 at 4:15 AM

This method has been developed on pourpose to behave like that

Juan FernándezMay 4, 2010 at 1:50 AM

Hi Michael:
in PhoneLocalServiceImpl, lines 116 & 117, there are two calls to the PhoneNumberUtil.strip(number) method.
This is coded to do what you camplaint about. So this issue can be fixed just removing those two lines.
The point is that they're there because somebody thought it was needed for some reason... can you think a use case where this is necessary so that we can't delete those lines?
Thanks
Juan Fernández

Fixed

Details

Assignee

Reporter

Branch Version/s

6.1.x

Backported to Branch

Committed

Git Pull Request

Components

Affects versions

Priority

Zendesk Support

Created April 15, 2010 at 12:10 PM
Updated June 23, 2023 at 9:03 PM
Resolved March 12, 2012 at 2:43 PM
Loading...