Spring по умолчанию отфильтровывает из запроса поле под названием «пароль»? оно всегда равно нулю. Кажется, я читал что-то об этом раньше. Но как я могу отключить его для этой конкретной конечной точки?
На снимке экрана показан запрос справа и выходные данные отладчика слева для SingUpRequest. password всегда пусто и я не понимаю почему. Я только начинаю изучать Spring, пытаясь выйти из мира PHP.
Подпись контроллера:
@PostMapping("/sign-up")
public String SignUp(
@RequestBody SignUpRequest signUp
)
public class SignUpRequest {
public Account account;
public Organization organization;
public UserProfile userProfile;
public Account getAccount() {
return account;
}
public void setAccount(Account account) {
this.account = account;
}
public Organization getOrganization() {
return organization;
}
public void setOrganization(Organization organization) {
this.organization = organization;
}
public UserProfile getUserProfile() {
return userProfile;
}
public void setUserProfile(UserProfile userProfile) {
this.userProfile = userProfile;
}
}
Субъект учетной записи:
@Entity
@Table(name = "accounts")
public class Account {
@Id()
public String accountId;
@NotBlank(message = "Email is required")
public String email;
@NotBlank(message = "A password is required")
public String password;
public String confirmPassword;
public String test;
public String emailVerificationToken;
public LocalDateTime emailVerificationTokenExpiresAt;
public void setEmail(String email) {
this.email = email;
}
public String getEmail() {
return email;
}
public String setPassword(String password) {
return password;
}
public String getPassword() {
return password;
}
public void setEmailVerificationToken(String emailVerificationToken) {
this.emailVerificationToken = emailVerificationToken;
}
public String getEmailVerificationToken() {
return emailVerificationToken;
}
public void setEmailVerificationTokenExpiresAt(LocalDateTime emailVerificationTokenExpiresAt) {
this.emailVerificationTokenExpiresAt = emailVerificationTokenExpiresAt;
}
public LocalDateTime getEmailVerificationTokenExpiresAt() {
return emailVerificationTokenExpiresAt;
}
public boolean checkIfEmailVerificationTokenIsExpired() {
return LocalDateTime.now().isAfter(emailVerificationTokenExpiresAt);
}
@Override
public String toString() {
return "Account{" +
"accountId='" + accountId + '\'' +
", email='" + email + '\'' +
", password='" + password + '\'' +
", emailVerificationToken='" + emailVerificationToken + '\'' +
", emailVerificationTokenExpiresAt = " + emailVerificationTokenExpiresAt +
'}';
}
}
JSON, который я отправляю через Postman:
{
"account": {
"email": "[email protected]",
"password": "password",
"confirmPassword": "password",
"test": "test"
},
"organization": {
"name": "Phauthentic"
},
"userProfile": {
"firstName": "Florian",
"lastName": "Krämer"
}
}
Может быть, у вас есть OncePerRequestFilter, который удаляет данные пароля? Или что-то еще, даже предшествующее самому Серверу.
Нет, это не сработает, потому что выдает исключение, поскольку пароль не может быть пустым.




Что ж, геттер есть геттер, а сеттер должен действовать как сеттер. Попробуй это:
@Entity
@Table(name = "accounts")
public class Account {
@Id()
public String accountId;
@NotBlank(message = "Email is required")
public String email;
@NotBlank(message = "A password is required")
public String password;
public String confirmPassword;
public String test;
public String emailVerificationToken;
public LocalDateTime emailVerificationTokenExpiresAt;
public void setEmail(String email) {
this.email = email;
}
public String getEmail() {
return email;
}
public void setPassword(String password) {
this.password = password;
}
public String getPassword() {
return password;
}
public void setEmailVerificationToken(String emailVerificationToken) {
this.emailVerificationToken = emailVerificationToken;
}
public String getEmailVerificationToken() {
return emailVerificationToken;
}
public void setEmailVerificationTokenExpiresAt(LocalDateTime emailVerificationTokenExpiresAt) {
this.emailVerificationTokenExpiresAt = emailVerificationTokenExpiresAt;
}
public LocalDateTime getEmailVerificationTokenExpiresAt() {
return emailVerificationTokenExpiresAt;
}
public boolean checkIfEmailVerificationTokenIsExpired() {
return LocalDateTime.now().isAfter(emailVerificationTokenExpiresAt);
}
@Override
public String toString() {
return "Account{" +
"accountId='" + accountId + '\'' +
", email='" + email + '\'' +
", password='" + password + '\'' +
", emailVerificationToken='" + emailVerificationToken + '\'' +
", emailVerificationTokenExpiresAt = " + emailVerificationTokenExpiresAt +
'}';
}
}
Обратите внимание на разницу в методе setPassword.
Кроме того, вы путаете типы доступа к связанным полям. Например. для submitPassword нет Getter/Setter, поэтому ORM возвращается к прямому расчету отражения поля. Используйте либо то, либо другое. Если нет конкретной причины использовать Getter/Setter, добавьте @Access(AccessType.FIELD) в класс. В противном случае укажите Getter/Setter для всех полей. В любом случае, постарайтесь оставаться последовательными.
Боже мой... 🫢 спасибо, что доказал, что кодирование поздно вечером - не всегда хорошая идея... Я чувствую себя идиотом. 😑Спасибо большое!
@floriank К слову; если вы используете Spring-Boot, нет смысла вручную писать геттеры и сеттеры. Включите зависимость org.projectlombok:lombok (она определена в родительской спецификации). Затем добавьте аннотации @Getter и @Setter в свой класс. Прочтите о ломбоках, это сэкономит вам массу времени, сделает ваш код чище и предотвратит возникновение подобных проблем).
Еще раз спасибо. Я попробую! Из любопытства, в чем обратная сторона его использования? Добавление большего количества абстракций и библиотек всегда имеет эффект.
Минус в том, что вам придется подчиняться дополнительной библиотеке. Это процессор предварительной компиляции, который изменяет ваш код в соответствии с конкретными аннотациями. На первый взгляд это может быть полезно, но в некоторых случаях может быть ограничивающим фактором. Современные IDE очень хороши в добавлении необходимых Getter/Setter/Constructor одним нажатием клавиши. Кроме того, они могут скрыть от вас этот шаблонный код, используя регионы. Так что на самом деле больше нет веской причины использовать Ломбок. Я бы посоветовал не делать этого и иметь уже готовый окончательный код, полностью изменяемый по вашему желанию и не имеющий другой зависимости, которая скрывает код для вас.
Также вам не следует полагаться на Lombok для Hashcode и Equals. По моему мнению, всегда лучше делать это вручную, поэтому вам придется подумать о том, какие поля действительно необходимы и, таким образом, почти всегда повысить производительность.
Спасибо, это подтверждает мои опасения и предположения по поводу использования этой библиотеки. Звучит хорошо для прототипирования, но не для производства.
Просто из любопытства: можно ли зарегистрироваться?