so I'm wondering what does API-facing code mean? I have been googling it, but I can only see sentences with it, but not explanation for it...
Context: "The code supporting this article has been provided as a single Android app for illustrative purposes. In practice you should not distribute your server-side API keys in an Android app as your key cannot be secured against unauthorised access from a third party. Instead, to secure your keys you should deploy the API-facing code as a server-side proxy and have your Android app send requests via the proxy, ensuring requests are authorized."
Can you explain to me what API-facing code means? Thank you and I'm looking forward to your reply!
In this context, "API-facing code" is the code that interacts with the API. They are suggesting the creation of a server component (proxy) that sits between Android and the API, so that the key does not need to be distributed with the Android app. (Instead the "in-between" piece on the server holds the key.)
Related
This may be a very simple issue but is (I think) complex to explain so, please bear with me.
We have a WCF API (written in C#) on our server which attaches to third-party APIs (a sort of one-stop place, if you will). These use a mixture of OAuth and certificates for security. The idea is that we don't have to put (the third party) certificates / security on all of our servers, just the one.
Therefore, the plan is for an application on one server to call the API on this server which calls the third-party API. This seems to work for all but one third-party.
If I use the Visual Studio (2017) inbuilt WCF Test Client on our API, it works fine. If I try to use our API from another application (by adding a service reference) even on the same server it fails with the above message.
Our API does not (yet) use https.
The plan is for use to release our API to others so we can't share any certificates / logins with them - this is the underlying reason for our API.
I have done a lot of Googling about this and all of the answers seems to point to the certificate has to be on the calling application which would seem to defeat the object of our "catch all" API
I have probably not explained this very well - sorry. Maybe the issue could be summed up as "how do I stop the security being "passed down" to the calling application?"
Seems that the culprit was the Application Pool Identity that "Our" API was running under. I changed that and now everything works as I would expect it to :)
I'm completing a python grpc server function-wise and being ready for deployment. Thusfar I have unsecure communication (pretty much the helloworld example when it comes to security). I thought I could put in place an authentication mechanism for my server in a reasonable amount of time after I observed that there was some documentation on this very topic provided by google. Closer investigation let me to believe otherwise.
The case is simple: Users (fellow colleagues of mine) login to their company mail (gmail) and use the resulting token (JWT, OAuth, OAuth2, I don't care) to gain access to the grpc server I wrote. No one else gets in.
Since googling grpc+authentication has been fruitless so far I believe I'm on the wrong track on how I should approach this kind of problem. So therefore the questions:
Given this use case, should my grpc server have any concern with authentication? If so, are there examples? Or should this be handled by a different system? If so, what system?
I noticed a lot of articles mentioning Envoy+gRPC. Can Envoy help me out here? Is it designed to deal with this?
The gRPC authentication can follow the same approach of a normal HTTP, the only thing you need to have in mind is that the authentication check would be placed in an gRPC interceptor and you will be looking at the metadata to get the creadentials. Unfortunately, I don't have an example to do it with Python but you can search in "how to add gRPC Server interceptors in Python" and then "how to work with gRPC metadata in Python"
Here an example in Golang, maybe it can give you the idea
I am building a Xamarin iOS Native project for a iPhone app and i am using Google Maps for creating Routes to several delivery points.
I registered for the Google Maps API but i have troubles with the security of the API key.
In my project i have installed the Nugget package for Xamarin.Google.iOS.Maps and set the App restrictions to my iOS Bundle name. When initializing the MAP all works fine.
BUT we also use the Direction API for setting up routes to different points of the map. But this call function method is a HttpClient call to a JsonAsync call. The Google API denies the call because it did not work with the Bundle name because its a HtppClient Call.
The project is installed on Mobile devices so restricting with a IP address is not a option for us. No restriction AT ALL is also bad for the security.
So my question is : How do I secure this?
Please note that web services cannot work with API keys that are Android/iOS restricted. Web services are server-side and can only work with API keys that are either unrestricted or restricted by IP address.
To resolve your issue, please create a second API key to use for web service requests only.
The public docs on best practices when using API keys has also some suggestions for when IP address restrictions are impractical as with the case with mobile applications.
When using Maps Web Service APIs in these scenarios, secure your apps using one or more of the following techniques:
-proxy server
-obfuscation
-pinning
References:
https://developers.google.com/maps/api-key-best-practices#api_key_table_sup_5
https://developers.google.com/maps/api-key-best-practices#proxy_server
I am trying to implement Docusign in my application for digital signature. I am using .net core 2.0 for development purpose. I found that the Docusign SDK(https://www.nuget.org/packages/DocuSign.eSign.dll/) is not compatible with .net core so I tried with the other one (https://www.nuget.org/packages/DocuSign.Core). The general signature request is working fine but when it comes to Embedded Signing, there is no method available in the SDK(but is available in the original SDK). I am using REST API to complete Embedded signing process and is working fine for now.
Now I want to keep track the status of the document(like when it is delivered, when it is signed by signers and so on). I am configuring webhook to accomplish this task but not getting the webhook object in the webhook endpoint. I referred few documents ("https://github.com/docusign/recipe-010-webhook-csharp/blob/master/Webhook/Controllers/WebhookController.cs", "https://developers.docusign.com/esign-rest-api/code-examples/webhook-status",
"https://www.docusign.com/blog/dsdev-msbuild2018-session-thr2605/") to see how a webhook works but looks like none of them is working. In the examples, everyone is getting the webhook object inside request content(request.Content.ReadAsStreamAsync()) but I am getting null at Content.
Can someone help me out to resolve this issue. A sample code or helpful documents(apart from the one I am referring) would be great.
Thank you.
Re: .Net Core SDK support -- we hear you and we're working on it.
Re: webhook setup --
How are you creating the webhook subscription? Via the Administration tool or via the eventNotification object in the Envelopes::create call?
To get going, I'd suggest using the Administration tool. Use the Connect screen to add a webhook notification subscription to your server (your "listener"). Then you'll receive notifications for the events you've indicated an interest in.
Your server must support https and be available on the public internet so DocuSign can send POST requests to it.
I am new to PowerApps development. I am trying to connect PowerApps to my custom APIs (Azure app api) and getting results of "resource not found". I can call the api from browsers, postman no problem. The .json file I use for PowerApps is the same as the one I use for editor.swagger.io (for testing). I checked the log file of the application on azure, all of the requests from browsers logged but not the ones from PowerApps. My question is, how PowerApps calls APIs and what is the right format of the .json file used for PowerApps app?
Thank you.
I would recommend trying again, we had a small issue on our backend that was causing some 404's at times. A fix for it has been deployed so you might see it work.
PowerApps uses Swagger to determine the shape of the REST api to be able to project those APIs into "formulas" that can be used easily in the client.
Also, for development/troubleshooting purposes I highly recommend using Fiddler to see exactly the REST call that PowerApps is doing and making sure the URL and parameters are correct. If not then look into your swagger definition and make sure there are no issues with the paths provided there.
You might also check that your Azure App API has either:
The PowerApps IP Addresses Whitelisted OR
If available, the "Allow Access to Azure Services" option toggled
When building Azure SQL backends for PowerApps, one of these paths must be followed.