Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -6,10 +6,12 @@
import life.mosu.mosuserver.presentation.auth.dto.Token;
import life.mosu.mosuserver.presentation.auth.dto.request.SignUpAccountRequest;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.security.crypto.password.PasswordEncoder;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Slf4j
@Service
@RequiredArgsConstructor
public class SignUpService {
Expand All @@ -27,6 +29,7 @@ public Token signUp(final SignUpAccountRequest request) {

private UserJpaEntity doAccountStep(SignUpAccountRequest request) {
UserJpaEntity user = request.toAuthEntity(passwordEncoder);
log.info("log : {}", user);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The log message log : {} is not very descriptive. Good log messages should provide context about what is being logged. This helps with debugging and monitoring. Please provide a more meaningful message.

Suggested change
log.info("log : {}", user);
log.info("User entity created from sign-up request: {}", user);

return signUpAccountStepProcessor.process(user);
}
}
Original file line number Diff line number Diff line change
Expand Up @@ -6,23 +6,26 @@
import life.mosu.mosuserver.global.exception.ErrorCode;
import life.mosu.mosuserver.global.processor.StepProcessor;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Component;
import org.springframework.transaction.annotation.Transactional;

@Component
@RequiredArgsConstructor
@Slf4j
public class SignUpAccountStepProcessor implements StepProcessor<UserJpaEntity, UserJpaEntity> {

private final UserJpaRepository userRepository;

@Transactional
@Override
public UserJpaEntity process(UserJpaEntity user) {
if (userRepository.existsByPhoneNumber(user.getPhoneNumber())) {
if (userRepository.existsByPhoneNumber(user.getOriginPhoneNumber())) {
throw new CustomRuntimeException(ErrorCode.USER_ALREADY_EXISTS);
} else if (userRepository.existsByLoginId(user.getLoginId())) {
throw new CustomRuntimeException(ErrorCode.USER_ALREADY_EXISTS);
}
Comment on lines +23 to 27

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

Both existence checks for phone number and login ID throw the same generic USER_ALREADY_EXISTS error. This prevents the client from knowing which specific field caused the conflict. To provide better feedback, you should use distinct error codes for each case. Consider adding PHONE_NUMBER_ALREADY_EXISTS and LOGIN_ID_ALREADY_EXISTS to your ErrorCode enum and using them here.

log.info("Processing user sign-up: {}", user);
return userRepository.save(user);
}
}
Original file line number Diff line number Diff line change
Expand Up @@ -125,4 +125,25 @@ public String getPhoneNumber() {
public String getPhoneNumberWithoutHyphen() {
return getPhoneNumber().replaceAll("-", "");
}

public String getOriginPhoneNumber() {
return phoneNumber;
}
Comment on lines +129 to +131

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The addition of getOriginPhoneNumber() was necessary because the existing getPhoneNumber() method contains logic that modifies the value, which is not what a standard getter should do. This can be confusing and error-prone. While this change works, for better long-term maintainability, consider refactoring this. A better approach would be to have getPhoneNumber() return the raw phoneNumber field, and move the transformation logic to a new method with a more descriptive name, like getFormattedPhoneNumber() or getPhoneNumberForDisplay(). This would make the code more intuitive and align with standard Java practices.


@Override
public String toString() {
return "UserJpaEntity{" +
"id=" + id +
", loginId='" + loginId + '\'' +
", password='" + password + '\'' +
", gender=" + gender +
", name='" + name + '\'' +
", birth=" + birth +
", phoneNumber='" + phoneNumber + '\'' +
", customerKey='" + customerKey + '\'' +
", agreedToMarketing=" + agreedToMarketing +
", userRole=" + userRole +
", provider=" + provider +
'}';
}
Comment on lines +134 to +148

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

critical

The current implementation of toString() includes the user's password. This is a critical security risk, as it will expose sensitive user data in the logs whenever this object is logged. Passwords and other sensitive information should never be written to logs in plain text. Please mask the password field.

    @Override
    public String toString() {
        return "UserJpaEntity{" +
                "id=" + id +
                ", loginId='" + loginId + '\'' +
                ", password='[PROTECTED]'" +
                ", gender=" + gender +
                ", name='" + name + '\'' +
                ", birth=" + birth +
                ", phoneNumber='" + phoneNumber + '\'' +
                ", customerKey='" + customerKey + '\'' +
                ", agreedToMarketing=" + agreedToMarketing +
                ", userRole=" + userRole +
                ", provider=" + provider +
                '}';
    }

}