Is it possible to defend my program whilst offline? - c#

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).

Related

Solution for a no-server multi-user application/database?

I am at a dead end an I could really use some help.
I intern for a huge company. My projects involves creating an application to automate/simplify the work of a retiring employee.
The problem here lies in the strict company policies. I am a developer stuck at business end of the company. Therefor IT gives me nothing:
I don't have a server (nor web nor database)
I can't create a server, because no pc will be running and we can't keep them logged in due to single sign on with company cards.
I can't install anything on the pc's in the network.
I can access a share file server, that is backed up every day.
The libraries involved have to be free
A central database has to be accessed by a dozen of users (at once)
The database will recieve new data every day and will grow accordingly
The users will both read and write from/to the database
Preferably C#.NET or WPF solution
Application needs to open files stored on the shared drive. ( Only once, the important information will be extracted and stored in the database.. the file will then be removed)
My initial idea was to use silverlight (which runs standalone) in combination with SQLite. I ran a test and Silverlight files stored on the shared drive work. (Silverlight is installed on every pc on the network) This is my preferred front end. However (correct me if i'm wrong) I tried SQLite-net and I needed to add the sqlite3.dll to my windows/system32 folder, but on the network PC's I don't have access to the Windows folder, so this can not be done.
Also I read that SQLite or files in general can become corrupt when accessed by multiple users as one, so maybe I thought locking was an idea.
Which solutions are there to my problem?
I worked for a company for several years writing software for police departments to manage traffic collision reports. Police stations usually have little-to-no IT support, so we faced many similar limitations. The company actually did pretty well using Microsoft Access databases, with the setup looking something like this:
The shared drive had an Access database file (.mdb or .accdb) which was the actual "database".
Client computers (at the officers' desks) had Access applications with local "utility" tables for temporary storage, UI defined in Forms, and logic defined in Modules. Each of the client machines were connected to the repository on the shared drive by using linked tables. Local client configuration was stored either in the Access application in a config table, or in a text file on the machine.
It's not the cleanest solution, but it would allow you to create and maintain a unified solution using files that don't need to be installed and don't require any funny permissions, as long as everyone has read/write access to the shared drive.
Create a website. Today you can host ASP web apps in a stand alone .exe. By doing so you can make sure that the shared files are only accessed by one process. You can also limit the access to sqlite.
It also means that you do not have to distribute anything. Simply start your application and tell your users which url and port they have to browse too.
As for permissions, only the account running your webhost requires access to shared files etc.
You should take a look at ScimoreDB. It's an embedded database that supports multi-process read/write access. If needed it can also act as a client/server database; even as a distributed database with multiple nodes.
It's free to use and deploy. It has support for C++ and .NET. Only disadvantage is that it only works on Windows.

Organization of a multi-user application

I have a WPF C# multi-user applicaton which interacts with Sql Server Express database. Currently I have faced up with the following issue:
How to organize the application and the database in order for several users on different stations be able to work on it , maybe i should put the database file on a server, and make my application on all other stations refer to that server when they interact with the datatbase? If so, how can I provide security of the database file.
Is there any scenario in which I could install my application on server and sign it as server and while installing on other machines point that server?
Any advice on general strategies in such cases would be appreciated.
Thanks in advance!
If all the users are concurrent then your going to need to place the SQL instance on a server that they all have access too..
your also going to need to know look at quite a few things like this such as how your going to manage your transactions and just how your persistence layer is going to function in general.
each of those topics are probably going to breed many more SO questions :)
this could help for some inspiration on how your going to structure the persistance layer..
http://msdn.microsoft.com/en-us/magazine/dd569757.aspx
For multi-user application, you definitely should put the database onto a server. And because the application is for multi-users, the first screen shown when a user opens the application is the login screen (just like the case of web application).
Security isn't a matter, once a database is put in the filesystem, only the users on that computer can access it. And of course, the computer which contains databases is supposed to have only administrators as users. Another point is that Windows may have IIS running, don't put the database files under public root of IIS so that non-user people won't be able to download them through HTTP.
Let's say the users are working on the same office. You can assign any computer in the LAN as a server and install the database on it. Any computer in the same LAN has a LAN IP (eg. 192.168.1.100), your application can connect to this IP for database operations.

Can a web app access and modify the registry of Windows?

I've been writing desktop apps in C# for some time now but I'm increasingly getting frustrated with the fact that not everyone has .NET 2 or Higher installed. I don't have the option of upgrading their systems to meet my needs. My apps are mostly utilities that run alongside the main program the company I work for has. They access the file system and the registry. Being relatively new to programming in general, I was wondering if moving these tools to the web would solve some of my problems. But I have no idea if web apps can have access to these parts of Windows. I was thinking of writing these web apps in either Rails or ASP.NET. So my question is this. Can a web app access and modify the registry and file system of Windows?
Thanks.
Nope, "web apps" like asp.net or rails apps run on the server alone and just serve html to the client. So all the client-side code can do is what jscript running in the browser sandbox can do, ie no file access or registry access.
You can however install an activex on the client computer that gets full access, but the user has to agree to install it as it's a security risk.
Writing the apps as Web apps instead (and Rails is cool to use) is a good option - your users don't need to install anything, upgrades are easy to do, and dependancies are no longer a problem.
However, you now need to start re-architecting your apps so they do not need to write anything to the client, except a cookie (that's stored in the browser). If you can do this, then migrating to a webapp will be great.
If you cannot, my advice is to learn the same language that your company's app is written in. Once you do that, the company app will have taken care of the dependencies already and you will just need to offer your utilities alongside the app, perhaps even in the installer, or just to copy the files into a subdirectory. If you're thinking of learning Ruby, then learning the corporate language will be just as difficult (only you'll be able to reuse a lot of code used in the main app)
No, a traditional asp.net application cannot access the file system or registry on the windows box. Simply put because it doesn't actually run on the client machine. Instead it runs on the server where it does not have access to the local machine.
It is possible to have portions of the application which run on the client machine. Browser based applications for instance. However these would require that the 2.0 framework be installed on the customers machine which puts you right back at square #1.
No, this isn't possible. Web applications cannot modify the registry and/or file system on a user's machine because of the security implications. You would need to develop a Windows app to do these kind of changes. You could always make this tool available for download on your website though.
No, you can't do that with a web application. Besides others have already said, a web application run in a browser, not inside an operating system, so all you can do is what browsers allows you to do and not all you want, and browsers doesn't allows you to take control of the host machine.
I'm guessing the desktop app used in your company uses the registry to store workstation / user specific (state)data.
Moving to a web based app does not mean storing state data is no longer possible, just account for it by including a table in your database that can be used to save that same (state)data in. The registry is no longer needed.
Another pro is that by moving to a fully webbased application, you never have to worry about your endusers, because the code is running on the server, all the enduser gets is the output in html :-D.
The only thing to keep in mind is cross browser compatibility, don't create an app that works in IE only for instance, it has to look and work the same in all major browsers.
There are a few products out there, such as Xenocode and VMWare's ThinApp, that allow you to virtualize your app's dependencies to the point where your .NET app can run on a machine without the .NET Framework installed. Just another option from left field.

Shaky connectivity - favor web or desktop app?

I'm a desktop application developer who is temporarily working in the web. I'm working with a client that wants me to build an app for use by locations all over the state; however, these locations have very shaky connectivity.
They really want a centralized web app and are suggesting I build a "lean" web app. I don't know what a "lean web app" means: small HTTP requests but lots of them? or large HTTP requests with few of them? I tend to favor chunky vs chatty.. but I've never had to worry about connectivity before.
Do I suggest a desktop app that replicates data when connectivity exists? If not, what's the best way to approach a web app when connectivity is shaky?
EDIT:
I must qualify my question with further information. Assuming the web option, they've disallowed the use of browser runtime technologies and anything that requires installation. Thus, Silverlight is out, Flash is out, Gears is out - only asp.net and javascript is available to me. Having state this, part of my question was whether to use a desktop app; I suppose that can be extended to "thicker technologies".
EDIT #2: Network is homogeneous - every node is Windows. This won't be changing.
You should get a definition of what the client means by "lean" so that you don't have confusion surrounding it. Maybe present them with several options of lean that you think they might mean. One thing I've found is it's no good at all to guess about client requirements. Just get clarification before you waste a bunch of time.
Shaky connectivity definitely favors a desktop application. Web apps are great for users that have always-on Internet connections, and that might be using a variety of different browsers and operating systems.
Your client probably has locations that are all using Windows, so a desktop application is an appropriate choice. One other advantage of web applications is that they make the deployment issue easy to deal with. Auto-update technologies like ClickOnce make the deployment and update of desktop applications almost as easy.
And not to knock Google Gears, but it's relatively new and would have to be considered more risky than a tried-and-true desktop application.
Update: and if you're limited to just javascript on the client side, you definitely do not want to make this a web app. Your application simply will not be available whenever the Internet connection is down. There are ways to save stuff locally in javascript using cookies and user stores and whatnot, but you just don't want to do this.
If connectivity is so bad, I would suggest that you write a WinForm app that downloads information, locally edits it and then uploads it. This way, if your connection goes down, all you have to do is retry until it works.
They seem to be suggesting a plain vanilla web app that doesn't use AJAX or rely on .NET postbacks or do anything that might make it break down horribly if your connection goes away for a bit. Instead, it should be designed so that you can hit Refresh until it works. In other words, they seem to want the closest thing to a WinForm app, only uglier.
You may consider using a framework like Google Gears to help provide functionality during network down time. This allows users to connect to the web page once (with a functioning connection) and then be able to use the web app from then on, even without a connection.
When the network is restored, the framework can sync changes back with the central database.
There is even a tutorial for using Google Gears with the .Net Framework.
Gears with other languages
You mention that connectivity is shaky at these locations, but that the app needs to be centralized. One thing you might consider is using multiple decentralized read database servers and a single centralized write server. Mysql makes this possible and affordable if your app is small.
Have the main database server at the datacenter/central office. Put up small web/db servers at each location, with your app installed. You can even run them off a user computer if the remote location is not too big. Make the local database servers connect to the centralized database server as replication slaves. As changes come in to the centralized database, the slave servers will pull down the data and make it available locally. When the connection is unavailable, your app data is still at least available, if not up to date. When the connection is available, the database handles replicating all relevant data down.
Now all you have to do is make your app use two separate database handles: reading data it uses the local database, writing data it uses the central database.

Dynamically load .dlls from network share not browsable on client PC -- WCF?

I'm architecting a WPF application using the PnP Composite Application Guidance. The application will be run locally, within our intranet.
Modules will be loaded dynamically based on user roles. The modules must therefore be accessible to the application through a network share, thus accessible from the client machines.
What I'd like to do is keep all the module .dlls in a location not accessible to staff, but still be able to provide them to the composite application when demanded and when the current user is authenticated to use that module.
My thought is to load the .dlls by streaming them down from a WCF service, where the WCF service (on the server) can access the .dll repository, but none of the client machines can access it. Authentication would also be handled by the service.
I suspect that I might be overcomplicating things somehow.
Is this something that can be done with a simple filesystem configuration and programmatically passing credentials when accessing the shared folder? If I do this, would access only be granted to the calling application, or would the logged-on user now be able to navigate to the shared folder?
Is this, in any way, a solved problem with MEF or any other project of which you're aware? (I hope this isn't LMGTFY-worthy -- I haven't been able to come up with anything.)
At Argonne National Laboratory we keep all sharable DLL and other objects (.INI files, PowerBuilder PBD libraries, application software, etc.) on a simple and internally public file server and objects are being downloaded over the network on a per need basis as defined by each client/server application. Thus we are minimizing the maintenance of middleware (Oracle Client, PowerBuilder, Java, Microsoft, ODBC, etc.) to a single file server location with basically no software installed on the end user PC. Typically we physically download less than a few KB Registry Keys to the individual end user PC; this includes the full Oracle Client, which if installed on the PC alone would take up 650+ MB disk space and several thousand Registry Keys, and costly to maintain on the enterprise. Instead our Oracle Client on the PC is about 17KB.
The only “software" on the client side are Registry Keys containing variables pointing to server locations (f.ex. ORACLE_HOME: \<server name>\ORACLE\v10\Ora10g ).
This has been a very cost effective solution we have been using for 10+ years, making all middleware and application software upgrades totally transparent to more than 2000 users Lab wide. Over the years we have done thousands of object upgrades on the central file server without ever having to install a single upgrade on the end user Desktop. Although this has some risks (“thou shall not copy DLLs over the network”, etc.) and is a heavily customized solution, it has worked flawlessly for us throughout for a large number of applications and middleware.
This is a somewhat surprisingly simple solution in today’s advanced technology, but it has been totally efficient and cost effective for us. Several vendors (Citrix and others) have looked at our solution somewhat perplexed, but every vendor of deployment techniques who have seen our deployment has come to the same conclusion, basically: “you do not need us”.
when loading modules you need to keep in mind that:
Once loaded, an assembly can't be unloaded (unless you unload the entire application domain) - so if users can log in and out using the same instance, you may have a problem.
"the load context" matters (see http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx) - this may cause problems if you have dependencies between modules or dependencies on assemblies that are not in the "load context"
If the restricted access to dlls is due to a licensing issue, maybe you need to refine the licensing mechanism somehow (not tie it to access to the actual code, but to some other checks)?

Categories