Summary
The server-side validation failure in AddPlayer logs a misleading message that obscures the real cause and makes operational debugging harder.
When Validate.isValidUser(userName, passWord, userAddress) returns false, AddPlayer.java:158-159 logs:
} else if (!userValidate) {
log.error("JavaScript validation bypassed");
errorMessage += "Invalid Request. Please try again";
}Problems
-
Misleading wording. The message asserts "JavaScript validation bypassed", but the real cause is simply that the input failed the server-side rules in Validate.isValidUser (e.g. username length 2–32, password length ≥ 8 and ≤ 512, address ≤ 128). The most common trigger is just a too-short password — not a malicious bypass. A legitimate admin entering a 7-char password sees an ERROR-level "bypass" line, which looks alarming and points debugging in the wrong direction.
-
No detail on which rule failed. isValidUser (Validate.java:176-188) collapses several checks into one boolean, and the log gives no indication of which constraint was violated. Operators can't tell a short password from an over-long username from an over-long address.
-
Log level. ERROR overstates a routine input-validation rejection. Consider WARN (or DEBUG) unless a genuine tamper signal is detected.
Suggested improvement
- Reword to something accurate, e.g.
"Server-side user validation failed (username/password/address constraints not met)".
- Optionally log which specific constraint failed (length bounds), without logging the password value itself.
- Reconsider the
ERROR level for a normal validation rejection.
- Same pattern may exist in sibling user-management servlets (e.g.
AddAdmin, registration paths) — worth a quick grep for the identical "JavaScript validation bypassed" string and aligning them.
Acceptance criteria
Context
Found while investigating live-app logs: creating a player with username john123 / password john123 (7 chars) was correctly rejected by the ≥8 password-length rule, but the log line read "JavaScript validation bypassed", which was confusing. The validation itself is working as intended — this issue is purely about the logging.
Summary
The server-side validation failure in
AddPlayerlogs a misleading message that obscures the real cause and makes operational debugging harder.When
Validate.isValidUser(userName, passWord, userAddress)returns false, AddPlayer.java:158-159 logs:Problems
Misleading wording. The message asserts "JavaScript validation bypassed", but the real cause is simply that the input failed the server-side rules in
Validate.isValidUser(e.g. username length 2–32, password length ≥ 8 and ≤ 512, address ≤ 128). The most common trigger is just a too-short password — not a malicious bypass. A legitimate admin entering a 7-char password sees anERROR-level "bypass" line, which looks alarming and points debugging in the wrong direction.No detail on which rule failed.
isValidUser(Validate.java:176-188) collapses several checks into one boolean, and the log gives no indication of which constraint was violated. Operators can't tell a short password from an over-long username from an over-long address.Log level.
ERRORoverstates a routine input-validation rejection. ConsiderWARN(orDEBUG) unless a genuine tamper signal is detected.Suggested improvement
"Server-side user validation failed (username/password/address constraints not met)".ERRORlevel for a normal validation rejection.AddAdmin, registration paths) — worth a quick grep for the identical"JavaScript validation bypassed"string and aligning them.Acceptance criteria
Context
Found while investigating live-app logs: creating a player with username
john123/ passwordjohn123(7 chars) was correctly rejected by the ≥8 password-length rule, but the log line read "JavaScript validation bypassed", which was confusing. The validation itself is working as intended — this issue is purely about the logging.