-
Notifications
You must be signed in to change notification settings - Fork 215
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue 2620 #2641
base: master
Are you sure you want to change the base?
Issue 2620 #2641
Conversation
@gsaslis can you please help review this one ? |
@ddhuy can you please sign the Contributor License Agreement at https://telestax.com/open-source/#Contribute so we can accept the contribution ? |
@deruelle , I have just signed the CLA. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great start @ddhuy !
Please look into the changes requested and let us know.
* @param email: the email address need to be verified | ||
* @return true if email format is valid, false if email format is invalid | ||
*/ | ||
public static boolean isValidEmailFormat ( String email ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would favour use of an external library that already handles email validations, rather than including our own regex here. Take a look at the JavaMail or the Apache Commons Validator for some ideas.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gsaslis I have just incorporated your comment using JavaMail API. I agree with you that using external library is better than regex.
And I found in class EmailMessageEndpoint we are using the regex for validating email format, so should we change with our new method or keep it as it is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ddhuy yes, i would suggest we include that change as well in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gsaslis , I changed to JavaMail as mentioned in class EmailMessageEndpoint as well. Please have a review and share with me your feedback.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition to the inline comments, could you please also explain your changes with commit b001a77 ?
It seems the InvalidEmailException
we used to have has both been made public but also had its type changed? Would you elaborate on why this was needed please?
isValid = true; | ||
} catch (AddressException ex) { | ||
isValid = false; | ||
logger.error("Email " + email + " is invalid"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i would change the log level here to warn
(if not info
).
(error
is usually reserved for severe issues that affect the application health. on the other hand, this is very much a normal operation of handling invalid user input - info
sounds like a better fit imho)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gsaslis Agree with you about the log level. I am prefer changing it to warn
. Thanks for your suggestion.
About the b001a77, I see that we had two different classes with exactly same purpose. So I think it should be better if we only have one interface to raise invalid email exception. Later on it will be more easier for maintenance and it is likely to have no duplicate in our code, IMO.
b639e23
to
74e55d9
Compare
@ddhuy the problem with commit b001a77 is that you've changed the type of the This means that its usages (e.g. Line 91 in e449462
RuntimeException , instead of the more general Exception .
I am not sure this is a valid / intended change... ? |
@gsaslis , Thanks for your reviewing time and comments. I think make the |
…Connect into restcomm-1543
This refer to #RESTCOMM-1618
This close #RESTCOMM-1618
This refer to #RESTCOMM-1512
This refer to #RESTCOMM-1618
…d catch clause to catch a Throwable This refer to #RESTCOMM-1618
fixes restcomm1786, unlink only removes given link
fixes restcomm1786 added extension mocks and int test cases
Restcomm1831 adjusted pre/post execpoint consistency
Restcomm 1741
* SDR service event stream implementation * sms implementation * Revert "sms implementation" This reverts commit 0d3a4bd * SDR service sms messages implementation * Revert "SDR service sms messages implementation" This reverts commit 1b464b3 * SDR service sms messages implementation * SDR service sms messages implementation
comment not applicable removed
fixes restcomm1851, constraint about status check
Fixes duplicate jars in classpath
Hi all, I have tried to resolve the merging conflict. Please help cross check them again |
Thanks @ddhuy ! @jaimecasero / @RestComm/vvs-squad does this look good to merge? |
i was thinking email is sometimes used as account key, so im not sure making email address modifiable could have some impact. Let me think about it... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gsaslis @ddhuy it seems like PR is missing integartion test when email update operation via http request. please check existing tests for accounts endpoint here https://github.com/RestComm/Restcomm-Connect/blob/master/restcomm/restcomm.testsuite/src/test/java/org/restcomm/connect/testsuite/http/AccountsEndpointTest.java
9469191
to
c67f142
Compare
Now we can be able to change the email address of an account.