How to manage your own user context on Windows files? - c#

I am working on a Windows 8.1/10-based Kiosk-type product (closed-down, no Windows GUI). We have our own user management system where every user of the Kiosk has to log on. Windows-wise the user is always the same auto logged on one, for reasons beyond my control.
In the process after logging on, files will be created. As the Windows user is always one and the same, the owner of created files will always be the same. How would I go about applying some kind of user context/ownership indication to the created files using our own user context? The most important use of this would be to keep track of which files to show/list for which user. We use C++ and C#.
edit: This has not been a problem until now, as each user has had their files stored in their own directory. We have then used that fact for deciding what files to show to a user. We are now changing that to instead let certain input dictate where the files are to be created for a more flexible, custom file structure.

Related

Is it possible for a user to only select file save location once?

I've been trying to learn how to handle saving normal .txt files in UWP, and have realized that it's quite locked down compared to WPF, especially in the sense of what folders you can access without requesting the user to select a location. I have searched for various ways this might be possible but found no working answer.
Question Description:
I basically would love to know if this is possible, and preferably a point in the direction where I can learn how exactly to do this.
Application settings page requires user to select folder where files are saved.
Application remembers this between launches (unsure if this is possible, but I can't require the user to select the folder on every launch)
Application saves files to the specified folder.
In my understanding, this should be possible, as the user is the one specifying the location via filepicker, but is it possible to have this work between launches so that the user wont be required to re-select the save folder?
I need to figure this out, as I would like my application to support selecting attached network drives, cloud storage folders, etc.
Any help is very much appreciated, and if there are any questions I will answer them to the best of my ability.
Fow this purpose there are two access lists designed: FutureAccessList and MostRecentlyUsedList. Once the user has picked up the folder with the picker, you add it to such list and receive a token, which you save for future purpose in LocalSettings:
ApplicationData.Current.LocalSettings.Values["MyFolder"] = StorageApplicationPermissions.FutureAccessList.Add(pickedFolder);
Then later, once you want to access that folder, you can do it like this:
StorageFolder folder = await StorageApplicationPermissions.FutureAccessList.GetFolderAsync(ApplicationData.Current.LocalSettings.Values["MyFolder"].ToString());
You can't save a StorageFolder or a path to it in settings, hence the UWP app needs permissions to access the folder. Using above access lists solves this problem.
I believe you want to save user settings and keep it somewhere so that next time when they launch the application, they can use the same settings.
Please check out this tutorial from Microsoft, which describes how to do exactly that.
https://msdn.microsoft.com/en-us/library/bb397750(v=vs.110).aspx

Accessing file information for all users, C#

I'm writing a short C# program that will iterate over each user on a given Windows system, check in their local app data folder for a specific directory, and operating on it if it exists.
I'm looking for a good way to resolve the absolute file path to each users' local app data folder. I can use Environment.SpecialFolder.LocalApplicationData but that will only work for the user that is currently running the program.
I know I can cobble together a few different utilities and make a couple assumptions about where a user's local data is usually stored to make it work for 99% of the time (determine a list of all users, go through each one and find/guess where their app data is, etc.), but I was hoping there was a more elegant solution?

c#.net application which can opened while opening a folder

I would like to create a c# application which will open when i open a folder automatically.
My c# application is intended to be like a password system, so that the contents in the folder can only viewed after logging in to my application. Everything is ready..........
but i am confused how to open my application directly while opening the folder with a c# script?
I have now created a application which will ask the user for name and password while opening the application and now i want to make it open through the folder to be locked , how to do it?
Ok, first of all if you want the folder to be secure you should encrypt it otherwise all the user has to do to gain access is kill the process.
What i would recommend you do instead is create a encrypted file. For example a zip file. Then all you have to do associate the file with the program and to unpack it with the password. Then when the user is done delete it and overwrite the temporary folder. It's really important that you overwrite it otherwise the encryption is useless.
If you want to avoid conflict with other programs that work with zip files you can make your own file type it does not affect the content of the file in any way.
I hope this helps.
To make sure I understand... you want to build an application that will, when someone tries to open it, will only open after they supply a password. Hmmm... okay. A specific folder, or any folder? Local folders or folders on network shares? I initially was thinking a file system watcher approach, but that will only work on change events, like copying, renaming, deleting, etc. So that won't work. The closest would be to check last accessed time, but that is an alert ex post facto, so this must be rejected. I'm not sure how you could do this in C#. What is wrong with the robust security options MS has already established, like global groups. That provides flexible restrictions on access. Especially over large amounts of folders. Are users going to have one password per folder? Too cumbersome. One password per user? Use Windows authentication to lock it down. How is this app storing the passwords?
I recommend trying to leverage existing technology to solve problems before trying to re-invent the wheel. You have omitted the scope of this, and what you have already attempted, so we may not understand completely.

Where to store custom configuration files

I currently store a serialized XML file in the application directory that contains all changes specific to the program operation (not typical system or user configuration). Weeks ago, we started running into problems where it would not save correctly (read my previous question about this).
Long story short, we finally discovered that Windows 7 (and sometimes Vista) has an issue with writing into the application directory (specifically anything under Program Files). Now, if this were a normal configuration file I would simply store it under the user's APPDATA folder, but it is not normal. We run this on our own instrumentation, and misconfigurations are 99% of the reason customers have issues running our software. So we need this file to be accessible such that they can easily find it and email it to us. Appdata is hard enough for experienced users to find, much less very non-technological people.
We've also tried running it as Administrator, and making folder permissions wide open (we have control over every computer it runs on; it will never run on some random person's machine). But, these sometimes work, and sometimes do not.
The worst part is that when I write the file back out, it doesn't even throw an error; it simply writes it to some temporary directory that expires at some unknown point in time. Weeks later, our user will have an issue, and the configuration file is all messed up.
So, my question is where should I be storing this file, if not in Program Files? Should I just put it in APPDATA anyway, and make a small utility that emails it to us automatically in case of a problem? Or can I leave it in Program Files, but change some specific permission or registry key to allow it to operate normally?
It depends on whether or not the user needs to edit the file directly. If not, you should put them in %APPDATA%, which you can access via:
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
Otherwise, you might put it in My Documents:
Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments)
Either way, putting it in Program Files is not a good idea. As you discovered, there are permission issues, even if running as Administrator.
For those users, you could build a button in that would open this directory. You could put it in an inconspicuous place that you could later direct them to.
For users that have an email client on their box, you could have a button that would create a new email with subject and automatically attach the file to the email.

C# Detecting server setup

I'm writing a program that deals with the logs generated by the clients server. How can I detect where the user is storing them? It feels invasive to search all files, but what if they're being stored outside of the root. Is this acceptable, what if I make the user click "detect" first? Regardless, what if they've been renamed and reformatted? Is it possible to read the server settings themselves from my external program? I want this to work on linux and windows servers. I need WC3 Extended format w/ several fields enabled that are not naturally. I also don't want it to return null if it's enabled but no log has been yet created. I don't want to force the user (assumed dumb) to play with settings.
Any ideas?
Hardcode where you expect them to be in the common case, and if they're not there, ask the user about it. Doing more "magic" than that seems like a recipe for over-complexity and mistakes.
If the user is specifying the location of the log file, then either you should have the user locate the file(s) themselves or keep track of these locations somewhere else when they are saved. You don't need to be doing a full (or large partial) drive search.

Categories

Resources