有没有其他人认为Silverlight 4安全性有点麻烦?
请看以下情况:
换句话说,为什么所有关于Silverlight安全的大惊小怪,实际上阻碍了真正的业务用例,何时可以使用COM访问任何文件?
换句话说,如果用户运行恶意Silverlight应用程序,他们不太可能会说 - 哦,这是COM的错。 COM之后被一个Silverlight应用程序调用了。
这就是我的意思....
在我看来,Silverlight安全模型存在缺陷,要么它们应该让开发人员完全信任并允许我们像在本地运行一样运行应用程序
或
不允许Silverlight访问COM。
只是我,还是其他任何人都认为这是一个糟糕的实施?
这会触发安全警报:
OpenFileDialog flDialog = new OpenFileDialog();
FileInfo fs = flDialog.File;
string fileName = fs.FullName;
这不是
dynamic fileSystem = AutomationFactory.CreateObject("Scripting.FileSystemObject");
fileSystem.CopyFile(anyFileName,anyDestination);
答案 0 :(得分:2)
我不同意你的观点。您可以执行安装的COM对象允许您执行的任何操作的事实是不是修改大量现有Silverlight代码以允许您执行相同操作的理由。
为什么呢?因为在打开代码的过程中,当Silverlight组件未以受信任模式运行时,以某种非预期的方式运行相同代码的可能性也会增加。如果这种情况发生,即使一旦媒体全身心投入,Silverlight的声誉也可能是不公平的,也可能会破坏。
我个人非常满意MS对Silverlight采取非常谨慎的安全措施。
答案 1 :(得分:1)
某些Silverlight控件(如OpenFileDialog)在受信任和不受信任模式下都可以工作。这些控件已从以前版本的Silverlight中移植,其中新级别提升信任不是考虑因素。
感谢Anthony指出这一点。
开发人员需要了解我们在此讨论的信任定义。使用提升的权限以完全信任方式运行Silverlight应用程序与运行本地Silverlight基于Windows的应用程序不同。它也比ActiveX更具限制性。
Silverlight中提供的信任可能适合您的特定业务需求。然而,在某些情况下,您会发现Silverlight过于严格,最好是事先进行研究,并运行代码示例以确保您可以在完成任务之前完成重要工作。
答案 2 :(得分:1)
Microsoft保证公共Silverlight API对于Windows和MacOS平台都具有相同的行为。因此,功能在很多方面受到共同点和技术可行性的限制。请将COM introp视为仅针对Windows平台且仅在完全信任模式下的特定情况,并且对于其他平台不会起作用。因此,安全限制是有效的,因为它们在API重用方面对于两个世界都是相同的。
答案 3 :(得分:0)
我同意原始海报。我认为这是不好的实施。我们有一个内置的对话框来浏览文件,包括目录结构。我们可以选择一个文件并获取一个FileInfo对象,但安全性阻止我们获取FullName(目录和文件名)。为什么?这如何提高安全性?打开文件对话框的重点是什么?
正如原始海报提到的那样,对于那些动态对象,我们可以修改本地文件系统......这似乎是可能的安全漏洞。
我想要做的就是从excel文件中读取一些数据......我的用户可以将excel数据导入到应用程序中,并且文件可以保存在他们机器的任何位置。这些销售代表使用excel文件在本地记录订单,直到他们可以进入互联网连接。谁知道他们在哪里保存该文件...所以我不打算建议我们告诉他们所有人将它存储在“我的文档”中的相同位置。如果我建议,我会被嘲笑。
看起来应该非常简单。但是,使我们无法从内置的打开文件对话框中获取用户所选目录的“安全措施”使得我们无法将该对话框用于其创建目的。
那么替代方案是什么?有没有办法使用这些动态对象选择文件?我是否必须使用可以修改文件系统的对象编写自己的文件选择工具?因为除了读取文件之外我什么也不需要,因为我在某处读到了我们可以访问文件流的内容...是否有办法使用文件流打开文件以便使用AutomationFactory进行读取?