You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug] Basic auth decodes the credential as ASCII and splits on every colon: a non-ASCII password answers 401, a password with ':' answers 400 #3284
I have confirmed and searched that there are no similar problems in the historical issue and documents
Environment (环境信息)
Server Version: 1.7.0 (hugegraph/server:latest, image 0c58df2cae57; GET /versions reports core 1.7.0). The code below is unchanged on master at d9abcd4
Backend: RocksDB, 1 node, usePD=false, authentication on (PASSWORD set)
OS: Docker on Linux
Data Size: empty graph
Expected & Actual behavior (期望与实际表现)
Expected: any password the user API accepts can be used for HTTP Basic login.
Actual: the API accepts a non-ASCII password and a password containing :, but Basic login with either one fails. Measured 2026-10-07: set the admin password with PUT /graphspaces/DEFAULT/auth/users/-27:admin, then call GET /graphs with curl -u admin:<new password>.
New admin password
PUT
Basic login with the new password
Basic login with the old password
newpass1234 (control)
200
200
401
ädminpass1
200
401 Authentication failed
401
new:pass1234
200
400 Invalid syntax for username and password
not tried
The non-ASCII row leaves the admin account with no working Basic login.
auth = newString(DatatypeConverter.parseBase64Binary(auth), Charsets.ASCII_CHARSET);
String[] values = auth.split(":");
if (values.length != 2) {
thrownewBadRequestException("Invalid syntax for username and password");
Decoding as US-ASCII turns every non-ASCII byte into U+FFFD, so the password checked is never the one that was stored.
split(":") cuts the password at every colon. RFC 7617 forbids a colon only in the user-id, so the credential should be split on the first colon.
Proposed fix: decode as UTF-8 (RFC 7617 section 2.1) and split at auth.indexOf(':'). A regression test in the auth API tests can cover both cases.
The Helm chart works around this by refusing such admin passwords in values.schema.json:824 and in its Server wrapper. The TODO at AuthenticationFilter.java:187 (from #3260) points here, and that guard can go once this is fixed.
Proposed for 1.8.0 (#3242): the fix is two lines, and today an admin password change through the API can lock the admin out of Basic login.
Reproduction
On a Server with authentication enabled and admin password adminpass123:
In the run above, the docker run entrypoint (HG_SERVER_BACKEND=rocksdb, HG_SERVER_USE_PD=false) kept waiting for a Store, so the Server was started inside the container with bin/init-store.sh and bin/start-hugegraph.sh.
@bitflicker64 Thanks for the detailed report. Our current preference is to preserve compatibility and keep the change focused.
We should distinguish the restrictions imposed by HTTP Basic from any additional product-level character policy. RFC 7617 forbids control characters in both usernames and passwords, and forbids a colon in the username. A colon in the password is valid: only the first colon separates the two fields. Ordinary spaces and commas are not prohibited by that rule.
Credential validation should be consistent between creation/password updates and login. Unsupported input should be rejected before saving a change, so it cannot leave an account with an unusable password. Any broader ASCII-only restriction needs a separate compatibility decision rather than being inferred from Basic's rules.
Activity
imbajin commentedon Oct 7, 2026
@bitflicker64 Thanks for the detailed report. Our current preference is to preserve compatibility and keep the change focused.
We should distinguish the restrictions imposed by HTTP Basic from any additional product-level character policy. RFC 7617 forbids control characters in both usernames and passwords, and forbids a colon in the username. A colon in the password is valid: only the first colon separates the two fields. Ordinary spaces and commas are not prohibited by that rule.
Credential validation should be consistent between creation/password updates and login. Unsupported input should be rejected before saving a change, so it cannot leave an account with an unusable password. Any broader ASCII-only restriction needs a separate compatibility decision rather than being inferred from Basic's rules.
Reference: https://www.rfc-editor.org/rfc/rfc7617#section-2
fix(server): split Cypher Basic auth on first colon
docs(helm): point the README guard note at apache#3284