[GH-ISSUE #321] app费解

kerem commented

2026-03-03 11:42:11 +03:00

Owner

Originally created by @roiding on GitHub (Sep 20, 2025).
Original GitHub issue: https://github.com/Finb/Bark/issues/321

我不太理解，从技术角度上为什么app不能自己编辑key呢，一定要去生成，彼此不认识的人不能通过一个推送地址集中收到推送嘛

Originally created by @roiding on GitHub (Sep 20, 2025). Original GitHub issue: https://github.com/Finb/Bark/issues/321 我不太理解，从技术角度上为什么app不能自己编辑key呢，一定要去生成，彼此不认识的人不能通过一个推送地址集中收到推送嘛

kerem closed this issue

2026-03-03 11:42:11 +03:00

kerem commented

2026-03-03 11:42:12 +03:00

Author

Owner

@Finb commented on GitHub (Sep 21, 2025):

如有特殊需求可自行修改后端源码

https://github.com/Finb/bark-server

@Finb commented on GitHub (Sep 21, 2025): 如有特殊需求可自行修改后端源码 https://github.com/Finb/bark-server

kerem commented

2026-03-03 11:42:12 +03:00

Author

Owner

@roiding commented on GitHub (Sep 22, 2025):

如有特殊需求可自行修改后端源码

https://github.com/Finb/bark-server

这不是后端代码的问题吧涉及到app 我用的cf，因为后端有register、ping、healthz等等的生命周期函数啊，app处添加的服务器地址如果带上key的话，后端的param1，2，3就不好判断了。这需要app端修改下代码吧？我不太熟swift，晚上拿ai看看能不能改改，最好是app的添加处把后端服务器必填，key选填，这样不影响生命周期函数

@roiding commented on GitHub (Sep 22, 2025): > 如有特殊需求可自行修改后端源码 > > https://github.com/Finb/bark-server 这不是后端代码的问题吧涉及到app 我用的cf，因为后端有register、`ping`、`healthz`等等的生命周期函数啊，app处添加的服务器地址如果带上key的话，后端的param1，2，3就不好判断了。这需要app端修改下代码吧？我不太熟swift，晚上拿ai看看能不能改改，最好是app的添加处把后端服务器必填，key选填，这样不影响生命周期函数

kerem commented

2026-03-03 11:42:12 +03:00

Author

Owner

@Finb commented on GitHub (Sep 22, 2025):

register 第一次不会携带key ，只会携带apns token。由服务器生成key。服务器保存 key-token 对应关系。
之后每次打开APP都会重新调用 register ,携带服务器返回的 key 和最新的 apns token，接受服务器返回的新key并更新key（如果key未改动则不变）

你要做的功能可以参考上面的逻辑响应的修改，APP应该不需要动

@Finb commented on GitHub (Sep 22, 2025): register 第一次不会携带key ，只会携带apns token。由服务器生成key。服务器保存 key-token 对应关系。之后每次打开APP都会重新调用 register ,携带服务器返回的 key 和最新的 apns token，接受服务器返回的新key并更新key（如果key未改动则不变）你要做的功能可以参考上面的逻辑响应的修改，APP应该不需要动

kerem commented

2026-03-03 11:42:12 +03:00

Author

Owner

@roiding commented on GitHub (Sep 22, 2025):

register 第一次不会携带key ，只会携带apns token。由服务器生成key。服务器保存 key-token 对应关系。之后每次打开APP都会重新调用 register ,携带服务器返回的 key 和最新的 apns token，接受服务器返回的新key并更新key（如果key未改动则不变）

你要做的功能可以参考上面的逻辑响应的修改，APP应该不需要动

仔细看了一下好像的确如此，那还想咨询个问题：我好像在readme还是哪里看到过一个情况。同icloud账号下的不同设备因为icloud同步，key就会天然一致，从而会产生2个设备有两个token都可以推送到。那么这样的话现在cf-workers的代码其实是一个key对应一个token，这个icloud的多token又是如何实现的呢？求解。数据库中应该最终也只有一条token记录啊

@roiding commented on GitHub (Sep 22, 2025): > register 第一次不会携带key ，只会携带apns token。由服务器生成key。服务器保存 key-token 对应关系。之后每次打开APP都会重新调用 register ,携带服务器返回的 key 和最新的 apns token，接受服务器返回的新key并更新key（如果key未改动则不变） > > 你要做的功能可以参考上面的逻辑响应的修改，APP应该不需要动仔细看了一下好像的确如此，那还想咨询个问题：我好像在readme还是哪里看到过一个情况。同icloud账号下的不同设备因为icloud同步，key就会天然一致，从而会产生2个设备有两个token都可以推送到。那么这样的话现在cf-workers的代码其实是一个key对应一个token，这个icloud的多token又是如何实现的呢？求解。数据库中应该最终也只有一条token记录啊

kerem commented

2026-03-03 11:42:12 +03:00

Author

Owner

@roiding commented on GitHub (Sep 22, 2025):

另外我看worker的代码中是有BasicAuth这个字段预留的，意味着支持鉴权，但是貌似好像现在app没地方可以配置这个吧

@roiding commented on GitHub (Sep 22, 2025): 另外我看worker的代码中是有`BasicAuth`这个字段预留的，意味着支持鉴权，但是貌似好像现在app没地方可以配置这个吧

kerem commented

2026-03-03 11:42:12 +03:00

Author

Owner

@roiding commented on GitHub (Sep 22, 2025):

register 第一次不会携带key ，只会携带apns token。由服务器生成key。服务器保存 key-token 对应关系。之后每次打开APP都会重新调用 register ,携带服务器返回的 key 和最新的 apns token，接受服务器返回的新key并更新key（如果key未改动则不变）

你要做的功能可以参考上面的逻辑响应的修改，APP应该不需要动

抓包看了下，第一次请求是register?deviceToken=XXXX&key=。首先咨询下，deviceToken在苹果那边是会不定时变更的是嘛，还是说一个设备的deviceToken是固定的，因为我看每次register其实都根据key去更新了token的。如果token会一直变，那群组推送的确就没法实现了，因为一个群组哪些token失效了，我服务端是不可能知道的。另外因为app的register肯定是在我输入的服务器地址后进行params的叠加，所以假设我要建立一个叫group1的群组，使用了https://xxxx/group1作为服务器地址，我岂不是所有的url params解析其实都要后移一格，同一个设备我现在能理解的是key一定是永远一样的，那其实app端可以自定义key是最方便的。这样register就是带key和params上去的以及BasicAuth最好是app端可以配置，这样push的权限就控制住了，否则url暴露，谁都可以push了。

@roiding commented on GitHub (Sep 22, 2025): > register 第一次不会携带key ，只会携带apns token。由服务器生成key。服务器保存 key-token 对应关系。之后每次打开APP都会重新调用 register ,携带服务器返回的 key 和最新的 apns token，接受服务器返回的新key并更新key（如果key未改动则不变） > > 你要做的功能可以参考上面的逻辑响应的修改，APP应该不需要动抓包看了下，第一次请求是register?deviceToken=XXXX&key=。首先咨询下，deviceToken在苹果那边是会不定时变更的是嘛，还是说一个设备的deviceToken是固定的，因为我看每次register其实都根据key去更新了token的。如果token会一直变，那群组推送的确就没法实现了，因为一个群组哪些token失效了，我服务端是不可能知道的。另外因为app的register肯定是在我输入的服务器地址后进行params的叠加，所以假设我要建立一个叫group1的群组，使用了https://xxxx/group1作为服务器地址，我岂不是所有的url params解析其实都要后移一格，同一个设备我现在能理解的是key一定是永远一样的，那其实app端可以自定义key是最方便的。这样register就是带key和params上去的以及BasicAuth最好是app端可以配置，这样push的权限就控制住了，否则url暴露，谁都可以push了。

kerem commented

2026-03-03 11:42:12 +03:00

Author

Owner

@roiding commented on GitHub (Sep 22, 2025):

我感觉我还是单独写一个程序作为中转吧，把一个群组的key都存在一个外置程序群组里吧。不然不太好操作，现在其实key就是设备id，因为devicetoken会变的话。但是那个BasicAuth还是希望app端可以完善下

@roiding commented on GitHub (Sep 22, 2025): 我感觉我还是单独写一个程序作为中转吧，把一个群组的key都存在一个外置程序群组里吧。不然不太好操作，现在其实key就是设备id，因为devicetoken会变的话。但是那个BasicAuth还是希望app端可以完善下

kerem commented

2026-03-03 11:42:12 +03:00

Author

Owner

@Finb commented on GitHub (Sep 23, 2025):

BasicAuth 是用于发送端鉴权，不用于APP
bark-server 已经支持 BasicAuth 了

@Finb commented on GitHub (Sep 23, 2025): BasicAuth 是用于发送端鉴权，不用于APP bark-server 已经支持 BasicAuth 了

kerem commented

2026-03-03 11:42:12 +03:00

Author

Owner

@roiding commented on GitHub (Sep 23, 2025):

@Finb 所以默认权限就是注册不需要权限，查询和推送需要权限是吧。ok，理解了

@roiding commented on GitHub (Sep 23, 2025): @Finb 所以默认权限就是注册不需要权限，查询和推送需要权限是吧。ok，理解了

Rows
Columns

[GH-ISSUE #321] app费解 #283