如何最好地实现简单的崩溃/错误报告?

发布于 2024-07-04 09:25:57 字数 294 浏览 7 评论 0原文

实现简单的崩溃/错误报告机制的最佳方法是什么?

详细信息:我的应用程序是跨平台(mac/windows/linux)并用Python编写的,所以我只需要一些能够向我发送少量文本的东西,例如时间戳和回溯(我已经生成并显示在错误对话框中)。

如果它可以简单地通过电子邮件发送就好了,但我想不出一种方法来做到这一点而不在应用程序中包含 smtp 服务器的用户名和密码... 我是否应该在服务器端实现一个简单的 Web 服务,并让我的应用程序向其发送包含信息的 HTTP 请求? 还有更好的想法吗?

What would be the best way to implement a simple crash / error reporting mechanism?

Details: my app is cross-platform (mac/windows/linux) and written in Python, so I just need something that will send me a small amount of text, e.g. just a timestamp and a traceback (which I already generate and show in my error dialog).

It would be fine if it could simply email it, but I can't think of a way to do this without including a username and password for the smtp server in the application...
Should I implement a simple web service on the server side and have my app send it an HTTP request with the info? Any better ideas?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

复古式 2024-07-11 09:25:58

某种简单的网络服务就足够了。 您必须考虑安全性,这样不是任何人都可以向您的服务发出请求。

在更大的范围内,我们考虑了 JMS 消息传递系统。 将包含回溯/错误消息的序列化数据对象放入队列中,并每 x 分钟使用它,从该数据生成报告/警报。

Some kind of simple web service would suffice. You would have to consider security so not just anyone could make requests to your service..

On a larger scale we considered a JMS messaging system. Put a serialized object of data containing the traceback/error message into a queue and consume it every x minutes generating reports/alerts from that data.

找个人就嫁了吧 2024-07-11 09:25:57

无论您使用 SMTP 还是 HTTP 发送数据,您都需要在应用程序中拥有用户名/密码,以防止任何人向您发送随机数据。

考虑到这一点,我怀疑使用 SMTP 而不是 HTTP 来发送数据会更容易。

Whether you use SMTP or HTTP to send the data, you need to have a username/password in the application to prevent just anyone from sending random data to you.

With that in mind, I suspect it would be easier to use SMTP rather than HTTP to send the data.

辞取 2024-07-11 09:25:57

网络点击是最佳选择,但请确保选择一个好的 URL - 您的应用程序将在未来几年内点击它。

The web hit is the way to go, but make sure you pick a good URL - your app will be hitting it for years to come.

梦里人 2024-07-11 09:25:57

如果不在应用程序中包含 smtp 服务器的用户名和密码,我想不出一种方法来做到这一点...

您只需要用户名和密码来向智能主机验证自己的身份。 您不需要它直接发送邮件,您需要它通过中继(例如您的 ISP 的邮件服务器)发送邮件。 完全有可能在没有身份验证的情况下发送电子邮件 - 这就是垃圾邮件如此难以阻止的原因。

尽管如此,一些 ISP 会阻止端口 25 上的出站流量,因此最可靠的替代方案是 HTTP POST,它不太可能被任何东西阻止。 请务必选择一个以后不会受到限制的 URL,或者更好的是,让应用程序定期检查更新,这样,如果您决定更改域或其他内容,您可以提前推送更新。

安全并不是真正的问题。 您可以相当容易地丢弃垃圾数据,因此您真正关心的是是否有人会费尽心思构建虚假的回溯来扰乱您,而这是一种非常不可能的情况。

至于有效负载,PyCrash 可以帮助您。

I can't think of a way to do this without including a username and password for the smtp server in the application...

You only need a username and password for authenticating yourself to a smarthost. You don't need it to send mail directly, you need it to send mail through a relay, e.g. your ISP's mail server. It's perfectly possible to send email without authentication - that's why spam is so hard to stop.

Having said that, some ISPs block outbound traffic on port 25, so the most robust alternative is an HTTP POST, which is unlikely to be blocked by anything. Be sure to pick a URL that you won't feel restricted by later on, or better yet, have the application periodically check for updates, so if you decide to change domains or something, you can push an update in advance.

Security isn't really an issue. You can fairly easily discard junk data, so all that really concerns you is whether or not somebody would go to the trouble of constructing fake tracebacks to mess with you, and that's a very unlikely situation.

As for the payload, PyCrash can help you with that.

寒江雪… 2024-07-11 09:25:57

Web 服务是最好的方法,但有一些注意事项:

  1. 您应该始终询问用户是否可以发送错误反馈信息。
  2. 如果出现网络错误,您应该准备好优雅地失败。 不要让未能报告崩溃而妨碍恢复!
  3. 您应该避免包含用户识别信息或敏感信息,除非用户知道(请参阅#1)并且您应该使用 SSL 或以其他方式保护它。 某些司法管辖区给您带来了您可能不想处理的负担,因此最好不要保存此类信息。
  4. 与任何网络服务一样,请确保您的服务不会被不法分子利用。

The web service is the best way, but there are some caveats:

  1. You should always ask the user if it is ok to send error feedback information.
  2. You should be prepared to fail gracefully if there are network errors. Don't let a failure to report a crash impede recovery!
  3. You should avoid including user identifying or sensitive information unless the user knows (see #1) and you should either use SSL or otherwise protect it. Some jurisdictions impose burdens on you that you might not want to deal with, so it's best to simply not save such information.
  4. Like any web service, make sure your service is not exploitable by miscreants.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文