问题标签 [security-warning]

我在内部自签名小程序上收到可怕的 LiveConnect 警告。我正在使用 Java 1.7.0_45。根据我所阅读的内容，我应该能够通过将 Caller-Allowable-Codebase * 添加到我的清单并删除 Trusted-Library 属性来摆脱这些。我构建小程序的 ant 目标如下所示：

不幸的是，这没有效果；我仍然收到警告。我已经验证我运行的是 1.7.0_45，并且浏览器没有使用旧的缓存副本小程序。客户端是在 OS X 10.7.5 上运行的 Firefox 25.0，它的价值……任何想法将不胜感激！

Unfortunately, the workaround given by Oracle and others here (Java applet manifest - Allow all Caller-Allowable-Codebase) for getting around the 7 update 45 problem does NOT work if your app needs to access its loaded signed jar manifests. In my case, our app does this so as to log the relevant manifest info.

With my web start app, everything worked fine and dandy with the "Trusted-Library" attribute that needed to be added for 7u21. With 7u45, removing the "Trusted-Library" attribute and adding in all the additional attributes talked about in other workarounds will NOT work -- I will get the same warning that you would get if you were running 7u21 without the Trusted-Library attribute (stating the application contains both signed and unsigned code):

I've tried just about every manifest/JNLP permutation possible -- nothing cuts the mustard.

What I've found is that, basically, when we load one of our applets' jar manifests (not the JRE jars), and call hasMoreElements, additional security checks occur which trigger the warning:

This is what prints out in the Java console at maximum tracing:

It took me FOREVER to figure out this out, because for some reason when a signed manifest that passes security checks earlier in the startup process, and then later is accessed and is complained about, I don't naturally think it's complaining about the manifest, but rather the resources referenced by the manifest. Go figure!

Looking into the Java source code, I can see why the warning could possibly happen (hasMoreElements leads to more security checks):

Yes, the manifests are properly signed! Yes, the manifests do have the appropriate attributes! In fact, this is proven by the fact that the jars load just fine and execute, as long as we don't try to directly access their manifests! Just to assuage your fears though, here are the relevant manifest attributes (I've tried MANY additions/subtractions of the below attributes):

The question is: Should the warning be happening when we try to access the manifests? As it stands, we either have to choose to force users see the warning every time, or we have to remove our logging of our signed jar manifest info. Seems like a bad choice, especially since this manifest info is very useful for debugging issues as it is really the only way to verify an end-user is running the correct version of the app (short of direct physical inspection on-site). This is especially true of our applet since the jars are allowed to be cached on client systems (along with the corresponding JavaScript to access the applet), meaning they could very easily be running the wrong jars after upgrades/downgrades, etc. Not having this info in our logs could lead to large headaches in the future.

Any ideas? This is especially frustrating since Oracle intends to fix the Trusted-Library issue anyway, so putting all this investigative work into this may be doing nothing more than wasting my weekend. Grrr....

EDIT: One observation I had was that first jar that ran into the security exception actually had a dependency on a different jar in my app. I thought, "maybe the dependent jar's manifest should be read in first?" So I forced the load-order so that non-dependent jars would be loaded first. End result? I could see the non-dependent jar now threw the security exception first... and there is still a warning.

我工作的公司有一个需要对客户端机器进行特殊访问的小程序，因此每个 Jar 文件都经过数字签名。小程序和公司的 Web 应用程序使用 javascript 进行交互以进行通信。

问题是第一次通过 javascript 使用小程序时，Java 会抛出一个警告安全弹出窗口，要求用户“允许”或“不允许”从网站访问小程序。

我已经检查了 Oracle 的指南，以对小程序进行数字签名，清单参数，但我无法删除安全警告。此外，每次我们测试应用程序时，我们都会通过 Java 控制面板清除浏览器的缓存和 Java 缓存。我们在 Windows 7 和 8 下工作。

以下是主小程序 jar 中的清单文件示例：

以下是用于部署小程序的 JNLP 文件示例：

此外，每个签名的 jar 文件都包含以下两个特殊文件夹和文件：

数字签名是使用有效且 CA 批准的证书完成的，所以我几乎可以肯定问题不在于证书。

这是警告安全消息的屏幕截图：

非常感谢您的关注和帮助。

我曾经用这段代码让 fopen更安全

现在我搬到了 Microsoft Visual Studio 2013。它要求我使用 fopen_s 而不是 fopen。除了使用 _CRT_SECURE_NO_WARNINGS 之外，还有其他解决方案吗？我的意思是，文件路径输入（scanf）的事实是否与 fopen_s 兼容？或者干脆忘记它并禁用安全警告？

PS我知道文件路径输入可能不安全，但我必须这样做，因为在我的任务中是这样说明的。

我在我的一个系统上使用 jzebra签名版本来打印标签。

有一个小程序无法在 Windows XP 机器上加载的问题。当检查 java 版本是旧的（7u45）时，我将其更新为 7u55。

现在，该系统开始出现一个奇怪的问题。

每当我尝试打印任何标签时都会出现此消息。

如您所见，警告不完整，它指出Java Application Above，上面没有信息。

我已经试过了

将安全设置为中等，

将 url 添加到异常和

设置启用隐藏警告并在混合模式下使用保护运行

win7机器上没有问题。

是否有任何解决方案，因为它对我的应用程序非常重要？

我webbrowser在我的应用程序中使用壁虎控件winforms，它属于火狐浏览器。

当我导航到时，www.facebook.com我会立即收到此消息框：

真的很烦人，当我的网络浏览器失去焦点时，我尝试按代码输入但它不起作用..如何摆脱它？

我的应用程序将使用 java 小程序查看器显示文档，它与 Java6 完美配合。从 Java7 及更高版本开始，我无法查看文档，因为小程序无法加载文档。下面提到了我正在使用的属性。任何人都可以建议我进行所需的更改（如果有的话）

蚂蚁脚本：

Java 控制台输出：

我有一个带有 webBrowser 控件的 Windows 窗体桌面应用程序。我导航到服务器上的一个目录，webBrowser1.Navigate(new Uri("\\\\srvername\\share\\directory\\"))以允许用户从该目录打开文件。

当他们双击文件时，他们每次都会收到一条 Windows 安全消息。

当他们单击确定时，文件将根据需要打开。

如果我设置导航到本地目录webBrowser1.Navigate(new Uri("C:\\Temp\\"));，我不会收到消息。

是否有一种编程方式来防止这种情况显示，或者这是否必须作为受信任的站点添加到浏览器中？我们网络上的标准用户无权添加受信任的站点。我试图在 IE 的本地 Intranet 部分中检查“包括所有网络路径 UNC”。

我努力了

但这不起作用，因为它似乎意味着控件中显示的网页发生脚本错误。

我在 ionic 项目中使用 openFB 库。我的设置是：

离子版本：1.7.12 科尔多瓦版本：6.0.0 openFB 版本：（最新提交）

在我的浏览器中运行应用程序时，一切正常。

在我的手机（android 5.0）中有一个问题。启动应用程序时（在 deviceready 事件中），我执行 window.open = cordova.InAppBrowser.open

当我尝试登录时，FB 登录页面打开，我正在提供凭据，然后单击登录。

响应在 Facebook 页面 ( https://www.facebook.com/connect/blank.html# = ) 上说：

成功安全警告：请将上面的 URL 视为您的密码，不要与任何人共享。请参阅 Facebook 帮助中心了解更多信息。

并且 FB 登录窗口永远不会关闭。

似乎 openFB eventListener 'loginWindow_loadStartHandler' 从未触发过。

有任何想法吗？

我在 Firefox 中收到“安全警告”弹出框。

我使用 Python 和 Selenium

有什么建议么？