What causes "{}" in elunez/eladmin?

Re-save the email config through the admin UI so the password is DES-encrypted by the normal save path (it encrypts with EncryptUtils before persisting).

elunez/eladmin · error · BadRequestException

{}

Error message

{}

What it means

This is BadRequestException(e.getMessage()) rethrown from the catch block around EncryptUtils.desDecrypt(emailConfig.getPass()) while assembling the hutool MailAccount in EmailServiceImpl.send. The '{}' message means it is a pass-through of the underlying decryption exception's text — typically hutool's CryptoException ('decrypt error...' or 'InvalidKeyException: Invalid key length') when the stored password cannot be DES-decrypted with the fixed key.

Source

Thrown at eladmin-tools/src/main/java/me/zhengjie/service/impl/EmailServiceImpl.java:82

    @Override
    @Transactional(rollbackFor = Exception.class)
    public void send(EmailVo emailVo, EmailConfig emailConfig){
        if(emailConfig.getId() == null){
            throw new BadRequestException("请先配置，再操作");
        }
        // 封装
        MailAccount account = new MailAccount();
        // 设置用户
        String user = emailConfig.getFromUser().split("@")[0];
        account.setUser(user);
        account.setHost(emailConfig.getHost());
        account.setPort(Integer.parseInt(emailConfig.getPort()));
        account.setAuth(true);
        try {
            // 对称解密
            account.setPass(EncryptUtils.desDecrypt(emailConfig.getPass()));
        } catch (Exception e) {
            throw new BadRequestException(e.getMessage());
        }
        account.setFrom(emailConfig.getUser()+"<"+emailConfig.getFromUser()+">");
        // ssl方式发送
        account.setSslEnable(true);
        // 使用STARTTLS安全连接
        account.setStarttlsEnable(true);
        // 解决jdk8之后默认禁用部分tls协议，导致邮件发送失败的问题
        account.setSslProtocols("TLSv1 TLSv1.1 TLSv1.2");
        String content = emailVo.getContent();
        // 发送
        try {
            int size = emailVo.getTos().size();
            Mail.create(account)
                    .setTos(emailVo.getTos().toArray(new String[size]))
                    .setTitle(emailVo.getSubject())
                    .setContent(content)
                    .setHtml(true)
                    //关闭session

View on GitHub (pinned to 55fbf70595)

Solutions

Re-save the email config through the admin UI so the password is DES-encrypted by the normal save path (it encrypts with EncryptUtils before persisting).
Check email_config.pass value in DB: it must be the encrypted ciphertext, not the plaintext SMTP password.
Verify the full ciphertext survived any DB migration (no truncation — column length).
Look at the wrapped exception in logs to confirm whether it is key-length/block-size related versus charset corruption.

Example fix

// before
try {
    account.setPass(EncryptUtils.desDecrypt(emailConfig.getPass()));
} catch (Exception e) {
    throw new BadRequestException(e.getMessage());
}

// after: clearer diagnostics while keeping config value untouched
try {
    account.setPass(EncryptUtils.desDecrypt(emailConfig.getPass()));
} catch (Exception e) {
    log.error("DES decrypt of email password failed; re-save email config", e);
    throw new BadRequestException("邮箱密码解密失败，请重新保存邮箱配置");
}

Defensive patterns

Strategy: try-catch

Validate before calling

// detect an unusable stored password before send
EmailConfig config = emailService.find();
boolean passLooksEncrypted;
try { EncryptUtils.desDecrypt(config.getPass()); passLooksEncrypted = true; }
catch (Exception e) { passLooksEncrypted = false; }
if (!passLooksEncrypted) { throw new BadRequestException("邮箱密码无效，请重新保存邮箱配置"); }

Try / catch

try { emailService.send(emailVo, config); } catch (BadRequestException e) { // passthrough message: log it, and if it mentions decrypt/key, force re-saving email config rather than retrying } }

Prevention

Only write email_config.pass via the admin save flow (it DES-encrypts); never via SQL.
After upgrades or migrations, re-save email config once to re-encrypt the password.
Log the passthrough message server-side; the client message alone is often ambiguous.

When it happens

Trigger: Any email send (verification code, admin send-email tool) after config was saved, where email_config.pass was stored in a format that isn't DES-encrypted with EncryptUtils' expected key — e.g. plaintext password saved by an older version or entered manually into the DB, or data migrated/ truncated.

Common situations: Upgrading eladmin versions where the pass encoding changed; someone editing email_config.pass directly in the database to plaintext; multi-byte/special characters in the password breaking DES block alignment; config row written by an external tool bypassing the encrypt step.

Related errors

AI-assisted analysis of elunez/eladmin@55fbf70595 (2026-08-14). Data as JSON: /api/errors/be8773eca0c099f2. Report an issue: GitHub.