Trying to use Postman with the OneLogin API to remove the license of users who are no longer with our company, as we didn't have this automated in until recently. Even with the automation we are noticing that it's not taking effect for a large subset of users, who are no longer being synced with OneLogin, and we do not want to re-enable them in our Domain for the sync to occur.
EDIT:
I have a list of the users usernames, but not sure how to get just their OneLogin IDs to use within the API calls.
Related
I am working on a personal project to recreate the news feed of Facebook. So what I am trying to do is to recreate the scenario where when the user goes to the news feed, the user gets posts of everyone he follows only. Is there any way to run a query like that using the Firebase real-time database using an of "followings".
I can successfully generate single users posts in the android studio app using snapshot and recycler view.
If you're asking whether you can get posts from multiple userUID values with a single query, that is not possible.
If you're asking whether you can pass a list of postUID values to retrieve, that is also not possible.
In both cases the solution is to execute a separate query/read operation for each of the values, and merge the results in your application code. This is not nearly as slow as you may think, since Firebase pipelines the requests over a single web socket connection - which is quite efficient. For more on this, see Speed up fetching posts for my social network app by using query instead of observing a single event repeatedly
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'm working on project that sell unique soft products like serials or tickets. To be fast and reliable, we going to use Firebase Real-time Database.
The problem is I want to remove or update the sold ticket after the user get it.
One way to do so is using another server to do so manage the tickets and update the Firebase Database using REST API, but I want to do it with the Firebase only.
Another way to do it, after the user get a ticket, the client side app will sent a remove request. But I'm afraid of losing the data in the middle of this process. A user got a ticket but never removed from the database. As I said the ticket is unique.
How to do it with Firebase side only?
this is a bit of a composite question, I'll try my best to separate the various parts even if they all have a common intent.
Common intent
Having a clear way of delivering notifications about posts regarding specific topics to Firebase Users (and not simply to application instances).
I have tried various methods, and I can't find a definitive answer about which one is the best one.
Method 1 - Relying only on the database
Each Firebase User has its own document in the Firestore at users/{userId}
This document contains two collections: tokens and interests.
The token collection contains a list of documents which have FCM tokens as one of their fields. Each time an user signs in the application or FirebaseInstanceIDService.onTokenRefresh() is called, the collection is updated to add the new token.
The interest collection contains a list of interests which simply are strings and are used as tags for posts. This collection has a mirror as interests/{interestId}/users/{userId} showing all the users interested in something. (This is kept updated and synchronised via a Cloud Function)
When a new post is created under a specific interest, I can get a list of all the users interested and then get their tokens from their document. Finally, I send a notification to each individual token.
Problems
This solution is not elegant (this isn't that big of a problem)
With the new GDPR rules I fear I might not be allowed to save tokens
directly on the Database
If the user signs out when he's offline, the
token isn't removed from his document, and the new user receives
notifications for the old interests.
Should I keep track of what the current token is and update it each time an user signs in ignoring FirebaseInstanceIDService.onTokenRefresh()? Else only the user signed in when the service is called would update the database.
Method 2 - Using FCM topic subscriptions
This should be the best option for me, but I can't understand how to make it work with multiple users on the same phone (always one at a time though)
The way I would handle this is still have the users/{userId}/interests collection, removing users/{userId}/tokens and interests/{interestId}/users, and subscribe/unsubscribe from the various topics as the user signs in and out.
Problems
What happens if the user signs out when he's offline? There is no way to retrieve the current subscriptions and remove each one, potentially resulting in conflicting topics subscriptions.
Thank you very much for your time
My GA Account has a number(50) of profiles associated with it and I am trying to build an api which shows me the basic information like visits, bounce rates etc. for each profile.
This query gets me what I want from GA, but for each profile:
URL ="https://www.google.com/analytics/feeds/data?ids=ga:11111&start-date=2011-07-01&end-date=2011-07-02&metrics=ga:visitors&prettyprint=true&alt=json"
The id is table id and the metrics gives me the information I want.
Now the problem is, I want to show all the information together. So, everytime I will have to send 50 requests to the API, which just doesn't work out. Is there a way I can get the information for all the profiles associated with me in a single request?
You unfortunately will be required to perform 50 requests if you want metrics for 50 different profiles. You can easily automate this, however, by using a combination of the Management API and the Data Export API.
The Management API allows you to pull information about the account. For example, you can very easily pull all profile IDs and names associated with an Analytics account through this API for use in an automated query.
The Data Export API, which I am sure you already are familiar with, is the only way to pull collected data/statistics for individual profiles.
If you are concerned about speed, you might want to build an automated process that uses both the Management API and the Data Export API. Pull all of the profiles associated with your account with the Management API, then loop through each and pull the basic data you'd like through the Data Export API. Have this run at regular intervals based on your needs and cache it between runs. This way it won't execute every time the page is hit (though you honestly might be fine, depending on your traffic - I've found it to be extremely quick).