I'm using application insights to get telemetry data off of my servers, but there is one server linked to my insights ID that i don't have access to, and it is giving me all sorts of bogus data. How do i filter out all of the telemetry from that server so that it doesn't appear alongside any of my other telemetry responses?
I know i can go into analytics and filter servers out there, but I'm talking about the main metrics page, the one that sends out alerts, shows a general overview of the servers, etc.
In short, there's no easy way to do it. you'd have to edit the filters on every part on every place in order to customize them, and pin those customized versions to dashboards and never look at the default experiences again.
How is there a server sending telemetry using your key you don't have access to? is it somewhere else where someone made a copy/paste error and somehow used your key?
i believe you can contact support and have them generate a new instrumentation key for that resource. then you'd update the places you do have under your control to use the new ikey, and the thing not under your control would still be using the old, now invalid key.
Related
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.
Imagine the following situation. I have an API and a developer builds an application that retrieves new content from it on a daily base. She stores this content and provides this data to all the instances of an app she developed. In this way these apps do not have to call the API directly.
Is there a way to prevent this and force the apps (and therefore the end users) to use the API and not only the application on the server.
I found many questions about how to cache API data but not how to prevent that. I am fairly new to this, so maybe I am overlooking something or maybe it is not possible to prevent this.
Thank you in advance!
Assuming you are using Apigee for API-management, you have some options. First, consider the options available to you contractually, if this is that sort of business relationship and you can impose certain API behavior with a business partner through a contract.
Separate from the legal side of things, we remember that you control your API and the credentials you issue for use by your API clients. You cannot though control, practically, what a client developer does with the credentials you issue: she could promise to embed the credentials in the mobile apps' API client, but change her mind and use it centrally, and then design her mobile client to call into her central cache. If though you really insist that only mobile app clients should be calling your API and not a hub/cache server, then you could consider applying constraint policies on your API (within the Apigee proxy, such as Access Control). For instance, you could blacklist your partner's hub/cache server IP address, although that is weak security at best. Or, you could apply a constraint that only clients with certain identifying User-Agent strings (mobile OS, client) are allowed to connect to your API. Or use GeoIP filtering to allow only clients from certain regions, if that applies to your use-case.
Finally, depending on the data model, you might be able to rate-limit such that a bulk cache becomes impractical: if your edge-client use-cases is to fetch a single record, but a cache would have to hold thousands of records, then you could impose a per-client rate limit (Quota policy) which is no bother to individual mobile clients, but makes the work of a hub/cache server untenable.
Is it possible to get user telemetry (like number of unique users) by only configuring application insights to be in ASP.NET Core Startup.cs without adding the telemetry javascript to webpages?
Do requests telemetry enable us to know the number of unique users from both mobile app and webpage or the information about users is limited to applicationinsights javascript?
Actually, you can do this in a limited way without javascript.
You'd be limited to whatever information you collect from the inbound requests, which would include location information (derived from client ip address, which will only be used for geolocation, then thrown away), and whatever limited user/session information the server generates for you, and asp.net (including core) does do some of that already.
Application Insights uses the full incoming address (if there is one) to do geolocation, and then (as of ~Feb 2018) throws away the ip address.
Well, binary answer is No.
As client side telemetry need to be captured in client browser - JS option is the only choice. Requests & other telemetry can give you server side data but user specific data still need ai.js
Otherwise you can have audit on your own in addition to your authentication/authorization implementation.
Update:
John & James pointed out some useful info & links to achieve this from server side too.
I am about to start working on the back-end for a mobile app (initially iOS/Android, later also website) and I am thinking whether Realm could fulfill all my needs.
The basic idea is that there are two types of users - customers and service-providers. The customers send requests to the server once in a while and are subscribed (real-time) for any event that might occur in relation to this request in the future. Each service-provider is listening for specific requests from all customers and is the one who is going to trigger various events (send data) for each of those requests.
From the Realm docs, it is obvious that the real-time data sync is not going to be a problem. The thing I am concerned about is how to model the scenario (customer/service-provider) in the Realm 'world'. Based on what I read, it is preferred to have one realm per user. Therefore, I suppose the user will register and will be given a realm. Then whenever he makes a request, it is going to be stored in his realm. Now the question is how to model the service-provider. There are going to be various service-providers each responding (triggering various kinds of events up to one hour after request) to different kinds of requests. (Each user can send any request and therefore be served by any service-provider.)
I read a bit about that Realm supports data sharing among different realms which could be a partial solution for this problem, however I was not able to find if this 'sharing' could share only particular requests. (Meaning each service-provider will get only requests intended for him.)
My question is whether this scenario is doable using Realm?
This sounds like a perfect fit for Realm's server-side event-handling. Put simply, Realm offers the ability through our Node SDK to listen for changes across Realms on the server.
So in your example, where each mobile user would have their own Realm, the URL for this would be /~/myRealm in which the tilde represents the Realm user ID. The Node SDK event handling API allows you to register a JS function that will run in response to changes represented by a Regex pattern for Realm URLs. In this case you could use: ^/([0-9a-f]+)/myRealm so that any time any user's myRealm updated, the server could perform some logic.
In this manner, the server via the Node SDK is really a "super-user" or service-provider as you describe. When an event fires, the JS function that runs is provided the Realm that was updated and a list of indexes pertaining to the objects in the Realm that were inserted, deleted, or modified. You can then perform any logic in JS, such as using the changed data to call out to another API or opening the Realm in question or any other and writing changes which will get pushed back out to the respective clients.
The full server-side event handling is part of Realm Professional Edition, but we recently released another way to interact with this called Realm Functions. This provides the ability through the server's dashboard to create the same JS functions that will run in response to changes across Realms. The developer edition support 3 functions so you can try it out immediately!
I have a WordPress website with custom tables that I store data into that was entered by customers. The site owner wants to develop a barcode app that can access this data. When I need the data from these fields to display within the site, I request it from a PHP script running on the server that make calls like get_post_meta().
The owner has hired a mobile app consultant who believes that, if he just has the password to the account where the site is hosted, he can access all of these database fields from the app.
I'm not seeing how this is possible. My understanding is that a mobile app can only access a site by making HTTP requests to it. It has no way of running on the server and executing things like get_post_meta().
Am I missing something?
Thanks
I think you are missing something. Wordpress now has a rest api https://developer.wordpress.org/rest-api/ that can allow a mobile application get at data in your database by making http requests.
The developer will need to be able to enable the Rest Api, but if you give her the password, she will probably be able to do so. Typically this is done using a plugin like: WP Rest API which enables a set of default endpoints which includes post meta data and allows you to add other endpoints
Depending on how the custom tables are set up, they might not be automatically available to the Rest API. However, if you are able to access them using get_post_meta() then I would expect that they would be accessible to the Rest API as well, most likely by adding endpoints.