I would like to know if there is any way to launch a local application with silverlight. I'm having some security problems doing this with a user control embedded in IE 8, so I would like to convert this into silverlight app. This little issue is stopping me to go forward with silverlight, so if any suggestion, I would appreciate to hear it.
Thanks in advance..
Carlos.
This will be, theoretically possible, using COM interop with Silverlight OOB in SL4, but you will still have the same security issues, and in addition, add some deployment issues.
In order to do this directly from within IE, you'll need to make an add-in that gets installed with proper security permissions. Any "automatic" model for this would violate the standard IE security policies, so there is no direct means of getting from browser->local system.
this would totally invalidate Silverlight security model. So, good luck with that. Pretty sure you can not do it. This is what officially is known as a "Bad Thing."
Things I learned from Jurassic Park: Just because you CAN do something doesn't mean you SHOULD do something.
It is absolutely possible to get "Out of Browser" support using Silverlight 4. But what you need to do in order to access applications on the "Host" machine is the certify the SL4 application as being trusted.
This will involve getting a certificate for it. This could be obtained from CA (or similar for Internet applications) OR you could generate your own certificate for Intranet use and have the users simply install it or have it installed via another automated sys admin style process.
The bottom line is that when the SL4 application is running OOB AND it is trusted, it can access anything on the host machine; to a point.
Even though you can have file access and so forth, you still cannot call the application directly. That is unless it's installed as a COM object.
So what you will need to do is invoke the application using the "script" host COM object. You create a reference to the Script host and then simply pass in the command (and parameters if you like) that would invoke the application.
Hey presto, you broke the wall :-)
It should be noted that the use will still only be able to run the applications on their machine that they are currently allowed to. So you won't be able to invoke Admin tools on a user with limited control.
See here for details
http://msdn.microsoft.com/en-us/library/dd550721(VS.95).aspx
It seems to me that you ought to post a question about the developement of the user control you already have. Ultimately no matter what technology you use you will need to get the user to opt-in manually. Silverlight when hosted by a browser is designed to live in nice and secure sandbox that it can't get out of. It isn't the answer to your problem in this case.
Your Silverlight application should be a trusted application because it runs on a browser.
If you want to launch an application in your local machine use the below code:
AutomationFactory.CreateObject("WScript.Shell").Run(FilePath);
Use the namespace System.Runtime.InteropServices.Automation
Related
So, i'm building my first SL application.
I tried to use the MVVM approach, and I think that's the way for me.
Basically, it's a simple application which shows data to the user, the data source is local (maybe in the future will be centric, but right now this is not the case), and the data should be retrieved by:
A. Calling file system's reading
and
B. Method calls from External DLLs
So, as I said, I started to work with MVVM (used this tutorial). I have 3 components: the service, the SL application and the project that host the SL app (excuse me if i'm not using the exact proffecional terms...).
My question is: Do you think that I've chose the right design? if so, is there any way not using IIS to host the service or is it a must? (I don't want to spend time on adminastrative tasks on clients' computers), because as I said, the data is local at the moment and IIS feels unnecessary.
I'll appriciate every comment on this. Thanks!
EDIT:
I'll try to simplify my question: I need my SL app to communicate with some kind of service - that will be able to take requests and reply back to the app.
This service suppose to be able to use .net dlls, and this service should be locally on each client run the app.
EDIT:
I noticed the Self host option.
Does anyone has any experience with it?
If your question is about: You having access to a database server somewhere, you should try WCF RIA Services. This will allow you to create service for each entity and the service will get included into your host project or you can even create a WCF RIA library.
As suppose to your MVVM pattern. I prefer splitting my Views from my ViewModels In different projects. I like to see them as a seperate layer.
Actually using ria services may mean that you have a number of services which apply to one user, but yes they are specific to the user. Which file system would you be attempting to access? The client or the server?
I finally decided to go with XBAP(WPF XAML Browser Application).
It suited perfectly to my requirements:
1. no deployment issues - just press a link, and .net enviroment will do the rest (downloading the needed assemblies, install them and finally run the app)
2. it's hosted on a browser
3. no IIS is needed!! it's a client-only application
Creating an OOB with silverlight is very easy and I think it is a good thing.
However, it is also easy to create an application that require higher privilege and with only one click, a user can "allow" the program to do everything on his computer.
Am I correct?
Am I correct to feel we are gone back to IE 6's days when executing a harmful activex was so easy?
"Desktop" .Net framework use a Code Access Security to reduce the threat perimeter. Does SL too?
Silverlight implements many mitigations to make this less scary than you think it is.
OOB apps are, by default, sandboxed - so most of them should have no more permissions than an app in-browser would have.
OOB apps (on Windows) intentionally restrict their security token when launching, so even if launches as an admin, they strip themselves of admin rights and re-launch (sllauncher.exe does this, the app has no say in it).
There is a registry key that can be set at the HKLM level that allows administrators of, say, corporate networks to disallow all installations of OOB apps, or to disallow only the installation of (or running of) Trusted Applications. So, with a little group policy, the user can't even run these if they want to - compared to an EXE, which they surely can run under their own security context.
Silverlight OOB is not an alternative for Web Apps but for Desktop Apps.
And SL does use the same CAS as Fx4 (which is a little less than Fx 35 and before).
So it is certainly not worse than the alternatives, with the potential to make it safer.
Trusted Silverlight OOB App on Windows should be considered as dangerous as EXE. That is because with little help from COM interop it can download EXE file to the user's computer and execute it.
Check out Silverlight security whitepaper for some extra information: http://download.microsoft.com/download/A/1/A/A1A80A28-907C-4C6A-8036-782E3792A408/Silverlight%20Security%20Overview.docx
I've seen several posts that essentially state that UI components shouldn't run as a service. I understand the rational that no one can respond to UI events etc. But the fact remains that are are many automation tasks that are only possible with Windows forms.
Here is a couple of great examples:
I would like to build a url crawler
service that makes thumbnails of
webpages. Currently the only way I
see to achieve this is to try and
automate the .Net WebBroswer
component.
Automate the printing of MS-Word
docs.
Pre-Vista there was some tricks to get around this, but now there is none. My question is why is this the case, and what alternatives does one really have?
Lookup Shatter Attacks and Session 0 Isolation Feature.
Basically if two processes (of different users) share the same desktop, one process can potentially execute whatever code it wants in the other process by sending windows messages, and this was called a Shatter Attack.
There was a lot of discussion whether this was a design bug or not, and post Vista, Microsoft decided to remove any interactive desktop support for services as that was a potential security hole.
As an alternative, you can consider, running your image generation/printing code as a logged in user, who has access to an interactive desktop.
Like Moron said best thing to do is not run it as a service.
But perhaps you're stuck running it from a service anyway, because there is an existing framework of some sort that you're needing to run your code from.
So the workaround to that would be to write a server program that runs as a logged in user. You will hit that server program from your code the must be in a service. The server will do the work and return the results.
You can communicate between the 2 using WCF over named pipes as the transport, or whatever works. If that doesn't, you can use bare named pipes, or, tcp/ip on the localhost. Judging from your website in your userprofile, you should know all about localhost!
Technically, UI components requires started Windows Message Queue to work. You can run it from windows service (may be with allowed Interaction with Desktop, as far as I know this feature is disabled in Windows Vista and higher).
But things you are talking about is not UI components, it is COM components, and you can use it. At least MS Office, but it is not recommended by Microsoft, because memory leaks are possible. Latest MS Office has server edition, that can be used in application without user interface.
I am in the design stage of an application that must be both a standalone app & a web application (To save the costs of building 2 near identical applications twice). Basically I have opted to go for a silverlight OOTB application that will be installed on the standalone machines and they will write to a collection of files in the sandbox and occasionally talk to the server version. The same application (with a little configuration) will also operate on the webserver and store its data in a database.
I am however more of a WPF developer so I would like to cover some concerns I have before I go too far down this path...these are:
I hear you can pass a file out for the user to 'Save As' in their browser when using SL normally. Is there similar functionality with OOTB? Because I want to be able to save some of the local files to locations other than the sandbox (With user permission)?
Is is possible to configure OOTB to allow access to the filesystem outside of the sandbox?
Is there a way to programatically determine whether a silverlight application is running in OOTB mode (So I know what mode the application should be running in)?
Are there any major flaws in my ideas so far that would prevent this from being a possibility?
Silverlight 4 will provide support for out of browser trusted applications, which have more privileges that a normal sandboxed application but still not as much as a regular desktop application. Regarding file access, a trusted application will be able to access to some predefined folders such as MyDocuments, MyMusic, MyPictures, MyVideos, but not the entire filesystem. See here for details: http://mtaulty.com/CommunityServer/blogs/mike_taultys_blog/archive/2009/11/18/silverlight-4-rough-notes-trusted-applications.aspx
As for how to know whether you are running out of browser or not, use Application.Current.RunningOffline.
Finally, I recommend you to take a look at PRISM. Among other things, it eases the task of sharing code between WPF and Silverlight, so you could consider developing a dual SL+WPF application.
Apart from the fact people get to view the app in a browser which may be familiar. Is there any actual compelling reason to use the XBAP model in WPF rather than a straightfoward stand alone WPF app.
All I can see are potential security issues and restrictions but no benefits. Am I missing something?
I have used an XBAP, once.
We needed full-trust, and we needed the application to act as if it were browser hosted. XBAP was the only real option we had, and I'm glad it was there.
Outside of this tiny nitch, Silverlight & Click Once are better all around options.
In practice No and No would be the answers to your questions. I have never actually seen them used in production nor is there ever really a justified reason to use them.
As Kent mentioned Silverlight or Click Once is almost always a better option.
One could argue, in a full trust Windows only environment, XBAPS gives you the ability to leverage the full WPF framework with the flexibility of web deployment. Of course that is what Click once is for. However, in my experience ClickOnce is a nightmare for anything more then a simple, single application install so you might argue in favor of XBAP to avoid ClickOnce headaches.
But again, my response would be, Silverlight is likely a better choice.
We use it to have a single sourced solution for an application that can run in a browser but also as a desktop application. Both full trust.
Actually a modular designed app consisting of xbap(s) communicating via webservice is very efficient. This type of scenario would allow for execution of the modular pieces to run concurrent and in separate memory spaces. This benefits the user and the application's developer(s).
The app would not run in an ie but rather a custom browser shell to control the flow and execution of the application itself. It does seem like a lot of work when everything could simply run with in a single or multiple projects but this type of solution would be pertinent in large enterprise app(s). The application Programmer(s) will be able to work on segments or distinct parts of the app which contain distinct functions, utilities, and capabilities. The user never knows or realizes that each part is actually running independently because it appears seamless. The partial trust issue is eliminated because the shell is not an xbap and has full permission. Now to the good stuff ... if there happens to be a fault (that never happens right?) other parts of the application continue to execute without failure. Try-catch-finally work great until you miss one... Last but not least no more complicate background thread processing it's in a browser and by default is async. Most systems will have multiple windows open at a time each window simply contains a browser running an xbap. Unique...Yes...Useful...Yes... It is a different approach but it is clean and simple.
Life is a race ... When you reach the finish line who will be there cheering for you and will you be proud of the race that was run?
XBAPs using Partial Trust are useful if you have a requirement that the WPF client should be run without requiring admin privileges and without installing anything on the clients machine (disregarding the user's profile cache that is)
I was thinking the same thing, here is my takeaway.
The main reason is the user experience, WPF apps are more powerful and easier to write than Silverlight. People will click on a web site, but will think twice about installing an application. An XBAP is very close to a website experience, and can out perform Click Once and Silverlight.
However since it only works for a very narrow user base, it would probably be best for intranet applications.
WPF, XBAP, Silverlight - What do I use?