I'm fairly new at building Electron apps and I've seen a lot of examples where Electron app connects directly to a remote database (MySQL in my case) so I started wondering what the problems might be with doing it that way. My first thought was to have a remote API (built on top of Express) which would communicate with the database and Electron app (React) would just utilize that API.
Any advice? Thoughts?
Thanks.
A problem with directly connecting to the database is you have to embed the database credentials in the electron app which makes them available to anyone who wants to snoop through the code. In addition, once the credentials are exposed, you lose control over what anyone can do to your database.
This is why you would usually give the user their own credentials, have the user authenticate to a web server and then have the web server be the only one who can directly talk to the remote database. You can then completely control what happens to the database since your web server is the intermediary and the only one that actually talks to the database.
This doesn't mean that there aren't some circumstances where you might want the client to talk directly to the database as it really depends upon what you're doing, what the data is and what the risk exposure is for allowing untrusted code to directly manipulate the data in the database.
Remember, you cannot protect credentials embedded in a client. They can be discovered by the client and used for other things.
Related
I just started on a new Electron project that needs to access a database, e.g. SQLite. The database will be on a shared drive that should be accessed by the Electron app.
To do that, I need to provide the path as well as the password for the database to the Electron app. Since it's desktop application, I deliver the whole application incl. the database credentials to the user.
From my point of view, this is not a good approach from a security perpective.
So the question is, where do I store these details, especially the credentials?
The same issue applies if I use e.g. another database like MySQL. There, I also need to store the host and the credentials.
I am currently in the process of creating a website, and I am now in the phase of trying to create a registration database. Currently, I have the databse running through localhost, using phpmyadmin and mySQL. But, when I publish the website itself, I want for each person, when they register, for their information to go to a database. I am quite new to database design and development, so I was wondering about how I should go about doing this? At the current moment, given its setup, I am sure that there will be an error caused if someone else tries to submit their information into the registration page because their computer is not holding the server. How may I resolve this? I hope that my question was clear...
I already have php code that sends the registration info to the database, but I know that it will only work on my computer.
The browser runs on the user's computer
The HTTP server runs on a hosting computer
The database server runs on a hosting computer
These can all be the same computer (and in the development environment you've described: they are).
When you deploy it to a production environment, the HTTP server will be public facing. The user's browser can connect to it from anywhere* on the Internet.
Since the HTTP server runs the PHP which talks to the database server, it doesn't matter that the database isn't stored on the end user's computer.
* Issues such as the great firewall of china aside
As of your comment, D_A, I would say that your registration system should work fine.
PHP code may contain "localhost" But you are sending request from "Form" submit or JS. Which makes request in URL. For example:
http://example.com/register?name=x
I'm new to Federation Services and I'm trying to understand how ADFS works as a whole and I've started to get down into the details. I followed along with creating an app using OIDC to authenticate a user, however, within the tutorial, they specified using a "Server Application" when setting up an Application Group. This ended up not working for me so I tried setting up a "Native Application" application group for kicks and was able to successfully login.
The thing that threw me off is, I ended up hosting ADFS on a server outside of the domain in which I had my application running, so I'm confused as to how that is "native" in terms of ADFS.
I went looking for this answer within microsoft's documentation but I didn't find the information very clear.
Native Application:
"Sometimes called a public client, this is intended to be a client app that runs on a pc or device and with which the user interacts."
Server Application:
"A web application that runs on a server and is generally accessible to users via a browser. Because it is capable of maintaining its own client 'secret' or credential, it is sometimes called a confidential client."
This may seem simple to some, but I'm trying to really get a grip on what would be used when. To me it sounds like a native application is used when you're running the application natively on a pc in which the user is also using the same pc, and the server application is run remotely in which the user would not be using the same machine. Is it really that simple or am I misunderstanding?
A native application (in Microsoft speak) is something that is not browser based e.g. mobile. The code runs client side. It may use JavaScript in which case the secret key is publicly accessible. (The secret key is one of the OAuth parameters). You use ADAL / MSAL to access it.
A server application runs server side e.g a web API. The secret key is not publicly accessible. You use OWIN to access it.
These terms have no relevance to where ADFS is actually installed. Native applications typically are not domain joined.
I'm trying to write an iOS app using Xcode.
A simple login prompting username and password.
I have no idea how to open a database connection to validate the username and password.
The database I use is mysql.
I tried using this link http://macbug.org/macosxsample/mysql#.Ur8AYBbtGPF
but I get an error when I tried to add libmysqlclient.a to the frameworks and library.
If your database is on a server somewhere, then you would generally not have your iOS app interact directly with the database server, but rather you would write a web service that the app would interact with (via NSURLConnection, NSURLSession or something like AFNetworking), and the web service would interact with the MySQL database.
In terms of how to write a web service, often, when people are writing their first web service, they'll use some simple technology like PHP. Do you know what options you have on your server? If PHP is an option, then you can check out Ray Wenderlich's How to Write a Simple PHP/MySQL Web Service. Then check out How to Write an iOS App that Uses a Web Service.
You should use SQLite instead of MySQL for iOS application. You are referring MacOSX application tutorial. try this http://www.raywenderlich.com/913/sqlite-tutorial-for-ios-making-our-app
Ive done a fair amount of searching on this, but ive struggled to find the answer.
At present I have an access program that sits on a remote windows 2008 server and users can log into it through a remote app. In the local version of my program, users can hit a button and email through outlook, but obviously if your accessing it remotely it tries to open outlook remotely.
So here's the question: Is there any functionality that will allow me to open Outlook locally whilst using the remote app?
Ive read about scriptable virtual channels but i would like someone to confirm if this is possible (or call me a moron for even contemplating the idea).
Thanks in advance.
Split the database. Your client will then open Outlook locally.
Here is some info that might be helpful if you do not know how to split the database and what the benefits are: http://office.microsoft.com/en-us/access-help/split-an-access-database-HA010342026.aspx