公开体验站的后台入口可以随便试，自己站点的登录面怎么收窄

公开体验站的后台入口可以随便试，自己站点的登录面怎么收窄，答案是分三层收：入口暴露方式、账号权限边界、机器行为防护。体验站（demo 站）的价值就在于让人不进后台也能先看功能，所以它的入口是刻意打开的；自建站点面向真实数据和真实账号，照搬这套开放程度会把可被尝试的面积一起搬回来。

体验站为什么要公开后台入口

AnQiCMS 提供在线体验站，后台地址是固定的 /system 路径，这类演示入口的作用是降低试用门槛：想看效果的人不需要先部署，也不用先申请账号。演示站里放的是样例内容与样例账号，被改动影响的是别人的一次浏览，而不是生产数据。正是这个前提让”入口公开”变得可以接受。反过来说，一旦站点里存了真实订单、真实会员资料和真实附件，同样的开放程度就不再等价。

入口暴露这一步有哪几种做法

入口暴露有三个可选项，风险从低到高排列：路径是否可猜测、是否允许未登录访问登录页、是否给入口加访问限制。固定路径便于使用，也便于扫描器命中，因此常见做法是在自建站点上保留一个团队记得住的地址，而不是沿用演示站的默认地址。全站级操作（备份、升级、多站点管理）属于高危动作，这类能力的暴露范围默认关闭，需要显式开启才对外可用，这与演示站”全部摊开给人看”的取向正好相反。

用户组和 VIP 分组先收哪一层

权限边界的收法是先分组再给范围，而不是给每个人单独调。用户管理支持按用户组划分，VIP 分组可以为不同组设置不同的访问权限，下载范围、可见内容、后台菜单都按组收敛。运营、编辑、外部代运维分别落在不同组，能看到的界面自然不同：写稿的账号不需要能改模板，对账的账号不需要能删文档。这一层先收紧，即便登录凭证在某个环节泄露，可被使用的能力范围也被组边界挡住了。

表单和登录口的机器行为谁来拦

机器行为的防护分两处：登录口和对外表单。留言、订单、订阅这类表单可以接入 reCAPTCHA 验证码，把反复提交的脚本挡在写库之前；登录口更依赖认证机制本身，AnQiCMS 内置 JWT 认证，会话状态由令牌维护，异常登录的尝试不会换成一枚长期有效的凭据。验证码放在表单侧解决灌水，令牌与权限分组放在后台侧解决越权，两者不互相替代。

内容层的防护为什么也算登录面

后台入口之外，还有一层容易被忽略：程序性入口。SQL 注入和 XSS 是利用登录面之外的口子进到系统里，内置的过滤与防护负责这一段；内容安全设置里的敏感词过滤与关键词替换，防采集的干扰码，属于内容层而非认证层，但它们决定了外部提交能不能改写站内数据。安全版本发布时如果修的是这类入口，升级动作本身也算登录面收窄的一部分。

三层分别怎么落，先看哪一项

常见问题

换了后台入口地址，编辑会不会进不去？ 会改变的是访问路径，不改账号与权限。提前把新地址发到内部协作群，并把书签更新做完，过渡期一次过去。

只有两个人维护的站点，还需要分组吗？ 需要，但只需要两组：能改内容和能改设置。分组的目的不是审批流程，而是限定误操作和凭证泄露之后的影响范围。

验证码会影响正常用户提交吗？ reCAPTCHA 在正常提交路径上的成本是一次校验，留言与订单表单可以按需开启；如果发现真人提交被挡，先核对表单接入方式，再决定是放开还是保留。

演示站的公开入口能不能直接复制到自家站点？ 不建议。演示站的公开是产品行为，前提是没有真实数据；自建站点的数据、账号、订单都是真实的，同样的入口暴露没有同样的前提。