I currently spike with WiX 3.11.2 to build a burn bootstrapping application that downloads packages from a local http server currently without any authentication.
Due to a lack of documentation of WiX burn I mostly reverse engineered how to set the UpdateLocation + how to check for updates via skimming through the UpdateViewModel.cs from the Wix3 repository.
As far as I have read, the
Engine.SetDownloadSource(ea.PackageOrContainerId,ea.PayloadId, dlUrl,user,pass);
can be used to download with no AUTH (last 2 parameters null) or plain authentication. Without authentication I already have a working prototype - but I will need the possibility to authenticate against a OAUTH secured web server.
If I were to need for instance to download behind a OAUTH2 authentication would the best practice be to use the OnResolveSourdce Event and instead of setting the Result to Result.Download, just do it myself with OAUTH2 libraries and download it to the ea.LocalSource so the engine basically thinks that the source has always been already available?
My second question is with regards to the UpdateLocation.
In the OnDetectUpdateBegin event I can set the ea.Result to Result.Ok if I want to check for upates - but I would like to be able to change the UpdateLocation during runtime, similar to what the Visual Studio Installer allows - to have different ReleaseFeeds, something like PROD or TESTING or Preview.
is there any possiblity to tell the Engine to set the UpdateLocation to a different URI? It would seem that the OnDetectUpdateBegin event would be perfect to change that, but the ea.UpdateLocation only has a Get, and I did not find a Engine.SetUpdate location or anything similar.
If I am not mistaken the VStudio installer is also built upon WiX so I would presume it should be somehow possible - am I missing something here?
Related
we are developing an application with a Helper Tool - which is installed into the system using SMJobBless. This works as expected; but there is a caveat.
We do frequent automatic deployments - sometimes more than one per week. Everytime the Helper Tool version changes, we re-register it - causing a password prompt. These 2 factors would quickly become irritating to our users.
Is there a way to have the password prompt appear only once, during the initial Helper Tool installation? Could subsequent updates happen without a prompt? Perhaps there is a way to leverage the existing Helper Tool to install a newer version of itself?
Short answer: No. SMJobBless() always prompts for admin credentials. There's no way to stop it from prompting. If you call this API, it'll prompt (or fail).
Longer answer on workarounds:
If your helper tool is running with admin/root privileges, it could theoretically replace itself with a new version. Think very carefully before doing this. Getting this right and maintaining security is very difficult, and the fact that even the major OSes have had vulnerabilities in installer functionality is a strong indicator that the risks of going this route may outweigh the benefits.
If you must proceed, read up on:
Race Conditions, Secure File Operations, and Time of Check vs Time of Use
Apple's Security APIs, particularly SecRequirementCreateWithString and SecCodeCheckValidity.
macOS Code Signing In Depth and the Code Signing Requirement Language
You would have to ensure that your helper tool cannot be tricked into replacing itself with (or executing) malicious code, or you will have opened your software up to being a trivial root exploit vector.
Also note: Regardless of what Apple currently does to verify helper tools installed by SMJobBless, it is conceivable that they could tighten the requirements in the future and refuse to run helper tools that have been modified since they were installed via SMJobBless. The safest method (in multiple respects) is to just call SMJobBless whenever you need to install/update the helper.
So I have this bit of a project planned for Windows Store and Android. Basically, a networking multi-tool coupled with a scripting engine to implement protocols and behavior. Ideal uses being things like "my embedded device uses this simplistic network protocol. I'd like to quickly prototype a way to control it from my tablet".
It's my understanding that the Android market should have no problem with this. However, the Windows Store policy includes a vague clause concerning remote code execution
3.9 All app logic must originate from, and reside in, your app package Your app must not attempt to change or extend the packaged content
through any form of dynamic inclusion of code or data that changes how
the application interacts with the Windows Runtime, or behaves with
regard to Store policy. It is not permissible, for example, to
download a remote script and subsequently execute that script in the
local context of your app package.
Of course, the scripting engine will be sandboxed and such and should be "safe"(completely intepreted, no reflection), but does it violate this policy?
If you build in your scripting engine, and only run local scripts, you will be good. However, if you were thinking to have a repository of scripts that could be downloaded and subsequently run, that would be in violation of the policy as we understand it.
Unfortunately I don't think anyone but someone on that team can answer that (or someone with direct experience in that) because of the closeness to the legal language. Have you tried the Windows Store Appl Publishing forum at: http://social.msdn.microsoft.com/Forums/en-US/windowsstore/threads
In the context of scripting engine example given, unless the app modifies the scripting engine after deployment on user's system such that the representation of protocol/behavior (the script artifact's format) is made to change then it'll be policy violation. Its as if you submit Python interpreter, and at some point in time it abruptly moves onto interpreting ecmascript.
I am attempting to write a small, lightweight client, using vb.net winforms, that can install without needing elevated privileges. Before I ask my questions, let me give you a bit of an idea of what it is supposed to do.
The app will start when Windows loads, set like this from the install, with a system/notification tray icon that can be clicked on to load up specific functionality. The application install from a website, or possibly a file share, haven't quite decided yet. This client will initially request user credentials for one of our web programs, and it will talk to an already built web service to determine what functionalities of our services they have licensed access to. After this, credentials will be encrypted and saved to the users pc locally. Every five minutes, the client will pass the credentials to the websites they have access to and check to see the status of jobs that are being processed, and download available reports if needed.
So, here is what I am trying to understand. If I configure this app as a ClickOnce application, once it installs from the url or shared drive, the user will not need to do anything else, correct? Or do they have to visit that url every time they boot up to reinstall/run the client?
Another thing, I wanted to get some opinions on the best ways to do some of the things this app will be doing. I have a good idea of where I am going with it, but I have no idea of which solution to go with yet.
For instance, what is the best way to store user passed credentials on their system for a "remember me"?
Also, is the best way to have the client install with automatically starting on windows startup to configure it to create a shortcut of itself in the windows startup folder?
I am trying to keep this as lightweight as possible, and using a very small GUI, so it shouldn't be too intrusive, so any ideas on how to ensure that, while keeping it from needing admin privs to install, will also help.
If I configure this app as a ClickOnce application, once it installs
from the url or shared drive, the user will not need to do anything
else, correct? Or do they have to visit that url every time they boot
up to reinstall/run the client?
Well if they need to reinstall it, they would have to download the setup.exe file again, but why would users need to do that? CilckOnce supports automatic updates. Visiting url is certainly not needed for running the program.
what is the best way to store user passed credentials on their system
for a "remember me"?
Probably storing them as application settings. Haven't used visual studio 2012, but in visual studio 2010 you have to right-click on project in solutions explorer, go to project propeties and then create variables in Settings tab. Then you can access those variables in code using My.Settings.variableName. Not sure about security though, if you need any.
As for privileges, I think you just need a privilege to install a program. Maybe you should publish a primitive clickOnce application and experiment with it and that will answer all your other questions about clickOnce.
I'm in the process of installing an open-source Python based web application to an internal server here at work. The existing code is open - it doesn't require a login to view it - but one of the requirements is that users have to be approved before they can see anything.
Is there a good way (using Apache configuration files for example, but any method would be great) to wrap the application so that any access requires a login? I would like to avoid modifying the open-source code (a maintenance nightmare every time a new release comes out).
Any thoughts or suggestions?
Apache supports Authentication, Authorization and Access Control.
It is a detailed process, and summarising it here would not do it justice. I refer you to the link provided,
There was a challenging situation happened when i was working with install to provide product key validation. I had to use C++ unmanaged code to validate the key. Actually we had the main validation logic written in C# and I had to create a mixed project. Problem was not stopped only with these, it continued. Since I used VC++ code, it expected atleast the VC++ runtime redistributable to be installed in the client machine. I thought of dropping the plan to migrate our install to Wix because of these kind of problems.
But I came to know that there is a nice and very cool feature that DTF is available in Wix to integrate any kind of actions in C#. I used it and could integrate the key validation in couple of hours and till now it is working fine in all client machine I implemented before 6 month.
Do you have any interesting moment or nice experience with DTF?
Search my blog at http://blog.deploymentengineering.com for DTF and you'll find a lot of useful content. I love DTF but I still believe that the best solution is to avoid a CA whenever possible in the first place. C#, like VBScript before it, is so luring that it tends to suck imperative thinking developers into writing CAs when not needed. I believe this is the reason DTF wasn't released for so long.
At my day job my approval is required for anyone who believes they need a CA. I instruct the developers on basic MSI philosphy, how to use DTF, how to attach a debugger and I make it clear that they are on the hook if it ever has any issues. The result is very few but well written CAs in our product line.
I have written several .NET CAs to support our WiX based installs:
Managed Wrapper around HTTPAPI.DLL - supports creating IP/Port SSL bindings and HTTP Url ACLs for use in deploying WCF services. I plan to turn this one into a Wix Extension. It was very interesting learning how to properly handle rollbacks, etc.
SSL Picker dialog that displays all the SSL certificates on the system and allows you to pick one.
SQL Server browser dialog - lets you browse your network for SQL Servers and then browse SQL Servers for Databases. Optionally uses impersonation. This is for crafting a connection string.
I am in the process of writing a set of CAs that will use the Microsoft.Web.Administration assembly to do native installs of web applications on IIS 7 (without requiring the IIS 6 Metabase Compatibilty feature be installed).
First off, the C#/DTF custom actions are still custom actions (no magic here :-)), so you should follow all the various CA guidelines working with this kind as well. It simplifies most of MSI tasks by abstracting low-level API behind the high level well-designed classes. Also, keep in mind that you can use managed code CA only in case the target machine has .NET installed (or install it as a prerequisite). Finally, the dtf.chm documentation which is distributed along with WiX toolset has some simple, but self-explanatory examples.
Hope this helps.