Implementing Google Contacts in WPF App
-
I'm working on a WPF app that will connect to Google and retrieve contacts. Right now, the Google key info is all hardcoded unencrypted into the app and is a security risk. I'd like to refactor this so that the key is not compiled in. One idea we had was to make a backend call to our server to retrieve the key, then use it to connect to Google. What's the right way to do this?
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
-
I'm working on a WPF app that will connect to Google and retrieve contacts. Right now, the Google key info is all hardcoded unencrypted into the app and is a security risk. I'd like to refactor this so that the key is not compiled in. One idea we had was to make a backend call to our server to retrieve the key, then use it to connect to Google. What's the right way to do this?
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
The server connects to / queries Google; the client makes the Google request via the server.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
The server connects to / queries Google; the client makes the Google request via the server.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
OK. THe issue is that the Security Key & Secret are stored local in the client. They have to be passed. I'm asking about how to design this for security
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
-
OK. THe issue is that the Security Key & Secret are stored local in the client. They have to be passed. I'm asking about how to design this for security
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
But if the key is shared, shouldn't it be on the server? You route the queries through the server; the query runs from the server; the client never needs to see the key; only the results.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
But if the key is shared, shouldn't it be on the server? You route the queries through the server; the query runs from the server; the client never needs to see the key; only the results.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
You pass a Key and Secret to the server. We're trying to avoid this
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
-
You pass a Key and Secret to the server. We're trying to avoid this
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
Where do I say pass the key? Put the key on the server. Why do you have a server? The client queries the server; the server queries Google and whatever else, and returns the result to the client. It acts like a proxy or a firewall. If you think "2 hops" is an issue, that's another matter, and only if you benchmark it and it says so.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
Where do I say pass the key? Put the key on the server. Why do you have a server? The client queries the server; the server queries Google and whatever else, and returns the result to the client. It acts like a proxy or a firewall. If you think "2 hops" is an issue, that's another matter, and only if you benchmark it and it says so.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
Gerry Schmitz wrote:
The client queries the server; the server queries Google
It's a WPF app. It's calling the Google People API directly. The Secret and Key are hardcoded as constants in the C# code. The app directly queries the Google API passing the Secret and Key. But that's what I said in my OP. We could store the Key & Secret on our sever and add an endpoint to simply return them, therefore removing them from the WPF app's code. The client app would still call the Google API directly passing the Secret and Key, it would just first, on app start, go to OUR server to get them, instead of them being in the code. Old
- App starts
- App calls Google API, passing hardcoded Key & Secret
New
- App starts
- App calls OUR server, which returns the Key & Secret, and stores them
- App calls Google API, passing the stored Key & Secret
Again, the ultimate goal is to get the Secret & Key out of the code.
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
-
Gerry Schmitz wrote:
The client queries the server; the server queries Google
It's a WPF app. It's calling the Google People API directly. The Secret and Key are hardcoded as constants in the C# code. The app directly queries the Google API passing the Secret and Key. But that's what I said in my OP. We could store the Key & Secret on our sever and add an endpoint to simply return them, therefore removing them from the WPF app's code. The client app would still call the Google API directly passing the Secret and Key, it would just first, on app start, go to OUR server to get them, instead of them being in the code. Old
- App starts
- App calls Google API, passing hardcoded Key & Secret
New
- App starts
- App calls OUR server, which returns the Key & Secret, and stores them
- App calls Google API, passing the stored Key & Secret
Again, the ultimate goal is to get the Secret & Key out of the code.
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
Wpf <-> internet <-> server <-> internet <-> Google; UPS; USPS; VISA; etc. I have WPF apps, running as kiosks, calling into my (ASP.NET) web server that has "no presence" other than to handle client requests), that calls multiple API's for credit card verification, postal rates, address verification, and retrieving shipping label images; all using different accounts and passwords "stored on the server" along with "back end code" and an SQL data base. Does that help? (Sounds like you have a simple / local "file server"; and not a remote / distributed application / database / web server).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
But if the key is shared, shouldn't it be on the server? You route the queries through the server; the query runs from the server; the client never needs to see the key; only the results.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
Organize, review, and merge your contacts. Create personal mailing lists. Quickly send messages to groups of people you contact the most, without entering their addresses individually. With Google Contacts, it's easy to keep all your contact information in one place and reach several people at once.
-
I'm working on a WPF app that will connect to Google and retrieve contacts. Right now, the Google key info is all hardcoded unencrypted into the app and is a security risk. I'd like to refactor this so that the key is not compiled in. One idea we had was to make a backend call to our server to retrieve the key, then use it to connect to Google. What's the right way to do this?
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
Seems like the other thread has a miscommunication. Your current app has the credential information in the client code. The type of credential information is irrelevant. The credential information is hard-coded because you stated that. (That means every actual user of the client will be using the same exact credentials.) So the other solution is to modify the code to do the following 1. Create a server API method that expects a requests from the client code. The client code does NOT make a call to google. The client code does not have the credentials. 2. The server code API uses the credentials and makes the call to google. 3. The server code returns the result of the google code to the client. Note in the above that I did not specify where the server code gets the credentials from. Could be it still hard-coded but in the server code. There are other possible solutions to providing the credentials to the server code.