Yodlee Site cannot be refresh - yodlee

I'm trying to test the MFA in Yodlee with the dummy account DagBankTokenFMPA. I let the MFA timed out and now everytime, I try to refresh I got the same error :
{"siteRefreshStatus":{"siteRefreshStatusId":10,"siteRefreshStatus":"SITE_CANNOT_BE_REFRESHED"},"siteRefreshMode":{"refreshModeId":1,"refreshMode":"MFA"},"updateInitTime":0,"nextUpdate":2047149073,"code":522,"suggestedFlowReason":{"suggestedFlowReasonId":2,"suggestedFlowReason":"ACCOUNT_IN_ERROR"},"suggestedFlow":{"suggestedFlowId":3,"suggestedFlow":"EDIT"},"itemRefreshInfo":[{"memItemId":10088102,"itemSuggestedFlow":{"suggestedFlowId":3,"suggestedFlow":"EDIT"},"itemSuggestedFlowReason":{"suggestedFlowReasonId":2,"suggestedFlowReason":"ACCOUNT_IN_ERROR"},"errorCode":522,"retryCount":1}],"noOfRetry":1,"isMFAInputRequired":true}
How can I prevent that ? Do I need to stop the refresh with stopRefresh and start over ?

In this case you need to call updateSiteAccountCredentials API and just pass the details again, this will trigger a refresh and then you need to call getMFAResponseForSite to see what MFA information is required by the bank.
To add more, it seems like you are mixing two sets of APIs here. We recommend to either use container based APIs or Site Based set of APIs, in conjunction with Core APIs which are common to both.

Related

Restricting user authentication with Firebase

I'm using Firebase to authenticate the users on my application but, since the app is very early stage, I would like to restrict the login (or registration) to only users that have a specific code.
It looks like there's no option like this and I was wondering if there's any solution that doesn't involve a back-end.
Right now I'm using a specific code in the database that the user has to enter while logging in. If that code is not correct you can't login. The problem is the function (obviously) is executed on the front-end so a person with the right knowledge could easily modify the code and still access without token.
Is there a more robust solution?
if you truly want no back end, you can see my answer at the bottom here How to protect firebase Cloud Function HTTP endpoint to allow only Firebase authenticated users? , which involves taking advantage of the fact that every firebase project is also a Google cloud platform project and GCP allows for private functions.
however, there is an easier way: just wrap your cloud function logic with an if clause that checks for any of a number of things before actually executing the function
assuming, for instance, you're on the web platform, when someone invokes an HTTPS callable function from the front, it will be sent with data and context objects.
you could check for context.auth.email to restrict to specific users. or you could check for data.mySecretKey and since the check is occurring in your cloud function, no one could inspect your code to find the key.

Sonos integration with anonymous access and the application registration form

I/we at www.dr.dk are working on a Sonos integration with the bare minimum functionality. This means that we wish to apply anonymous access in this first version of our Sonos integration.
In the API documentation
https://musicpartners.sonos.com/node/289#toc0
is says 'Finally, you can decide not to use any authentication, also knows as anonymous access. ...'
Which we read as an option to not to implement authentication endpoints like 'GetAppLink(...)' etc.
So now we have teste our service and it appears to work fine, as far as we know. Therefore we have now started to fill out the application registration form.
In the registration form we find the following required fields regarding authentication as depicted in the image below
Screenshot from the application registration form
As we see it these fields are related to authentication and seems somewhat confusing to us. So with our logic - anonymous authentication means that no test accounts or customer care accounts are needed etc.
So the question is. What are we missing ?
You can just mark those as N/A for each of the fields.

Implementing OAuth2 with Socrata API

I'm implementing the Socrata API to be able to parse publicly-available data from the City of Chicago open data set. I am really just concerned about the data itself, so I did not initially think that I would need to implement OAuth2 through an app exposed via ngrok to be able to GET the data.
My initial attempt was to take the GET requests mentioned in their documentation and try to get responses through Postman.
Here's an example of such an attempt:
I also added my Socrata App Token as a param in the querystring, but the same message was shown.
So I tell myself, ok, maybe they deprecated GET requests without making the client go through OAuth2. If they didn't deprecate these GET requests, I would prefer not to have to deal with OAuth2, but I began implementing the authentication process and everything went successfully until I got to the following instructions found here:
I have every single value that needs to be included in that POST request except for 'authorization_type'. Where does this come from? I tried leaving 'authorization_type' in as a string, but received a response similar to the 'Invalid username or password' message in the top image in this question.
Are you only accessing public datasets from Chicago's data portal? From your screenshot it looks like you're trying to access the Building Permits dataset, which is public.
Authentication is only required for modifying datasets or accessing private data, so chances are very good you don't even need to authenticate. Just include an application token with your request for throttling purposes.
Glad to help you figure out your OAuth workflow, but it sounds like it might be unnecessary.

Using FastLink for Account Refresh and Edit

We are trying to use Fastlink to provide instant refresh and account edit functions. This has not been successful as we keep getting "Problem updating account" FastLink UI.
We do not want to use the ProviderAccount PUT API to trigger refresh as we want to stay away from providing login/MFA UI. FastLink has been very helpful in providing the account add function and we really want to leverage it for all the account related functions.
Please use the following sample values in extraParams for refreshing or updating account.
Refresh Account:
String extraParams="flow=refresh&siteAccountId=10139794&callback=https://www.google.co.in";
Update Account:String extraParams = "flow=edit&siteAccountId=10139794&callback=https://www.google.co.in";
Please pass the value of providerAccountId for siteAccountId.

Yodlee refresh on an already-active MFA account

Re: Yodlee site-based API
a) I know that when adding an MFA account you are supposed to trigger /jsonsdk/Refresh/startSiteRefresh. But if an account is already added and already active, and I want to trigger a manual refresh to get new data, is /jsonsdk/Refresh/startSiteRefresh the correct API to use?
b) When I do use /jsonsdk/Refresh/startSiteRefresh for a manual refresh, I do not want to trigger the whole MFA flow, I simply want to pull new data if possible. So which refreshMode do I specify "MFA" or "NORMAL"?
I ask this, because I used "MFA" mode and it failed with a 522 (timeout) error due to a new security question. But when Yodlee runs the nightly refresh, the same condition will result in a 506 or 518; not a 522. Maybe I am supposed to specify "NORMAL" even for "MFA" accounts for a manual refresh?
You need not pass the refresh mode in the startSiteRefresh API. When you call this API for a siteAccountID the response will tell you if the MFA is required or not. Below fields can be used from the response.
"siteRefreshMode":{
"refreshModeId":1,
"refreshMode":"MFA"
}
Depending on the refreshMode you can follow the MFA flow or Normal flow.
When you trigger this API you will have to flow the complete flow to get the latest data or else the refresh will fail and data will not be updated.
Refer - startSiteRefresh for the API and Refresh Flow for refreshing an account.
I ask this, because I used "MFA" mode and it failed with a 522 (timeout) error due to a new security question. But when Yodlee runs the nightly refresh, the same condition will result in a 506 or 518; not a 522
This is because in case of manual refresh you as a user is not answering the question asked at the end site and hence our server identifies it as no response from the user and hence 522 error code. When it's automatic refresh from Yodlee's end and a new question is encountered the error code is 518.