如何在服务器上使用 SMTP 正确设置 Java Web Applet
我需要一个 Java Web 小程序通过 SMTP 发送自动电子邮件。从编程的角度来看，我对服务器和通信比较陌生。因此，我没有使用 servlet，只是在我的 Web 小程序中运行 java mail api。当我通过 Netbeans 运行它并使用 Glassfish 时，它运行良好。我想将其放在公司的服务器上，以便可以从他们的网站运行。
我知道如何嵌入小程序等，但我不确定电子邮件服务将如何准确工作。据我了解，我需要在服务器的类路径上或小程序运行时在附近的目录中设置适当的 jar 文件（邮件、激活、pop3 等）。我假设该服务器将执行类似于 Glassfish 的操作，因为我可以在 netbeans 之外编译并运行小程序中的所有内容，但当小程序尝试发送电子邮件时会出现 classnotfound/classnotdef 错误。这似乎是由于缺乏类似于 Glassfish 的服务器环境造成的。
同样，我对服务器通信和结构这一领域还很陌生，因此任何有助于介绍的指南都会很有用。除此之外，任何能让事情暂时进展的快速启动建议也将不胜感激。
最后，Glassfish 以及 Apache 和 Tomcat 等其他服务到底为 Netbeans 提供了什么？他们似乎需要在 Netbeans 中开发任何与 Web 相关的内容，尽管我可以在 Netbeans 之外运行小程序（不包括邮件服务），但它实际上在做什么？它是一个模仿完整服务器流程的假服务器吗？我花了几个小时试图了解更多有关这些事情的信息，但我发现的所有这些都没有基本的方法/原因。
感谢您的任何指导。
I need to have a Java web applet send automated emails via SMTP. I am relatively fresh to servers and communication from a programming standpoint. As such, I am not using servlets and am just running the java mail api in my web applet. It runs fine when I run it through Netbeans and am using Glassfish. I want to put it on to a company's server so it can be run from their website.
I know how to embed the applet and such, but I am not sure how the email service will work exactly. From what I understand, I need the appropriate jar files (mail, activation, pop3, etc.) set on the server's classpath, or in a nearby directory while the applet is running. I am supposing this server will do something similar to Glassfish, as I can compile and run everything in the applet outside of netbeans, but get classnotfound/classnotdef errors when the applet attempts to send an email. This would seem due to a lack of a server environment similar to Glassfish.
Again, I am pretty new to this area of server communication and structure, so any guides to help with introductions would be useful. In addition to that, any jump-start advice would also be appreciated to get stuff moving for the time being.
Lastly, what does Glassfish and other services like Apache and Tomcat provide for Netbeans exactly? They seem to be required to developed anything web-related in Netbeans, though I can run applets outside of Netbeans (excluding the mail services), what is it actually doing? Is it a faux server mimicking the processes of a full one? I spent some hours trying to find out more about these things, but there is not a basic how/why for all of this that I have found.
Thank you for any direction.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在JRE可访问的地方。服务器的某些目录禁止小程序（和一般浏览），但 JRE 应该能够从中加载 Jars 的一个位置是与 HTML 相同的目录。这不是最佳解决方案，但它会起作用。
如果您希望使用“最佳”，我会将所有小程序的所有 Jars 放在一个目录中，
/lib（位于根目录的lib目录）公共站点 - mydomain.com -> mydomain.com/lib)。是的。这是使用 applet 元素的
archive属性完成的。请参阅APPLET 标记 了解更多详情。一旦它使用普通小程序元素工作，最好转换为使用 deployJava.js。该脚本对 JRE 进行最小版本检查。但首先要在一台已经具有运行该小程序所需的最低 JRE 的机器上使用
applet元素让它工作 - 它更简单。顺便说一句 - 该小程序需要经过最终用户的数字签名和信任，然后才能将电子邮件发送到其他域的地址。从服务器发送邮件的优点之一是小程序可以被沙箱化，因为它只需要“打电话回家”即可发送信息 - 服务器会完成其余的工作。
你前面有一个陡峭的学习曲线。 ;)
请参阅Applet 可以做什么和不能做什么。
未签名的小程序
未签名的小程序可以执行以下操作：
引用自 Oracle，强调 &我的大胆。做出这个决定的原因之一是因为（当时的所有者）Sun 不希望小程序因跨站点资源请求而名声不佳（我直接从您的站点上提取图像以在我的站点上的小程序中显示它） ）。它被称为热链接，&非常不受欢迎，因为我的网站获得了好处（和访问者），但您的网站正在为资源托管和下载付费。
另一个原因是小程序可能会启动然后通过请求单个资源数千次来攻击站点。获取一个“kewl”小程序游戏，在一千个浏览器中发生这种情况（隐藏在后台），您可能会导致网站崩溃。这称为“拒绝服务”攻击。
因此，Sun 决定，小程序只有获得用户的信任才能跨域，而获得这种信任的唯一方法是开发人员对代码进行签名，JRE 询问用户是否允许它运行，然后用户单击“确定”该提示。
最近，Sun 开始识别 ..cross-domains.xml（或类似的名称）。如果您将这些文件之一放在站点上的正确名称/位置，则可以向 JRE 发出信号，表明可以允许来自其他站点的小程序访问资源（无需用户给予明确的许可） ）。
我怀疑这是否适用于电子邮件，即使邮件发送到的域有适当的文件允许它。但我没有测试过。
In a place accessible to the JRE. Some directories of servers are barred to applets (and general browsing), but one place that the JRE should be able to load the Jars from, is the same directory as the HTML. That is not the most optimal solution, but it will work.
If you wish to go with 'optimal', I'd put all the Jars for all applets in a single directory,
/lib(alibdirectory at the root of the public site - mydomain.com -> mydomain.com/lib).Yes. That is done using the
archiveattribute of the applet element. See The APPLET Tag for further details.Once it is working using a plain applet element, it would be best to then convert to launching using the deployJava.js. The script does minim version checking for the JRE. But first get it working using an
appletelement on one machine that already has the minimum needed JRE to run the applet - it is simpler.BTW - this applet will need to be digitally signed and trusted by the end user, before it can send emails to addresses at other domains. One of the advantages of sending the mail from the server is that the applet could be sand-boxed, since it only needs to 'phone home' in order to send the information - the server does the rest.
You have a steep learnig curve ahead. ;)
See What Applets Can and Cannot Do.
Unsigned Applets
Unsigned applets can perform the following operations:
Quote from Oracle, emphasis & boldness by me. One of the reasons this decision was made, was because (then owners) Sun did not want applets getting a bad name by making cross-site requests for resources (me pulling an image directly off your site to show it in an applet on my site). It is known as hot-linking, & is very frowned upon, since my site is getting the benefit (and visitors) but your site is paying for the resource hosting and the download.
Another reason is that an applet might start up then attack a site, by requesting a single resource thousands of times. Get a 'kewl' applet game with that happening (hidden in the background) in a thousand browsers and you might be able to cause a site to crash. It is called a 'Denial of Service' attack.
So Sun decided that an applet could only reach across domains if it had the trust of the user, and the only way to get that trust is for the developer to sign the code, the JRE to ask the user if they will allow it to run, and the user to OK that prompt.
In recent times Sun started to recognize the ..cross-domains.xml (or called something like that). If you put one of those files at the right name/location on your site, you can signal the JRE that it is OK to allow access to resources to applets from other sites (without the user giving explicit permission).
I doubt that would work for email even if the domain to which the mail is sent, had the appropriate file allowing it. But I have not tested it.