I am developing a UWP app in C#.
I need a SQLite database to store some information, and I place this file in the LocalState folder, which I am sure to have access to.
Everything usually works fine, except in few cases in which some users experience an error while accessing the database when the app starts (please also notice that the users are able to normally run the app - sometimes - while other times the app cannot start because of this file access problem).
The error is thrown by the SQLite connector and says
database is locked
The users also confirm that they haven't touched the database file (actually they didn't even know it exists...)
Now, I cannot understand:
What is the root cause of the problem, since the file should be accessible by the UWP app, it is in the private space of the user, so no other user of the machine should have access to it, and the UWP app is basically a singleton (you cannot run two instances of the App at the same time)
Why it is happening to a small portion of the users, just sporadically
Thank you very much!
Related
I need to find a way to block user access to my database that will be installed in his pc.
So, here on the company we have a problem. We need to block user access to our database that will be installed on their pc, what I mean by this is...
We have 2 softwares. A web App ERP and an instalable finances App.
We reached the conclusion that it was unnecessary to have 2 standalone apps, and that we should put the finances app inside our ERP.
But this comes with a problem, theres a big part of our users that don't trust the web, and web apps, they think that what is on their pc is what is
safe, and is where it should be.
We don't want to maintain the 2 standalone softwares needlessly.
We asked our users if they'd be happy with a progressive web app, their answer was the same.
Then we tried to make a way to run our ERP on their pc whilst offline, as an executable, but that comes with a lot of troubles, we need to install IIS, PostgreSQL, .net frameworks, pgadmin, our metadata database (which it shouldn't be accessible in any way shape or form by the user!), etc... that lets our app run on the users pc.
Of course we don't want to do that, but we got no choice left. We need to at least block our metadata database from being accessed, since the whole structure of the web app is there and we don't want to share it with the competition
Our solution was installing all that was needed inside a virtual drive and run the app from there. but all the files and databases are available to the user for him to mess with.
How can we restrict acess to that virtual drive the best possible, and protect our intelligence property? is it even feasable? I've run out of ideas and don't know what else to do, so any help is welcome.
Should I take another route or is it a lost cause?
Whoever has control of the database machine has control of the database. So if the database is running on the client's machine, there is no way to keep an administrative user out of the database.
So if the users don't trust a web application, they will have to trust their system administrators (or themselves, if they have administrator rights to their machines).
I'm a relatively new Developer building my first app.
Right now I'm in the process of developing a UWP app and I am needing to get the Hard Drive Serial number from the PC from the Views (OnNavigatedTo), then after a few more fields are filled out, to then save all values to a SQL Server.
What I have discovered up to this point:
Grabbing some values like Hard Drive SN are not so easy with UWP.
I don't seem to have access to Registry HKLM via UWP
I can grab it very easily with PowerShell, and write it to a JSON or XML file. which I plan to do with a Service Account when PC is imaged.
I Don't know where to put the file where the App can see it.
Writing to Sql Server can only be done by creating a webservice and making HTTP / JSON calls via App. (I have this part setup but have not started accessing it via app yet)
So the part I really need help with I guess, is Where to Put JSON/XML file that App will be able to see and read from. Unless of course, someone knows of another way to get Hard Drive SN into a UWP app.
Thanks for Any Help
The recommended way to do this (if you want to go to the Windows Store) is to use a FileOpenPicker and have the user choose the file manually.
If this is for side-loading only (not going to the Windows Store) you can write the file to the user's Documents folder and then the UWP can read it using documentsLibrary capability without any user intervention. You could also use a fullTrust extension to run the PowerShell script and to put the file in the app's data folder. You can check out the Desktop Bridge docs for more info on fullTrust extensions.
Hello all,
I just created a C# application that connects to a server database, it can insert, update, search, delete the files from the database, more than this I can view all the files in a listview.
I have encountered the following problems:
1) I don't want the application to be instaled on every PC from work, I want it to be instaled on a shared drive and every PC can open the application from a folder inside that drive (I don't want them to connect remoutly to my PC). I heard that there would be an another solution, that I can put my app into a Site (I have no idea how.. never did that before);
2) I have no idea how many PC can use the application at the same time ( but somehow I don't think that should be a problem because I tried inserting into the database through SQL manager at the same time with a mate and there were no problems) but if I put the application to be shared from the same drive it could cause problems;
3 I would love some tips how to make my application work nicer ( it started getting laggy after a few show/hide text boxes and labels..
Well the most important for me would be point (1), I have no idea how can I do this, I am sure that it is possible somehow, I accepted doing this C# app without knowing like anything but now it makes me curious like hell!
Thank you in advance! (sorry for bad english)
Image:
my first C# applicatipon
You can use something like ClickOnce so the users can download and execute your app.
From the site:
You can publish a ClickOnce application in three different ways: from
a Web page, from a network file share, or from media such as a CD-ROM.
A ClickOnce application can be installed on an end user's computer and
run locally even when the computer is offline, or it can be run in an
online-only mode without permanently installing anything on the end
user's computer.
Either that or convert to windows forms application to a web based application using ASP.Net.
Microsofts preferred way to handle application configuration and runtime data seems obvious at a first glance: App.config, which will be stored in the application execution directory (C:\Program Files\ProductLocation in most cases.) where only privileged users have write access. (Makes sense to me, because a casual user shouldn't be able to alter essential application configurations).
For normal user configuration, there's a user.config which will be copied into each users personal application data directory (%APPDATA%).
But this leads to a few questions:
How can I alter configurations for every user without executing the process as administrator?
Where should I store application data that doesn't get deployed with the application, instead should be generated when the application is started the first time?
How is it possible to have e.g. dynamic connections strings, like for a database health monitor application?
I checked out the program data folder (%PROGRAMDATA% -> C:\ProgramData), but it seems this place is read-only for the standard user. (Windows Installer does create folders in here if needed, but they're all read-only.) -> What happend to %ALLUSERS%?
Example where the Microsoft way may fail in my eyes:
A financial application where every user should store his information in the same database (a SqlCE file db), where as the application has to run with user privileges (I don't want to be administrator to manage my wallet). The application needs connection to a database that isn't available at runtime and may be generated in during the first run using EntityFramework. So it could be possible that even the connection string has to be dynamic, and not configured in the app.settings where such information is fixed.
This is stupid! Users could read sensitive information from other users by directly accessing the file database!
-> Security is not only a file permission thing, there could also be database users, certificates, cryptography etc.)
Do I have to develop my own settings handler as a workaround to the Microsoft intended way?
I guess this question is asked a numerous times on SO, but every answer I found showed up workarounds, different solutions. Questions regarding "best practice" are closed immediately, so I tried to provide a practical example here.
I'm writing a windows service that will have a 'LocalService' account type. I have a file that stores what it has to do.
I also have a windows form GUI where that file is also accessed to add/remove instances of the action for the service to perform. (dont know if its relavant but the service downloads tables from a webservice and exports them to any database the user has access to. these downloads are scheduled to happen regularly)
The service will only be installed on a user account.
I was planning on storing the file in user appdata folder however while debugging the service I got the error "Access to path [path] is denied"
Where would you recommend storing this file so it is accessible from both programs?
Thanks
EDIT: Looking a bit more, I've realised that
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
finds a different path for the service and the windows form app..
And that that app cant access the service appdata just as the service cant seem to access user appdata. so the same question stands!
ANOTHER EDIT:
So it turns out
Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)
is accessible from a local service and a user program - doh
...but some places seem to be read only...
Three options as I see it:
Run the service under the user's login id
Upside - both processes will have identical access to the various parts of the file system, so should remove your immediate problem
Downside - if the user changes their password the two will get out of sync.
write to some "neutral" part of the file system (or perhaps the registry) where shared access won't be a problem. The trouble with AppData is that as you've found, Windows sets up all kinds of protection around it in order to ringfence different users from each other.
Upside - no problems writing
Downside - you're effectively inventing your own standard. 15 years ago this would have been a no-brainer, the registry, but these days I get the impression that the registry is frowned upon (even though ms still rely on it!). If you do go down the registry route, make sure you're aiming at hklm not hkcu else you'll have the same problem!
During your setup, do some tricks to set up access to the relevant folders. But this is basically tearing down the protection that Windows sets up. Doesn't sound too sensible to me.