覆盖了其他项目的配置项

[netkey]

今天突然发现有一个appid（假设为app-a）的某个配置项被变动了但是并没有发布，修改人为另外一个项目（假设名为app-b）的所有者（app-b-user），app-b-user对app-a并没有权限。看历史操作记录，此时间点app-b-user对app-b做了修改，但是在app-b的修改历史记录中看到的key却是app-a中被修改的那个key（这个key在app-b中并不存在）。

求查该问题根源的思路，目前看日志没有发现异常，在数据库中看到Commit表中的操作记录，该条操作记录的 ChangeSets字段中记录的原始namespaceId和key都是app-a的，但是AppId、ClusterName、NamespaceName 这几个字段都是app-b的。

目前觉得异常的地方是提交的这个键值是很大一长串的json格式的数据，里面包含有空格、tab和换行符之类的隐藏字符。是否这个原因导致了异常？

[nobodyiam]

版本信息提供一下？另外是否可以问下这位用户，他当时做了什么操作？

[netkey]

apollo版本是1.6.1，由于是十多天后才发现这个问题，之前的操作日志都已经覆盖掉了，询问这位用户也只是说操作了自己这个项目的配置，另外那个项目他没有权限不可能去更改。

[nobodyiam]

能否根据这个key查一下Item表中对应在app-a和app-b中的记录，然后根据ItemId查一下AUDIT表？

[netkey]

这个key在Item表中app-a是有这个key的，app-b中不存在这个key，其他app有这个key；app-a对应的ItemId为3705

查询Audit表中也能看到这个Itemid存在被app-b-user修改的记录

[nobodyiam]

这个前一段时间在 #3341 中修过一个可能存在问题的点，传入的 appId, cluster, namespace 和 item dto 的内容对不上，不过这个正常操作应该是不会产生的

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in 14 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it has not had activity in the last 7 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted". Thank you for your contributions.

[huayaoyue6]

@nobodyiam 看来这个问题跨越的版本挺多的，1.5.1也有这个问题。#2592 这个issue估计也是相同的问题。

[nobodyiam]

@huayaoyue6 可以升级到新版本 apollo 看下，#3341 防御性的修了下

[huayaoyue6]

这个问题估计是js的bug导致的。类似 #3196 这个问题。

db说明：

1. 不同环境的Namespace/Item都是自增的。
2. 不同环境中的Namespace/Item中的总数不相同。
3. 之前版本的更新Item的逻辑是不判断namespace与item的关联的。

下面两个是根据数据反推出的结论：

不同环境切换的时候，不慎将正式的item的id提交的测试环境上了，即id是非当前环境的id。直接根据item的id更新，所以导致了此问题的发生。

#3341 这个pr加了对namespace的判断逻辑。应该会起作用。

你可以根据db的数据来检查一下上面的结论是否正确。
下面是操作：

• 查找到这条错误的数据，然后查看当天操作人（app-b-user）的操作记录。重点关注操作时间前后的数据。
• 如果操作人（app-b-user）比较仔细的话，发现修改没有生效（因为修改到app-a中了），就会再次修改的。这样的话就能找到要修改的记录的真实的“目标id”。
• 拿被误修改的item的id去别的环境中的item表中查找，会发现id的key和上条说的“目标id”的的key是相同的 。或者拿“目标id”去别的环境中的item表中查id，与被误修改的id相同。

这些操作也都记录到了Commit表中。

如果你把db的数据跑一下，可能会发现这种情况已经发生多次：

1. 从Audit表中查EntityName="Item"的记录，记录下操作者和EntityId。
2. 从Item表中查EntityId的值为第1步的EntityId的记录，查找到NamespacId的值。
3. 从Namespace中查Id的值为第2歩的记录，查找到AppId。
4. 从用户权限表中查第1步的操作者有没有第3步的App的权限即可。

[huayaoyue6]

我发现的原因是这样的：

实现的自定义登录的时候处理的不周全。用户信息使用自定义的oa单点登录。用户信息失效的时候被拦截，会返回302，重定向的login，然后自动重新登录。 打开DEV页面后长时间未操作，用户信息失效了，再点击切换到PROD的环境的时候发出的加载数据的ajax会被302重定向登录，此时PROD的数据没有被重新加载，但是页面上的Env切换了，即页面在PROD环境上，但是数据却是DEV的数据，再更新的时候就会导致此类问题。我的处理方案是拦截的时候判断不是页面及mediatype为applicaiton/json的请求，如果是的话直接返回403。

我看#3341 中增加了防御性的逻辑，判断了关联的namespace是否一致的逻辑，但是文本修改的话可能也会遇见相同的问题。