feature: enforce account initialization and disable default credentials #7261
Conversation
console/src/main/java/org/apache/seata/console/security/User.java
Outdated
Show resolved
Hide resolved
|
Also, we need to consider how to handle this logic in the build workflow. That's why the workflow below does not terminate. |
I resolved the problem in 78dd208 by adding environment variables during the CI stage. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## 2.x #7261 +/- ##
=========================================
Coverage 55.75% 55.76%
Complexity 7469 7469
=========================================
Files 1178 1178
Lines 41962 41962
Branches 4923 4923
=========================================
+ Hits 23396 23399 +3
+ Misses 16328 16323 -5
- Partials 2238 2240 +2 see 5 files with indirect coverage changes 🚀 New features to boost your workflow:
|
funky-eyes
changed the title
funky-eyes
changed the title
| user.setUsername(username); | ||
| user.setPassword(new BCryptPasswordEncoder().encode(password)); | ||
| public void init() throws IOException { | ||
| String envUsername = System.getenv("SEATA_CONSOLE_USERNAME"); |
There was a problem hiding this comment.
Requiring users to read credentials (username and password) directly from environment variables would impose significant changes to their workflow and create a poor user experience. Instead, we can default to a predefined username (e.g., seata) and remove any default password. If no password is configured, the system will automatically generate a random password, log it for user reference, and notify them:
"No password was configured. A random password has been generated for security purposes. You may either:
- Use the auto-generated password (see logs for details), or
- Set a custom password in the configuration."
This approach ensures backward compatibility while guiding users toward secure practices.
There was a problem hiding this comment.
Requiring users to read credentials (username and password) directly from environment variables would impose significant changes to their workflow and create a poor user experience. Instead, we can default to a predefined username (e.g., seata) and remove any default password. If no password is configured, the system will automatically generate a random password, log it for user reference, and notify them:
"No password was configured. A random password has been generated for security purposes. You may either:
- Use the auto-generated password (see logs for details), or
- Set a custom password in the configuration."
This approach ensures backward compatibility while guiding users toward secure practices.
Thank you for your comment!
As you pointed out, suddenly requiring users to provide credentials would lead to a poor user experience.
Following your suggestion, I will implement it so that if no password is set in the YAML configuration file, the system will generate a random password, log it, and provide guidance to the user.
There was a problem hiding this comment.
Done in a02be95 !
There was a problem hiding this comment.
The modified result is now being logged as shown below!
22:56:58.549 INFO --- [ main] [y.CustomUserDetailsServiceImpl] [ init] [] : No password was configured. A random password has been generated for security purposes. You may either:
1. Use the auto-generated password: [424e287f]
2. Set a custom password in the configuration.
|
The problem currently occurs only with JDK 17, and I'm in the process of analyzing it. The most likely cause at this point appears to be a compatibility issue between |
See #7329 |
Ⅰ. Describe what this PR did
fix #6396
Ⅱ. Does this pull request fix one issue?
Ⅲ. Why don't you add test cases (unit test/integration test)?
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews