I would like to find out if someone (and maybe someone on StackOverflow works for LogMeIn, and can fill me in on the details) knows how to create a similar experience much like what you get with LogMeIn when you install their remote components on a computer, when logged into their site?
Typically, when you download and keep their remote components on a thumbdrive, you have to log into their software with your username and password, but when you're on their site, and click on "Add Computer" from their menu of options, the setup process bypasses the login process.
I'm writing up the specifications on a different tool, but similar in deployment model, and having that feature would make the setup process for the end user all the more simplistic in the long run.
Any assistance would be greatly appreciated.
Edit:
I did some digging and ran across this example of how to read from a table. So now I'm thinking maybe my way of doing this is to create a custom "download" page that when it gets clicked on, the msi is read into memory, I edit a custom property to insert a guid or other property that expires in 10 minutes or so, and use the guid to link the user account to the installation instance... Hmm... may work :)
Something to try during my next geek week before I go about building the msi installer for said project.
Windows Installer has the concept of transforms. LogMeIn is probably just using a base msi and programtically generating a transform and applying it as part of a watermarking process.
Morphing Installers ( with transforms ):
http://www.tramontana.co.hu/wix/lesson9.php
The concepts here are straightforward and the majority of your work is going to be integrating it into your websites build/release process.
Personally I get nervous about baking that much information into an MSI but the LogMeIn people obviously had a business case for making it as easy easy easy as possible for their users.
Once you have the admin password to a (non-firewalled) windows box, you can copy files, remotely update the registry, start services, etc.
This is one example of a remote VNC install procedure.
One remote desktop vendor (don't remember which) that I looked at allowed remote installation by ordering a computer to log in and install on any computer located on the same subnet.
Related
so I have a bundled software that a client can download and install (using an msi on win machines).
part of this software is a mongoDB database, that stores client info, configurations, etc..
When the software is first installed, it creates an empty folder for the mongoDB, and whenever the software starts, it starts a mongod process (using C#'s Process.Start()): mongod.exe --dbpath <path> --port <port> --quiet.
My goal is to secure the mongoDB database with a username / password that will be known only to my application.
this will help prevent tampering with my client's data from the outside, as well as make it harder (but not impossible, see below) for the client themselves to tamper with the application's data.
The general idea, I guess, is that on installation (or on startup), to create a user with read / write privileges which my software will use to communicate with the database.
So My questions are:
1. How do I programmatically do this? I guess this is the right direction, but I couldn't find much info on the c# driver docs
2. How do I deal with upgrades? i.e clients who installed a previous version of the software, where the database is not secure at all; i would like to create a user with a password in that case as well.
3. how do I store the application user's credentials in my application? in a config file? but that can be read by the client. any best practices here?
versions info- (unfortunately, because of my company's issues, we're not using the latest product versions); mongoDB 2.6, mongoDB driver for .net 1.5.0.
thanks!
P.S. I have read through the security section on the mongoDB website, but wasn't able to find a simple example for the use case I'm trying to implement.. maybe I'm just missing something simple here..
This is kind of an interesting, unusual use case.
First of all, I want to make sure you're aware of the licensing/copyright implications of bundling MongoDB with your software. You should check out the license section of the mongo project GitHub page and read up on the AGPL.
Second, the easiest part of your question:
how do I store the application user's credentials in my application? in a config file? but that can be read by the client. any best practices here?
This goes beyond MongoDB. If a user owns the system that the mongod process is running on, they could just copy the data files and set up a no-auth mongod on top of your application data. You cannot reasonably stop them from doing things like that, so do not count on your application's data to be secure from the client user. Plus, if you install your application code locally, any decently smart and committed person should be able to extract the username and password from the compiled application code. You can make it hard, but not impossible.
Third,
How do I programmatically do this?
Based on what I just said, I'm taking "this" to mean
on installation (or on startup), to create a user with read / write privileges which my software will use to communicate with the database.
not the part about having it be secure from the person who owns the computer it's installed on, because that's not possible. To do this, I'd either package a mini datafile to start the mongod on top of, one that included users set up already, or include a dump that you use something like mongorestore to load into the mongod after you start it up. The first option is way simpler to implement and should not require you to have to take down and respawn the mongod process, so try that - see if you can set up a mongod with auth how you want it and then transplant user info by copying data files. FWIW, I'm pretty sure the passwords are not stored in plain text in the data files (they are salted), so you won't have that directly exposed from the data files.
Finally,
How do I deal with upgrades?
You'll have to take down their mongod, restart it with auth, use the localhost exception to create the users you need, turn off the localhost exception (optional but why not), and then end that connection and start new ones using auth. It's the same process as in the security tutorials, you just have to do it with C# driver commands. Note that moving between MongoDB versions is also tricky as the seurity model has improved over time, so you should consult the upgrade guide for extra things to do to make sure user schema gets upgraded correctly if you are moving a user from a secure 2.6 to a secure 3.0, say.
C# driver connectionstring can accept login credentials for the database.
mongodb://username:pwd#server:port/dbname
for ex
mongodb://myuser:mypassword#mydbserver:30254/mydb
The best way is to store the data in a config file. If you are worried about exposing it, it can be encrypted and stored. Other less likely option is to store in a resource file and reference that as a string.
I have developed a small application with SQL SERVER back end and I also make an installer for the application with Indigo Rose Setup factory 8.0. What I need is I want to automatically create the database back end with specific user account during the installation of the application.
Before the installer a user is asked to install either SQL server or SQL express as prerequisite, when the database is installed the installation of the software continues. I tried to do using SQL script but I don’t how to do it before installation on the installer software. I though also to embed the database creation program in the main application and it will execute on the user need upon the completion of the installation but I have never tried it before whether it works or not.
Incase if it need I developed the system using C# with SQL SERVER 2005 backend.
So would you please give me some answer to tackle the problem?
Thank you
The simplest way would be to have the installer call sqlcmd.exe to run a sql script. To call that, you will need to know the data source (location) of the sql instance. You will need to get that from the user. For example, machinename, machinename\instancename or typically sqlexpress is machinename\SQLExpress.
http://msdn.microsoft.com/en-us/library/ms165702.aspx
You can also side step the pre-req and install sqlexpress for your customer. There's a cmdline to install it:
http://msdn.microsoft.com/en-us/library/ms144259.aspx
Another option with no sql dependencies is to write your own custom action (command line/API), parse between the GO statements in the script and execute with ADO.net.
Another option outside of setup is to separate setup and configuration. Setup only lays down bits and the database is created at runtime via a configuration phase of the runtime of the product. This has many benefits including being able to update your bits (either with a patch or automatically) after the setup phase and before the configuration phase. You can also give a better interactive experience and handle issues at runtime - with setup, your choices are to fail setup and roll it back which is a bad experience.
Hope that helps.
Bryan already gave you good advice. My recommendation would be to have the application itself be capable of deploying the database by running the deployment script(s). You can use a library like dbutilscmd that parses the .sql scripts and executes the batches from inside the application. I would also advise to have your scripts be capable of upgrading the database, not just deploy it. This will be very handy when you release v. 2.0 of the application. See Version Control and your Database.
One thing to consider is that often the initial database deployment requires an elevated privilege context. There are some options, see Teach Your Apps To Play Nicely With Windows Vista User Account Control.
I'm a C# noob and i want to ask if it's possible for this kind of scenario:
I have a windows form app in C#, is it possible i will only install it in 1 computer(as a server) and it can be accessible from all the computers within the network? If it's possible can you please help me what i need to do, any reference/books/tutorials?
I already googled this but i think i can't find the correct 'search word' that's why i didn't get the desired search result.
Yes it is possible. Put the C# executable in a network UNC Path, and you can access it if you create a link on the destination desktops. XP SP 2 and higher by default can run it. If it has .NET 3.0 or 3.5 or 4.0 framework you may need to install the Runtimes for those frameworks, but .NET 2.0 should be fine with XPsp2. All the frameworks are downloadable from Microsoft's site.
Is this a database driven app or just a straight up stand alone?
You don't need any books, it should work just fine. But provide as many details as you can so we can steer you in the right direction.
You may have to do a large code overhaul to do this. Could you simply install it on one computer and remote login to that computer and access it?
You see the thing about network-accessed programs is that they have two parts--a client and a server. It sounds like you just have one piece. You would need to write a program that is a windows form and install it on all the machines. You would then need to write your server code that receives the data from the client over the network.
You would need to know about socket programming. Here is a book introductory tutorial of C# and sockets.
http://www.codeproject.com/KB/IP/socketsincsharp.aspx
I'm not 100% sure what you're asking, but hopefully this covers it. If not, please edit your question to be more specific.
You can generally run a WinForms application from a shared network drive/folder by copying the executable to that drive (and making sure that all users have appropriate access to that network location).
If you use an automatic installer, it should be possible to select a network share as the place to install the software. Automatic installers tend to also put things in the local registry (e.g. create menu items for the program, which go on the local computer always). In that scenario, you would want to create an installer that creates appropriate shortcuts/menu items on the local computer that point to the pre-installed executable on the network share.
You need to take care that the windows forms application doesn't write data to the network share, or if it does, that it does so in a manner consistent with multiple users accessing that data (in other words, keep in mind that all of your users will share that location).
Put it in a shared folder and access either by UNC path or map a drive to that location. You could also map the drive for all users with group policy.
Alternatively you could wrap your app into an MSI and install it via group policy?
Hope this helps :)
You should use a layered approach to your software design. Create a website to give users access to the application from multiple locations. Then create a service layer to give the website access to the desktop functionality that you require. WCF is a good service layer as it allows consumption through HTTP.
My question is sort of linked to this existing question
How to deploy a desktop .Net application with custom settings per user
However, I understand the idea of using Application Settings what I can't find information on is, how should I deploy the application settings for different customers?
We have a custom settings system that works just fine, however when the app is first run it needs to know a couple of things, such as Company Name and Application Server. These will obviously differ on a customer basis.
I don't want the user to have to input these settings at first run as in most cases the app will be deployed by Group Policy.
Currently my thinking is to have some sort of setting file in a separate build per customer. Is this the way to go, or have I missed some kind of native support for this idea of "customer profiles"?
EDIT:
More info that might help people grok my question.
This is an enterprise application that consists of a central database and application server, plus 100 installations of a client application. I need to be able to give the client application some application settings that will obviously be different for different customers.
A lot of applications ask you some initial settings at the first start (Microsoft Office, Visual Studio, etc.). So this behaviour is commonly known by the user.
Maybe the problem is more, that these initial settings revive an update of your application. To accomplish this you could save your data in a version independent path within the registry or somewhere below %AppData%.
Also it would be helpful to prefill these dialogs at the first startup, by getting these informations somewhere out of the machine (e.g. Company Name can be get from registry [HKLM\Software\Microsoft\WindowsNT\CurrentVersion\RegisteredOrganization] or as Application Server take the Gateway address, AD Server, whatever most commonly matches).
So in a best case the user will be presented with a already correct filled out form and just has to press enter or he makes only the changes that are necessary, but doesn't to fill out the complete dialog by himself.
Update:
So if the user doesn't know the Application Server path. Who does it? Where resides this information? Maybe you can enforce your customers to provide this information all the same way. Maybe they set some environment variable within the logon script or they put a file with the needed informations on a global accessible place (e.g. where the logon script resides).
If I understand right you want to deploy a pre-customized software for each user.
You could use WIX to create a MSI-package for each customer. You can deliver several user-settings in your customer-oriented msi. You can dynamically generate a WIX-XML-Document based on a data-source where you store your customers.
Is a bit work, but later saves a lot of work. The MSI-creation through WIX can be easily integrated into the build-process.
Given that it's an enterprise environment, have you considered using ClickOnce? We've had success mainly with startup arguments, e.g. http://servername/OurApp.application?environment=uat
It doesn't always scale, but you can pass arguments using GET variables and parsing the resulting QueryString when delivering via HTTP - http://msdn.microsoft.com/en-us/library/ms172242.aspx
You might pass in the settings in the QueryString, or create them in the database, generate a (hashed?) key and build a QueryString unique to that reference (with the added benefit that an inquisitive user wouldn't be able to manipulate the URI and fake a different set of parameters).
I've got an app that publishes and updates from an http update location (I publish to the ftp site of the host, and update from the website).
The publish.htm page is very handy as I can install the app on any machine, anywhere without needing media. The problem is, so can anyone else. How can I secure the update location so that only authorized users can install the app without buggering the auto-update feature of clickonce?
Is this an internal application? If so you could just exclude the publish.htm page from your deployment. Then to install you would then just use the application manifest link http://yoursite/YourApplication.application which should kick the install off, this would not affect automatic updates. This may be just enough obfuscation to for your purposes.
Failing that you can dynamically generate the application manifest using a little bit of asp.net which would only produce the manifest for the users you want. The other benefit this has is that you can isolate a small group of users when rolling out a new version.
Just a thought.
If you're still transferring over HTTP, it's as easy as running a traffic sniffing program like Wireshark to see where the application is downloading from. To evade this you'll need to make sure to transfer over HTTPS, on top of whatever obfuscation you do to hide the update location.