I'm following the Quick Start Guide, as I've just received my credentials. I went through the coblogin and user (consumer) creation successfully. For test purposes, I was able to search and list sites and infos.
When I try to invoke addSiteAccount1 using the user session token for the consumer that I create, I get an HTTP 200 response and no apparent error, no exceptions or messages. The JSON response is basically the same as the one listed in the API documentation page, however there's no ID I can use to list transactions. I'm using a real login/password account information on Chase (site ID 643).
By the way, if I use random strings for credentialFields[0].value (username) and credentialFields[1].value (password), I get the same JSON response.
Please help me clarify what is not working here.
addSiteAccount1 API will give you a response which should contain "siteAccountId" field this is the identifier for that particular user's Chase bank site.
This siteAccountId will have itemIDs which resembles different 'container'(in Yodlee terminology) like, all saving and checking accounts comes under bank container,while credit card comes under credit's container similarly loan and mortgages are other containers.
Now even under a specific container you might have multiple accounts for e.g., Chase Bank container you might have 1 saving's account and 1 checking account, for each there will be an itemAccountId available. This uniquely identifies that specific account and you can pass this itemAccountId (which you can get from getItemSummariesForSite API) in executeUserSearchRequest API to get the transactions belongs to this specific account.
For further help here is the link for the API flow which will give you an idea about how and when to use different APIs.
OK, I think I got it working, but maybe some documentation clarification is needed. Provided that all mandatory parameters in the addSiteAccount1 are present and contain no errors, the method call will be successful for a given consumer.
I then visited the getAllSiteAccounts method, which would show me all account aggregation for that user/consumer. I was able to see all accounts added, some had a message like "REFRESH_COMPLETE" and others would have "AUTH_FAILED". It seems that once one adds an account, the Yodlee robots will try to login and then synchronize the data for a given account. Makes sense?
I was only able to verify if the bank credentials were OK by calling another method.
Related
Currently I am developing a Chrome-GMAIL extension which requires me to get the logged in user's first and last names. For experimentation, I have used the following goggle API (userinfo) and have successfully obtained the names I wanted:
https://www.googleapis.com/auth/userinfo.profile
However, using the userinfo APIs will cause a change in the OAuth2 scopes in my manifest. This change will in turn cause a permission-prompt to my existing users (if a domain wide delegation is not setup in place). Point being the idea of having more prompts in front of my user, or additional oauth scope is not really something I desire.
Currently our extensions use the following OAuth scopes and API :
Chrome's Identity API
Chrome's Storage API
GMAIL.modify
GMAIL.send
My question is, is it possible to get the first and last names using an API that is defined/allowed/provided for by any of the above scopes/permissions I listed? or is userinfo the only way to go?
Thank you very much.
Profile data like first name and last name is private data. You are corect that some Google apis give you access to some data that would normally require an extra scope. For email normally you would need to to request the email scope to get this back however the Gmail api does have an endpoint getprofile which will return the current users email address without you requesting the email scope.
However i am not aware of any apis that will give you access to the users first and last name without you requesting the profile or user.profile scope.
If you do decide to add the scope, I do recommend going though the people api rather then the userinfo endpoint as the data returned by the user info endpoint is not guaranteed to always return the name.
We'd like to extend our quota limit from 1kk to around 20kk. We were already hitting limits, so we lowered frequency of our requests, and submitted https://services.google.com/fb/forms/ytapiquotarequest/. We have filled the from thoroughly and sent it three times, always with negative response from google:
Your quota extension application cannot be processed at this time
because of the following reasons:
Bad data (invalid project number)
As it says in the form:
The project number is a series of digits that can be found alongside
the Project ID in your Google Cloud Console. Please comma separate
the project numbers without additional spaces
There is only one numeric Project ID we have. When I tried fill in the alphabetic one, we received :
Project ID supplied does not exist.
When contacted Google Cloud Support, they told us that it is probably some bot who is answering this request, hence the generic answer. As well they directed us here: maybe someone of you had similar problem?
Perhaps they wish you to use the item the arrow is pointing at in the image below.
Go to Iam & Admin >> Settings
Here is what I am planning to to for keeping separate tokens for web and mobile
1.When user is logged in from web JWT token is issued and it is stored in DB table with created time stamp.
The above step is repeated for the mobile client ,so the table contains separate tokens for each client.
2.At the time of validation search for the token in table and validate if exists then it will try to verify with JWT.verify
Is it right method to do keeping separate logins using JWT??
Maybe there are other ways to do it, but your approach is totally correct. By fact I would recommend it exactly your way. What you doing, is scoping issued token for specific service, platform. It is useful not only for your use case, but also when you have multiple APIs. You can issue different tokens for each service separately.
I'm working on a project that consumes Service Now API (Rest). To do so our client has registered us as a user in order to login and make all service calls we need to. This project has an interface where users can login once they have an account on Service Now as well, the username they type to log in has nothing to do with service now by the way, but later they associate theirs service now users to it. They can do some operations through this interface, where all of them are done using the integration user/pass not their service now users theirselves, even because they do not need to share their passwords with us. But it's needed to track the correct user to register on service now and I'm in trouble specifically about commenting on an incident. The endpoint to comment is the following :
http://hostname/api/now/table/incident/{sys_id}
where request body is a json object just as simple as :
{
"comments": "My comment is foo bar"
}
but when this comment is registered on Service Now it is under integration user instead the user which commented. Is there any way I could keep a specific user, considering I already have the user id on Service Now ready to inform it on the request the way it should be.
I tried reading Service Now documentation but had no clue how to solve it, altought I've found something about impersonate
This is happening because you're being proxied through the "Integration User" instead of your own account. As long as this is the case, your comments are going to be attributed to the Integration User.
I can think of two ways to fix this issue.
Ask the client to log you into their system directly as a user.
Implement a special API (Scripted REST API, available in Geneva or later) that allows you to identify the Incident and enter the comment, and then the script forges the comment on your behalf, attributing authorship correctly.
The first solution can be expensive due to possible additional licensing costs.
The second solution will require a willing client to devote 2-3 hours of development time, depending on the programmer.
Firstly, you need an integration user with suffient rights. Our integration user has suffient rights out of the box, but your story could be different. A quick check is to try impersonate as other user using menu.
Login as integration user to ServiceNow instance.
Go to https://{instance}.service-now.com/nav_to.do
Click on username at top right corner. This is a drop down.
There should be at least three menu items: "Profile", "Impersonate User", and "Logout". If you do not have "Impersonate User" in this menu, your integration user miss some permissions. Contact system administrator if you miss this menu item to configure appropriate permissions.
Then you need to find sys_id of user that you want to impersonate. For example:
https://{instance}.service-now.com/api/now/table/sys_user?sysparm_query=user_name={username}&sysparm_fields=sys_id
If you have suffient privileges, you could invoke the folling endpoint with sys id of user that you want to impersonate:
HTTP POST to https://{instance}.service-now.com/api/now/ui/impersonate/{user_sys_id} with body "{}" and content type "application/json". You need to provide HTTP basic authentication to this query as your integration user.
The response code on success is 200. The response body could be ignored. The interesting result of this response is a set of cookies for impersonated user in response headers. These cookies could be used for subsequent REST API calls until they expire. Use some HTTP rest client dependent method to capture them and to provide them to next calls.
For Apache HTTP Client (Java), I'm creating http client context using:
HttpClientContext context = HttpClientContext.create();
context.setCookieStore(new BasicCookieStore());
Pass thing context to impersonation request and to subsequent API calls until I get 401 reply, after that I'm reaquiring cookies. Setting new cookie store is important, as otherwise some default cookies store is used.
Two things to note:
This API looks like internal one, so it could change at any time. If it happens, look for what "Impresonate User" menu item does, and repeat it youselves.
ServiceNow permissions are quite fine-grained, so the target user could lack permissions to perform operation. In some cases, if there is no permission to update the field the operation PATCH on object returns reponse 200, but field is not updated. This introduces a surprising mode of failure when you use impersonation.
I'm trying to use the Graph API to get the feed of multiple public groups then that of multiple users.
When it comes to the feed of groups, it works flawlessly, all I have to do is fetch the following :
graph.facebook.com/$group_id/feed?limit={feedLimit}&access_token={access_token}
My access token being comprised of: AppID|AppSecret
However when it comes to fetching the feed of a user (Whose confidentiality settings are set to public of course) all I get is an empty answer. I would've thought it impossible to get such info and stopped there but then I stumbled upon ApiGee. All I have to do then is authenticate as a user (facebook-Authenticated-user) and it works.
Here's an image of it: http://s9.postimg.org/ynq5tar9r/feed.jpg
My question is : "How is that possible? I've read all I could in the docs and I still can't understand how it works. And how can I remedy that?"
Thank you.
The token you are using is an App token (AppId|AppSecret). With the app token you can't really get users personal feeds. With ApiGee you authenticated to get a user token, which can be used to fetch posts on the authenticated user's feed.
Read more about Facebook's access tokens