kusica+SCQL项目邀请成员后，查询邀请列表，返回值为乱码

[zwj-edas]

Issue Type

Running

Have you searched for existing issues?

Yes

OS Platform and Distribution

centos7

SCQL Version

SCQL.0.90b

What happend and What you expected to happen.

kusica+SCQL创建项目，邀请成员后，查询邀请列表，返回值为乱码，无法看到邀请Id

Configuration used to run SCQL.

curl -X POST http://127.0.0.1:80/intra/invitation/list \
--header "host: scql-broker-intra.alice.svc" \
--header "kuscia-source: alice"

SCQL log output.

乱码

[1139763082]

看下您服务器的编码格式

[zwj-edas]

请问是哪个服务器

[zwj-edas]

而且在sqllite上查询，邀请id是从1开始的自增字段，请问是否还有改进计划？

[zwj-edas]

看下您服务器的编码格式

其他接口返回都是正常的，只有/intra/invitation/list接口返回乱码

[tongke6]

不是乱码，因为请求为空，且未设置请求的 content-type，无法识别请求的编码格式，默认按 protobuf wire 格式返回了。

可以给请求 body 设置成 "{}"，或者设置请求的 content-type 为 "application/json"

[tongke6]

而且在sqllite上查询，邀请id是从1开始的自增字段，请问是否还有改进计划？

有什么顾虑吗？

[zwj-edas]

不是乱码，因为请求为空，且未设置请求的 content-type，无法识别请求的编码格式，默认按 protobuf wire 格式返回了。

可以给请求 body 设置成 "{}"，或者设置请求的 content-type 为 "application/json"

这个问题解决了，谢谢！

[tongke6]

而且在sqllite上查询，邀请id是从1开始的自增字段，请问是否还有改进计划？

有什么顾虑吗？

太简单了吧，安全上有考虑么

太简单并不是一个安全隐患，你担忧的安全问题是什么呢？

[zwj-edas]

而且在sqllite上查询，邀请id是从1开始的自增字段，请问是否还有改进计划？

有什么顾虑吗？

安全角度来讲，是不是太简单了？

[tongke6]

从安全角度来看，得给出攻击方式才能说是有问题，而不是说这个方式简单就有问题。

[zwj-edas]

从安全角度来看，得给出攻击方式才能说是有问题，而不是说这个方式简单就有问题。

数据库自增主键可能产生的问题包括：

1、插入数据时可能存在并发问题。如果多个线程同时插入数据，可能会导致主键冲突，从而导致插入失败。 2、主键值的增长可能会导致性能问题。当数据库表中的数据量非常大时，自增主键的值也会非常大，可能会导致索引、查询等操作变慢。 3、主键值的增长可能会导致空间浪费。当数据库表中的数据被删除时，自增主键的值并不会回收，导致主键列的值空间被浪费。 4、主键值的增长可能会暴露业务信息。自增主键的值通常是连续的，可以通过简单的递增计算来推测出表的数据量和插入顺序，可能会暴露敏感的业务信息。 5、主键值的增长可能会导致数据迁移问题。当数据库表需要进行数据迁移或导出时，自增主键的值可能会导致数据迁移或导出的问题，需要额外处理。

[tongke6]

@zwj-edas 首先点赞你良好的安全意识。

不过是否存在问题，也得结合场景看。

InvitationID 只对自己这一方可见和有效，代表己方收到的一个项目邀请，会给共享给其他参与方。因为 intra 接口应只对域内暴露，其他方无法访问到此接口，没有暴露业务数据的问题。每一方的 invitation id 都是隔离的，也不会有并发冲突问题。

从隐私计算项目创建邀请来说，它的业务量一般都不会太大，非高频操作，也不太会有增长值空间浪费的问题。

[github-actions[bot]]

Stale issue message. Please comment to remove stale tag. Otherwise this issue will be closed soon.