能否为nodewarden管理界面设置一个隐藏地址，如:https://nw.xxx.org/panel-back

[vimbackground]

安全需求，虽然加上二次认证已经很安全了，但还是不希望有人找到管理后台。

如果能为send功能绑定一个与管理后台不同的域名更好，谢谢。

[Evenjine]

安全需求，虽然加上二次认证已经很安全了，但还是不希望有人找到管理后台。

如果能为send功能绑定一个与管理后台不同的域名更好，谢谢。

正想说呢，像send这样的功能bitwarden不应该出的，加密软件不应该玩「高大全」，最好专一，安全比什么都重要。建议shuaiplus取消这个功能。send项目也很多，大家可以另外独立部署。

[shuaiplus]

关闭前端页面，关闭send，两个按钮，马上加上

[Zhuoershang]

关闭前端页面，关闭send，两个按钮，马上加上

大佬厉害！！！ 一波更新攒了个大的。完美

[tan9710630]

安全需求，虽然加上二次认证已经很安全了，但还是不希望有人找到管理后台。
如果能为send功能绑定一个与管理后台不同的域名更好，谢谢。

正想说呢，像send这样的功能bitwarden不应该出的，加密软件不应该玩「高大全」，最好专一，安全比什么都重要。建议shuaiplus取消这个功能。send项目也很多，大家可以另外独立部署。

对于这两位的观点我有一些不同的意见仅供大家讨论哈：

1. Send功能其实无法真正"独立"

技术上有个关键问题：Send的链接要能正常工作，客户端必须能访问web-vault的资源来解密数据。也就是说，就算给Send配了独立域名，该暴露的前端资源还是得暴露，攻击者照样能通过这些资源推断出服务端信息。所谓的"隔离"只是表面上的，实际安全收益很有限。

2. 隐藏管理后台≠真正安全

子路径用工具几分钟就能扫出来，这是基础攻击手段。真正的安全应该依赖认证（2FA、IP限制、失败次数限制），而不是依赖"藏起来"。

3. Send的主要使用场景被误解了

大部分用户用Send是跨设备同步消息，不是对外分享。这是Bitwarden官方客户端的标准工作流，取消这个功能会直接破坏与官方客户端的兼容性。作为兼容服务端，保持功能完整性很重要。

4. Send本身的安全机制已经足够

端到端加密、过期时间、访问密码、最大访问次数限制——这些安全机制都在。风险主要来自用户配置不当，应该通过文档引导用户正确配置，而不是取消功能。

[shuaiplus]

我当初添加隐藏前端功能是因为当时的前端只是一个help页面，但现在的前端已经是一个完整的web vault了，有导入导出功能，云端备份功能。所以我不支持隐藏前端这个想法，前端页面已经够安全了

[tan9710630]

我当初添加隐藏前端功能是因为当时的前端只是一个help页面，但现在的前端已经是一个完整的web vault了，有导入导出功能，云端备份功能。所以我不支持隐藏前端这个想法，前端页面已经够安全了

附议，我也是这个观点

[vimbackground]

安全需求，虽然加上二次认证已经很安全了，但还是不希望有人找到管理后台。
如果能为send功能绑定一个与管理后台不同的域名更好，谢谢。

正想说呢，像send这样的功能bitwarden不应该出的，加密软件不应该玩「高大全」，最好专一，安全比什么都重要。建议shuaiplus取消这个功能。send项目也很多，大家可以另外独立部署。

对于这两位的观点我有一些不同的意见仅供大家讨论哈：

1. Send功能其实无法真正"独立"

技术上有个关键问题：Send的链接要能正常工作，客户端必须能访问web-vault的资源来解密数据。也就是说，就算给Send配了独立域名，该暴露的前端资源还是得暴露，攻击者照样能通过这些资源推断出服务端信息。所谓的"隔离"只是表面上的，实际安全收益很有限。

2. 隐藏管理后台≠真正安全

子路径用工具几分钟就能扫出来，这是基础攻击手段。真正的安全应该依赖认证（2FA、IP限制、失败次数限制），而不是依赖"藏起来"。

3. Send的主要使用场景被误解了

大部分用户用Send是跨设备同步消息，不是对外分享。这是Bitwarden官方客户端的标准工作流，取消这个功能会直接破坏与官方客户端的兼容性。作为兼容服务端，保持功能完整性很重要。

4. Send本身的安全机制已经足够

端到端加密、过期时间、访问密码、最大访问次数限制——这些安全机制都在。风险主要来自用户配置不当，应该通过文档引导用户正确配置，而不是取消功能。

有理有据，表示支持