安全性——与客户共享 gearman 工作 ID，不好的做法吗？
我计划将 Gearman 作业服务器合并到我的网站架构中。我计划使用 gearman 来完成的一项任务是通过我的网站进行 Facebook 身份验证。
目前，我允许用户通过 Facebook JS SDK 授权我的 Facebook 应用程序来登录我的网站，在成功进行身份验证后，我通过 AJAX 调用将用户的 access_token 发送到我的服务器，一旦服务器拥有 access_token，它就会查询 facebook Graph API获取当前用户的信息，并相应地设置用户的会话。我想将 facebook API 调用推送到工作线程。
我会将作业发送给 gearman，让 gearman 返回延迟的作业 ID，将该 ID 发送回客户端的浏览器，然后让浏览器以设定的时间间隔（概率 0.5 或 1.0 秒）轮询服务器以查看 API 调用是否已完成通过将作业 ID 返回到服务器并让它检查作业的完成状态。
我的问题是：与客户共享内部职位标识符是否存在安全风险？
I'm planning on incorporating the Gearman job server into my website's architecture. One task in particular that I'm planning on using gearman to accomplish is Facebook authentication with my website.
Currently, I allow users to log into my site by authorizing my Facebook App via the Facebook JS SDK, after a successful authentication I send the user's access_token to my server via an AJAX call and once the server has the access_token it queries the facebook Graph API to get the current user's info and I set the user's session accordingly. I would like to push the facebook API call off to a worker thread.
I would send the job to gearman, have gearman return a delayed job id, send that ID back to the client's browser, and have the browser poll the server at set intervals (prob 0.5 or 1.0 seconds) to see if the API call has completed by returning the job ID to the server and having it check the job's completed status.
My question is: are there any security risks in sharing an internal job identifier with the client?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
共享可能不是问题，但由于用户将 jobDd 提交回服务器以检查状态，因此没有什么可以阻止用户仅更改 jobId 并获取其他身份验证尝试的状态。这可能不是问题（因为您可能不会返回任何其他内容），但您至少会向任何竞争对手泄露一些有关您的应用程序受欢迎程度的信息。
我建议简单地生成一个随机密钥服务器端并将作业 ID 与该密钥相关联，然后使用随机密钥在浏览器和服务器之间进行通信以请求当前状态。
客户端将获取随机密钥，然后使用它来请求当前任务的状态，而客户端和 Gearman 之间的服务器将在数据库中查找密钥，检索实际的 jobId，然后查询 Gearman。
The sharing is probably not the issue, but since the user is submitting the jobDd back to the server to check the status, there's nothing stopping the user from just changing the jobId and getting the state of other authentication attempts. This might not be a problem (as you probably wouldn't return anything else), but you'd be leaking at least a bit of information about the popularity of your app to any competitors.
I'd suggest simply generating a random key server side and associating the job id with that key, then using the random key to communicate between the browser and the server to request the current state.
The client would get the random key and then use that for requesting the state of a current task, while the server acting between the client and Gearman would look up the key in the database, retrieve the actual jobId and then query Gearman.