How exactly can I get access to #LinkedIn Contacts API and Connections API? I would appreciate a list of steps, and probability of success. I have asked LinkedIn help about this and they told me to use StackOverflow. Thanks.
These APIs are private. Nobody can guarantee that you will get access to them, and if you don't have a good reason to have access to them, you almost definitely will not get access.
That being said, there are ways to apply for access. Notably, setting up a business page and creating an app will get you access to non-restricted APIs.
To get access to Contacts and Connections specifically (which are both restricted APIs), you will have to apply for access. Once again, in terms of guaranteeing your application's acceptance, it is impossible to say whether or not (for certain) you will or will not get in.
There is no set of steps that will guarantee access.
Related
I am a developer tasked with an investigation about the LinkedIn APIs. More specifically, I need to be able to get information on a user's connections and I think that the Contacts API would be a good match, since it retrieves a logged-in user's connections and I currently have no means to access the Connections API. The problem is I do not know how to get access to it, as it is not clear enough in the documentation I have read thus far.
I have checked the API documentation and several posts in Stack Overflow about the topic, but I have not been able to find the answer I have been looking for. I have also read through other resources, such as the API Terms of Use and many other forum posts, but with the same result.
On the API documentation, all it says is that "The use of this API is restricted to those developers approved by LinkedIn and subject to applicable data restrictions in their agreements.", however I do not understand where I should apply for approval, as the Contacts API does not seem to be under any of the options I can apply to. Is it possible to apply for it at all?
Thanks in advance
As the title states, I've gotten this email for both projects I've made public on Github. One is a landing page for a local business and the other is a CRUD app I have on the App Store; both of which are using Firebase as the backend.
Is the API key being visible on Github such a security risk?
I've done some research after following the instructions in the email to restrict my API and have heard that you cannot make web service requests with a restricted API key.
I just want to show my repos for the projects for the application process and obviously don't want anything bad to happen with them by doing so.
Aren't Firebase APIs meant to be public?
If so, is it just my database rules that need to be stronger/more verbose?
If any more context is needed, please let me know!
Cheers!
NOTE: I'm still very new to programming so a lot of this is over my head
For Firebase apiKey in a web app you are intended to make this key public, so you should ignore this email -- see: https://stackoverflow.com/a/37484053/771768
Hopefully Best practices for securely using API keys helps.
I'm uncertain as to what you're doing specifically that's resulting in the email but it is warranted.
Please be very careful with API keys.
As the name suggests, these are like keys in that they unlock access to stuff. With digital keys, the additional challenge is that, once obtained, infinite copies of the key may be distributed (and these are usable until the API key is revoked).
There are (often) other (complementary|alternative) ways to authenticate APIs but, as I think you've discovered, sometimes you are required to use API keys.
In the case where they're required, you should endeavor to use complementary authentication mechanisms too in order to try to mitigate overuse and you should continue to be very judicious in your publication of these keys.
I suspect you should not be including (any) keys (ever) in your GitHub repos.
One rule of thumb is that vendors (like Google) use API keys as a way to limit access to (often paid) resources. If the vendor is giving you a key, they're often (not always) using the key as a way to determine how to charge you for an API too. If you're giving the key to others, you're giving other people the possibility of potentially incurring charges on your behalf.
I don't wish to scare you but I would like you to leave this question being very cautious when using keys even if only this causes you to read up more on the consequences of using them.
Woocommerce provides an API here which in order to use it, you have to provide a consumer key and consumer secret with a relevant authorization schema. What I fail to grasp is that, shouldn't be there an API for unauthorized / guest users ? I mean, I just want to create a display page (frontend) of available products, but without the need of generating CK/CS. Also looking in a similar question here
it seems that you cannot avoid using the keys. But a second question comes up. The frontend is not supposed to use the keys, because then the e-shop becomes exposed to the client. So, even by generating these keys in order to access woocommerce api, how am I supposed to correctly use them ? Please help me understand the flow.
TLDR;
Do NOT use CK/CS in front end. It's only for use in a secure backend. The keys can be used to read/write anything from products to, orders to all customer related information.
Based on you questions, I suspect APIs might not be the best way to do what you're intending to do. If you do need APIs, chances are, you have two backend servers communicating with each other. APIs are usually meant for use by other applications. For example, a lot of Point of Sale systems utilize this WooCommerce API. You might want to look into extending the WooCommerce plugin itself and creating end points to get the information or perform actions you need.
If you are not familiar with secure Authenticated APIs, I would highly suggest you familiarize yourself with them as failure to secure the website can result in huge financial losses to sensitive personal information leakage of the site users since WooCommerce APIs, at the time of this writing, only allows you to set read or write permissions with full access to everything.
With that in mind I will attempt to answer all of your questions one by one and give an idea of how you should use it.
To Answer your questions
What I fail to grasp is that, shouldn't be there an API for
unauthorized / guest users ? I mean, I just want to create a display
page (frontend) of available products, but without the need of
generating CK/CS
I'm guessing your misconception is that you need to use separate keys for each user. API keys are not meant to give access for front-end users. The API keys generated by the WooCommerece plugin gives full read/write access to any user to view/modify any information including that of other customers. Its meant for admins. If you check the official WooCommerce API reference for retrieving a customer you'll notice that you get to provide an id here. And if you check the response it shows everything from addresses to contact information.
The frontend is not supposed to use the keys, because then the e-shop
becomes exposed to the client. So, even by generating these keys in
order to access woocommerce api, how am I supposed to correctly use
them ?
Its quite simple actually. You just need to get between the communication between the front-end users and the WooCommerce API. If the users needs to be provided information from the WooCommerce end point, you need to get it for them using the CK/CS.
This way, you confirm what information is allowed to view/modify by whom, and the user does not need to be authenticated.
WooCommerce Endpoints <---> Your secure backend service/middleware/controller <---> front-end user
One thing to note though, is that you need to be careful about the parameters a front-end user is able to change in the request to your server end-point that is consuming the WooCommerce API key. A customer should not be able to change the id that is requesting their info for example. Id should be retrieved from the backend from the secure authentication information coming from the front-end.
I have successfully deployed a Google Cloud Endpoints Developer Portal for my API running on Endpoints. I would like to provide access to testing to people outside my organisation that are not using GCP in their projects.
Login to the portal works correctly if I enable the Service Consumer role for these people (on per-email basis). However, when they open it for the first time, they are being asked to grant some extra permissions to the portal:
This form can create totally unnecessary security concerns. Does anyone know, why is it needed?
I only would like my clients to be able to test my API using a GUI, before they could start connecting their projects (not necessary on GCP) to mine. This seems to be a valid use case for me, however I might be misunderstanding some basic concepts.
Or should I submit a feature request to Google about a new role that only enables the access to the portal, and nothing else, so no such forms are shown?
Since Endpoints APIs must be explicitly shared with customers, the portal needs to verify that the logged-in user has permission to view that Endpoints API. So the short answer is that these scopes are being requested primarily so the portal can check the user's access to this API.
Longer answer is that we (the Endpoints team) are looking into if it's possible to build narrower OAuth scopes that would correspond to the access checks we perform. We agree that it's unnecessarily broad of an access request and are hoping to improve this in the future. Thanks for your comment!
What's the best way to set permissions on objects in Apigee BAAS entities, collections in such a way that Users can edit what they create, and others can read them? There might be a case for Admins to be able to edit everything as well.
I asked a similar question here Securing apigee baas that was more around securing the app id/secret which would be needed to make the call to update permissions, but I was wondering if there is any best practice around doing this sort of thing from a mobile application.
My initial thought would still be the service callout (not sure how Apigee-127 which was mentioned in the previous question would be any different to a service callout directly to the BAAS as to me 127 looks like I'm just writing my apis in Node.js rather than using the edge console), but I don't know if there is an easier way in terms of securing all entities, in specific collections ,created by specific users? I guess I could add a created by column which I could check from an app perspective, but this wouldn't stop someone from potentially hitting the BAAS directly and retrieving this info unless permissions are also set at an entity level requiring a user access token.
Is it possible to secure the BAAS in such a way that only calls from Edge can hit the BAAS url?
(Disclaimer: I have not tried this myself but here is a suggestion.)
API BaaS Automatically sets the path segment to the UUID of the currently authenticated user when $user is used. For example, if you sent a request with a valid access token for a user with UUID bd397ea1-a71c-3249-8a4c-62fd53c78ce7, the path /users/${user} would be interpreted as /users/bd397ea1-a71c-3249-8a4c-62fd53c78ce7, assigning the permission only to that user entity.
In this way, through your application, you can set permission for each user, and each object as soon as the objects are created from your application. Assuming you have the user authenticated, of course.
Ref: http://apigee.com/docs/api-baas/content/using-permissions