eg from their site
{
"access_token": "access-sandbox-de3ce8ef-33f8-452c-a685-8671031fc0f6",
"item_id": "M5eVJqLnv3tbzdngLDp9FL5OlDNxlNhlE55op",
"request_id": "Aim3b"
}
My question is what is "item_id" and why it keeps changing on repeated requests. I understand that "access_token" to change on repeated requests.
This is what Plaid documentation says
"item_id - string
The item_id value of the Item associated with the returned access_token"
How what should I treat this Item_Id as? InstitutionID?
Is the item_id actually changing across multiple consecutive API requests, or only if you link an account multiple times? It is normal and correct for you to get different item_ids if you link the same bank account multiple times. Two linked accounts are considered different items even if they are actually based on the same user credentials at the same institution.
An item_id is an identifier associated with an item. It is less sensitive than an access token, because it cannot be used to access any data. So it is used as a safer way of referring to an item across the Plaid API than passing the access token around. For example, webhooks that give information about a change to an item will include an item_id to let you know which item the webhook is about.
Related
I am working on a function that allows a user to check if their existing device contacts are using our platform, based on phone numbers.
For privacy and security, we are hashing the user's contact's phone numbers on device (salted with the user's id) before sending to our server.
Server side, we then need to hash our entire contacts table (using the user's id as a salt), which is currently being done in a for loop.
We then check this list against the request list, and return the details for any matches.
However, I'm sure there is a more efficient way of doing this, something like computing the hash in a calculated field then including the $request->hashes in a "whereIn" clause.
Could someone give me a pointer on the best approach to be taking here?
The question is, what privacy and security are you achieving by sending hashed value of contact number?
You are hasing the contact in client side(device), that means you are using a key and salt that is available in clinet side already. How can that be a security feature?
If you want to search hashed value in database then it's better to save hashed contract number in a column in the first place. So you can directly run where query in database table.
Ideally, if you really concern about user's contact number you should:
Encrypt the user's contacts in backend/databse not in frontend.
If you need to query for a field in database then you should make a hash valued column that can be matched easily. I mean searchable fields should be hashed so you can run direct query.
Nothing to worry about user's contact security in frontend if you are already passing it trhough Secure HTTP(HTTPS).
Even it a common practice in the industry, to pass a submitted plain password via HTTPS when a user submit it in frontend. It shouln't be a concern of privacy or security.
In the Preventing duplicate Items article, it mentions that you can use a specific combination of fields to determine if there are duplicate items or not. And specifically OAuth institutions, it says the combination of fields are: customer's user ID and institution_id. I'm confused what the customer's user ID is. I'm not familiar with this identifier. Can somebody explain?
The customer's user ID would be a value in your own application's business logic, not part of the Plaid API. In most Plaid use cases, alongside an Item, you would typically store some kind of user id that associates it with a specific user in your system. The logic here is saying that if the same end user in your system has multiple Items with the same institution, they are probably duplicate Items.
I have a website:
10,000 pages, each page represent a category, for example: "Laptops".
On each page I am showing 20 recommended products
99% of the users are anonymous
For each user I have a context (device, user-agent and category)
For each product I have the price and the seller name
I have 2 events: outbound & purchase
I would like to re-rank (re-order, sort) the results for each new anonymous user based on the user context. I would like to re-rank based on performance (outbound & purchase).
Do you have recommendation for Specific algorithm OR tool OR service to do that? I found AWS Personalize very nice but the problem is that all of my users are anonymous so I don't believe it can be effective in my use case.
Amazon Personalize can still be used effectively when most/all users are anonymous. If you track users as visitors using a cookie or local storage, then a visitor's session ID can be considered the userId in Personalize. You will lose the continuity of stitching together the same logical user's activity across multiple sessions but you can still get in-session personalization. This requires calling PutEvents with the visitor's session ID in the sessionId field and excluding the userId field. Then when calling the GetRecommendations or GetPersonalizedRanking APIs, use the visitor's session ID as the userId field. Personalize will consider the event activity for the visitor's session when providing recommendations or reranking items.
If the visitor is a known user or later becomes known (i.e. signs in or creates an account), then pass their user ID in the userId field for PutEvents and GetRecommendations/GetPersonalizedRanking. At the next training, Personalize will associate any prior anonymous events (i.e. those with a sessionId but not a userId) to the user. The key is using a consistent sessionId across the anonymous and known events for the user for the session.
Is there any way how to uniquely identify user who caused an event? I want to extract all events from Appsactivity service, which belongs to specific user.
The problem is, that service.activities().list() returns also activities of other users of shared file, even if this request has set userId which indicates the user to return activity for. It returns all visible activities to given user and therefore it contains activities of other users.
I tried to filter list, but it seems to be impossible - events contains simple User object which does not have userId or userEmail.
One way is to compare user's photo url which is avalaible in appactivity User object. Note, that this can be done only if url is not null, otherwise it won't uniquely identify user.
I'm trying to build a simple reviews site for a very specific search parameter, which I can pull information back from Google Places API. I understand I cannot store any information other than what Google says I can, and it sounds like I can only store the "reference" parameter and the "id" parameter.
Upon creation of a review for a place returned from Google, I need to store some identifier so that when someone else searches Google Places through my site, I can do an AJAX call to my DB and pull all reviews for that Place.
Ultimately, my question is, which key should I store? Or both?
As per the documentation:
id contains a unique stable identifier denoting this place. This
identifier may not be used to retrieve information about this place,
but is guaranteed to be valid across sessions. It can be used to
consolidate data about this Place, and to verify the identity of a
Place across separate searches.
reference contains a unique token that you can use to retrieve
additional information about this place in a Place Details request.
You can store this token and use it at any time in future to refresh
cached data about this Place, but the same token is not guaranteed to
be returned for any given Place across different searches.
It would make sense to store both, reference to retrieve reviews from Google Places and id to group your place reviews in your db.
As of June 24, 2014 the id and reference fields are deprecated. placeId (for requests) and place_id (in responses) should be used instead.
The Places API currently returns a place_id in all responses, and accepts a placeid in the Place Details and Place Delete requests. Soon after June 24, 2015, the API will stop returning the id and reference fields in responses. Some time later, the API will no longer accept the reference in requests. We recommend that you update your code to use the new place ID instead of id and reference as soon as possible.