Just an R&D question. We need to develop an application that can be run in a browser that has the capability of performing some system checks to gather support information to be emailed to us. These checks will include basic system information, but also will need to scan the filesystem and pull out version information about various DLLS, executables, and .NET assemblies that might be installed. The idea being that we can direct a client to a page and have the application gather the relevant information needed for support, and potentially even populate some database fields. We need it to have as small a footprint as possible.
I've worked with ActiveX before, and know it is capable of these things, but particularly on modern systems security is a nightmare to get around, with a lot of people blocking ActiveX altogether. Is Silverlight easier to deliver to clients? Does it have a lighter footprint? Is it even capable of doing these things?
Silveright has access to isolated storage, but I don't think it can do what you are looking for (I may be wrong). As for footprint, if I remember correctly, the runtime is reasonably small, and the .xap packages are limited to 4Mb.
Silverlight out-of-browser has access to the file system. http://msdn.microsoft.com/en-us/library/dd550721(v=vs.95).aspx#special_features_for_outofbrowser_applications
If you intend to run your app in the browser, you will still have to configure the trust as if it where oob. http://msdn.microsoft.com/en-us/library/gg192793(v=vs.95).aspx
However, iTunes has a neat way of doing something somewhat related. It has a custom protocol (itms://) that allows the browser to invoke a client side program (iTunes). Then you can embed html in a webpage that passes parameters as command line arguments to that app. The website also knows if the iTunes is installed by a cookie. We this in mind, you might be able to encourage your users to install some small app that setups the custom protocol on install. You could pass command-line parameters to it from the web, and the app will push information from the client back to the server.
To create a real-time experience, you could use sockets + more javascript to update the page with the info you just got off the machine.
HTH,
Silverlight runs in a pretty restricted silo and can't do a lot of low level things - such as checking the file system. So I would say it does not fit your use case, unfortunately.
Related
In a nutshell, my project consists of:
A secure RESTful API web service (hosted on Heroku), handling requests/responses for a database. It accepts & returns JSON data
A Unity desktop application, which doubles as a Twitch API chat bot, and communicates with the webservice to update the state of the game, as well as the state of the database.
IMPORTANT: This game is meant to be run by Twitch streamers, and played by users in Twitch chat
So my question is... Even though my web service is secure, what can I do to ensure that someone won't simply reverse engineer my Unity application to figure out how to properly communicate with my web server?
Encrypted HTTP traffic stops packet sniffing, but is a moot service if you can still use the same methods the application uses to interact with the data. Perhaps I'm being too paranoid, but there are plenty of tools out there that specifically target Unity & C# projects, so it really wouldn't take much effort.
One idea I had was to use the Twitch API to check if the user is actively streaming the game, and only allow them to start the game if the web service can't find a duplicate IP address in the database with an "isStreaming" flag set. This works in theory... but in practice, anyone can set up a fake Twitch account and a fake or "blank" stream on their machine, and then run some reverse-engineered code from the game.
Is there anything else I could do to minimize a hacker's ability to interact with my database?
The Simple Answer
Unity-compatible Code Obfuscation
Thanks to Unity's plugin system, there are actually some decent options for this. Some are paid options that exist in the Asset Store, as well as some 3rd party paid/free options that are simply unrelated to Unity (but could still work). Some of the free options, such as ConfuserEx, are also open source, allowing you to make custom code changes to how your work can be obfuscated.
The More Complex Answer
I made a simple C# Class Library and filled it with some pointless functionality (for testing)
I compiled a release build of the library
I obfuscated it through ConfuserEx using Aggressive settings (Maximum settings had Unity spitting out Invalid IL code errors)
I added an Assets/Plugins folder to my Unity project, and placed the compiled library there
I created a new C# script to test the library from within Unity
... And although the decompiled code was unintelligible, it still worked as expected within Unity. I used an IL/C# decompiler tool (such as JustDecompile) to compare the differences between the obfuscated binary and the original binary.
So if I really wanted to, I could follow these very same steps for all of my important bits of code (or even for the majority of my client project), as well as implementing any aforementioned security measures... And so hopefully, it's now going to be too much of a chore for anyone to understand the inner-workings of my project.
I just heard that a company I do work for may be bringing in the Pyxis Mobile application development system. When I google it most of what I find is from the company's web site and that is not very informative from a geek perspective. Can any one shed some light on what sort of programming environment it is and what programing language is involved (please let there be a text based language). Any additional information would be great.
Note: the company/product changed their name to Verivo in January.
Full Disclosure - I work as an engineer at Pyxis Mobile. However, I have been in the mobile space for 7+ years and have evaluated several approaches to mobile so hopefully this is helpful.
Pyxis Mobile provides a set of tools and components to build cross platform mobile applications. Let me outline them first.
1. Application Studio - All application development, backend integration, user provisioning and application maintenance/debugging is done w/in this tool. Application Studio (for now) is a Windows based desktop app.
2. Application Clients - Pyxis Mobile provides native client runtimes for iPhone, iPad, BlackBerry, and Android devices. These runtimes get branded for the customer through a build service and are primed to point to a specific Application Server URL.
3. Application Server - Pyxis Mobile App Server runs on the .NET stack (on IIS). All client communication is proxied via this server. This server is able to connect to varied of backend systems (via the Plugin Framework listed below) and respond to the client in a mobile optimized manner. This server needs a SQL Server (2005 or newer) for configuration access, session management, logging and more.
4. Plugin Framework - The Plugin Framework is a backend component that provides system specific pre-built access to several of the enterprise and cloud based systems (Oracle, Siebel, SAP, Salesforce.com, social feeds, REST/SOAP web services, etc.) and also offers an API layer in .NET and Python (using IronPython) to allow even further customization. A plugin is essentially comprised of one or more DLLs or a Python file. These assets are then dynamically loaded to normalize communication between Pyxis Mobile and the customers' backend systems.
5. Push Services - This provides a cross-platform push layer that can poll a backend system for change and alert a mobile device via BlackBerry Push, Apple Push Notification Services (APNS) or Android's Cloud to Deice Messaging (C2DM).
6. OverWatch Analytics - This is an optional (but included) component to track users/devices and provide integrated analytics on what the users are using and what kind of devices and locales makes up your users.
The application itself is "coded" via configuration that is build in App Studio. Pyxis Mobile abstracts away from the code so that you can work at a higher level without having to worry about the wide array of device variances (GPS, touch screens, camera, accelerometer, push, screen resolution, etc.). You can drag fields onto a from, connect screens via menus or buttons, set up caching rules and more in this graphical utility. This configuration (essentially think of an XML like document) is interpreted by the native client layer to produce a rich application. There is also a scripting layer in Lua that allows to really customize behavior via code.
The real value of Pyxis Mobile comes up when you have change to make. The clients check for new configuration at app startup or if the server forces the client to get new configuration. This gives you great agility. Lets say once your application is deployed you want start using the swipe gesture to go next/prev through a set of records. This change on other platforms would mean writing some platform specific code to trap and interpret the swipe to perform a navigation (you couldn't trap a swipe on a non-touch screen). However, in Pyxis Mobile this is a simple configuration change that can be quickly deployed to the App Server and the clients automatically download and use the new configuration. No compilation, no redeployment or re-download for the end users.
I could keep going, but hope this provides some level of guidance.
Beware of Pyxis Mobile. While many of the things they say do work, there are some serious platform issues (as a geek) which I've experienced.
1) No version control system process. The Application studio can basically only be developed on by one person at a time or you risk having your changes overwritten by a fellow developer. The "principle of last save" is very much in play.
2) No unit test coverage. This isn't the biggest issue for a lot of people, but it's a concern for anyone who wants to work in the Enterprise world.
3) The middleware server gets you some value, but it's also a PITA to work with. There is no concept of "client side storage" unless you consider the middleware server the client side. If your phone goes out of coverage, your app won't work. Again, this might not be an issue for you.
4) The application has no true scripting language to work with. The middleware server allows you to intercept requests and responses and modify what you're doing there, but it's not the most elegant solution considering that a native application can have something as simple as "if this then X else Y." This can be accomplished with Pyxis, but the whole process is convoluted and more complicated than one would think it needs to be.
5) Lack of documentation. There's some training guides and the GUI is easy enough to get around for simple apps; however, when you need to do something with guts, you're left relying on Pyxis professional services. There's really no developer community to pose questions to.
I have more complaints, but they are more opinion oriented than Q/A oriented.
I just got note about the most recent comments. I don't want to turn this into a thread of back and forth, but did want to throw a couple of quick notes.
Regarding the points on version control and documentation/developer community - no big contest there. We are definitely working on these shortcommings. We have some basic pieces in place, but we have big plans to focus on this.
Regarding unit testing - we provide a very open interface to our middleware and backend components and they can be very easily unit tested with a bit of instrumentation. We run a ton of unit and integration tests internally. However, mobile unit testing is extremely difficult to get right. We'll investigate this further.
Regarding #4 around middleware and offline capabilities - things are a lot different now. With version 7.1, 7.2 and 7.3 our products have increasing become more capabale offline and now features a secure local database if necessary. I can provide more details as necessary, but you can certainly login and operate the app even if you are out of coverage for weeks at a time!
Regarding #5, we've had a scripting engine for over 2 years. Its Lua based and its actually quite powerful and fast. It was BlackBerry only till the most recent release. Given Apple's change of stance on allowing scripting we now allow scripting on BlackBerry, iPad, iPhone and Android as well now!
#RockMeetHardplace - feel free to reach out to me directly and I'll be happy to give you more detailed live demos of our latest platform. I am at - arunSPAMNOTatpyxismobiledotcom (drop the "SPAMNOT" and replace the at and dot). I happen to be the Director of Software and interested in knowing more about the issues you had.
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.
I'm building a new Silverlight app for a photography studio. I was about to say "you have to have a Windows-based server hosting it" and then I thought, wait is that right? Looks like it's not. So I could point him toward a Linux host.
I know you have to register the MIME types (from a different SO thread). Are there any other caveats or gotchas that I need to know about? Assume for a second that I know next to nothing about Linux.
Edit: what if the app needs to talk to a database (mySQL)? Seems like I'd need to have Moonlight to get that going, which isn't gonna fly.
The only thing you have to do is ensure the web server delivers the correct MIME type for the .xap (which is application/x-silverlight-app). That's it.
There is nothing blocking you to host a Silverlight app(Client Plug-in) in any webserver on any platform.
Silverlight is client technology. There is nothign (but MIME types) that are required to host on non-MS servers. But if you have server-side code (e.g. web services or REST API's talking to your mySQL db), that server-side technology would need to work on Linux. That's completely separate from Silverlight. You might want to do the server stuff with Java or PHP (or other Linux-friendly platform) but Silverlight doesn't care what it talks to and can be served in a non-MS platform easily.
Regarding your edit (on mysql) -- no you would not need Moonlight (as that is client only as well). You'd need to expose your database functionality through a service layer of sorts as Shawn notes.