I'm trying to develop an application that is composed by two parts, a Windows Service and a WPF GUI to manage the data used by the Service.
The Windows Service is running under Local System profile, and the UI part is installed for all users. This UI stores the data used by the Service on the AppData folder, so I need to retrieve the path to the folder for each user from the service to everything work fine.
The other solution is to have the data stored in the Program Files folder, but this way, all users can see the config and data from other users and the Application must run under Administrative privileges to write to C:/Program Files.
Finally the third solution, and the one that I'm currently using, is to have the Windows Service to host a WCF to commuinicate the GUI with the Service, so this last one is the only one who is able to write to C:/Program Files, and the UI does not require Administrative rights.
Which is the best sollution for me?
BTW: right now my data is stored in encrypted json format in txt files, but this is another querstion here.
EDIT: This brings to my head another question. How do big applications write to their own ProgramFile folder? Like aniviruses and this kind of giant apps.
Related
I have a Windows service that runs as a specific user (agent installed on desktop machines) - I had originally stored/updated appsettings.json in Program Files alongside the binary, but this causes issues during updates etc.
I have since moved to using an app config file under the users home directory - which I create manually (Finding local users profile path in C# and creation of folder).
I also see there is a ProgramData enum that is available via .NET directory enums, and would save the above code (less things to break in future).
The Linux/MacOS version of this software would be under /home/myuser or /etc/myapp. I need to consider this as I write an abstraction layer to run my BackgroundWorker as a daemon and the associated installation thereof.
My question is which is better to follow for this multi-platform supported app, store config files by user directory, or program data directory?
Appreciate this is on the fringes of development question, but also not necessarily serverfault question - if better suited let me know and will repost on a different site.
I have a kind of odd request- I have lots of users who run my application, and I need to be able to have the app know who is running it. This isn't a problem at all, and I am capturing this info just fine.
The trick is the application needs to access a network share that is restricted- none of the users running the app have permission to do anything there. And there's a lot of stuff going on there- reading files, writing, and since this is a WPF app, data binding to file URI's in that restricted area. To set ImageSource of an Image for example. In all different parts of the application, I need unrestricted access to that data.
I have been looking into the WindowsIdentity.Impersonation stuff, but it seems to be more targeted towards impersonating a user in a small context scope and then ending impersonation.. which is okay, but not convenient.
Is there a way to have my app start and then Impersonate a user within the app scope? So then I could do all the work with the correct permissions sets.
One approach that might work is to set up a Windows service on the users machine that can connect to the server with appropriate Active Directory account privileges. Your application would communicate with that Windows service rather than to the server directly. While this might literally do what you want, the implementation may be more involved than you care to mess with.
I am writing a GUI to configure my service written in C#.NET 3.5, it edits an embedded SQLite database from which the service pulls its settings. The GUI is being developed in a seperate project and I am at the point where I would like to integrate them. It is my first time implementing someting like this and I am unsure how I go about it.
Do I simply place the GUI .exe file in the same directory (bin?) as the service and give it the location of the database?
Yes, usually. You will however have to ask for elevation or you won't be able to write to the dbase. UAC prevents write access to the directories in c:\program files. Which is okayish, the user is after all tinkering with the configuration of a privileged service. And you probably need to stop and start the service to make the configuration change effective, something you can only do from a privileged program. Embed a manifest in gui.exe as explained in this post.
Pre-empting the next question: there is no standard Windows way to have to dbase in a location that's accessible to both the service and your gui without elevation. You'd have to write an installer that creates a directory that gives the gui app sufficient rights and allows the service to find the directory without relying on the user name.
My problem is I have a LOB application that can possibly save multiple files (number of files only known at runtime) based on user inputs. Saving this as a single file and having the user break them apart, or zipping them up as a single file is not an option unfortunately.
SaveFileDialog seems suited to only save 1 file at a time. Third party controls may be an option but I have yet to find any that serve this purpose. Thanks!
The browser security model guidelines (outside of Silverlight) prohibit web application logic (script or otherwise) from having direct access to the local file system.
Consider what havoc a malicious web site could wreak on your computer if web application script could write arbitrary files to arbitrary locations on the local hard disk!
For this reason, Silverlight isolates your code away from the local file system. Silverlight manages the Open File or Save File dialogs, but your web app code never gets to see the full path of the file names directly for security reasons. The Silverlight dialog only supports working with one filename / path at a time.
Silverlight does offer isolated storage on the local machine in which your web app could write multiple files. However, as noted in comments, isolated storage is isolated in both directions - it keeps the web app isolated from the local file system, and that makes it difficult for the end user to access the contents of the isolated storage outside of the browser. (Difficult enough to make it infeasible for nontechnical users, but not difficult enough to call isolated storage "secure" from malicious snooping).
Short of writing your own native executable browser extension (for each different browser brand and version you wish to support) (or non-sandboxed javascript plugin for some browsers), I don't think there is a way for a web app to push data into multiple local files convenient to use outside of the browser in one user action.
Since this is an LOB in the intranet zone have you considered asking your users to install the app as OOB with Elevated trust. This would allow you to write files to the users Documents folder without the SaveFileDialog.
The other option is to zip the files with a single SaveFileDialog call.
There are no other Silverlight oriented solution.
I have a website that occasionally needs to have a handful of the tables in its database updated. The updates come from another system that exports to comma delimited text files. I can then either FTP the text files to the web server, send them in through an admin upload page, or manually log in to Remote Desktop to download the text files. I have all my C# code written to parse the files, check the database contents, and decide what to do.
Should I code the sync logic to be part of a file upload page, protected in the admin section of the site or should I create a Windows Service that constantly looks for files to process in a particular directory that I can drop files in through FTP?
I have used Windows Services in the past and they have worked great, but if I ever have to make a change to the code it can take longer than it would if I just had to modify an ASPX.
Are their security benefits one way or another?
Performance benefits?
ASPX page wins the "ease of maintenance" category.
I would create a Windows Service to watch a secure folder and use a directory watcher to look for new files. Since the files are coming from another system, it is asynchronous in nature, and it is much more performant to have a Windows Service running separately to watch for updates as they happen. It can also parse the files and update the database for you.
Depending on who maintains the remote system, the easiest way is to grant permission to the service to access the files on a secure, shared folder. Then you won't need to do anything manually.