I'm having some difficulties implementing the MFA workflow with Yodlee. The workflow does not specify how to proceed with multi-level banks, for example, when a bank asks for a phone number to send an SMS with a temporary PIN.
{
isMessageAvailable: true
fieldInfo: {
responseFieldType: "text"
minimumLength: -1
maximumLength: 25
displayString: "Enter your Mobile Number or eMail ID where to send the temporary PIN"
} -
timeOutTime: 111750
itemId: 0
memSiteAccId: xxxxxxxx
retry: false
}
In this situation, what do I have to do? Keep calling the getMFAResponseForSite every 2 seconds?
Also, in order to perform the putMFARequestForSite, which type should I use?
com.yodlee.core.mfarefresh.MFATokenResponse
com.yodlee.core.mfarefresh.MFAQuesAnsResponse
com.yodlee.core.mfarefresh.MFAImageResponse
As there are 3 types of MFA (to know about types of MFA refer what-is-the-mfa-differences-spotted-in-this-case
To differentiate you can use the response of getMFAResponseForSite.
SECURITY_QUESTION - The response from getMFAResponseForSite looks like -
fieldInfo":{
"questionAndAnswerValues":[
{
hence you need to use com.yodlee.core.mfarefresh.MFAQuesAnsResponse
IMAGE - The response from getMFAResponseForSite looks like -
fieldInfo":{ "responseFieldType":"text",
"imageFieldType":"image",
"image":[
hence you need to use com.yodlee.core.mfarefresh.MFAImageResponse
TOKEN_ID - The response from getMFAResponseForSite looks like -
fieldInfo":{ "responseFieldType":"text"
Since there will not be any indication of Q&A or Image hence you need to use com.yodlee.core.mfarefresh.MFATokenResponse
You can also check the various responses of MFA at getMFAResponseForSite and getMFAResponse. The fieldInfo returned in both the methods will be same and hence can be used to identify the type of MFA.
Hence in case of multilevel MFA you will have to use any combination of the 3 listed MFA types.
Related
I'm trying to understand which Http Status Code to use in the following use case
The user tries to do a GET on an endpoint with an input ID.
The requested data is not available in the database.
Should the service send back:
404 - Not Found
As the data is NOT FOUND in the database
400 - Bad Request
As the data in the input request is not valid or present in the db
200 - OK with null response
200 - OK with an error message
In this case we can use a standard error message, with a contract that spans across all the 200 OK responses (like below).
BaseResponse {
Errors [{
Message: "Data Not Found"
}],
Response: null
}
Which is the right (or standard) approach to follow?
Thanks in advance.
Which is the right (or standard) approach to follow?
If you are following the REST API Architecture, you should follow these guidelines:
400 The request could not be understood by the server due to incorrect syntax. The client SHOULD NOT repeat the request without modifications.
It means that you received a bad request data, like an ID in alphanumeric format when you want only numeric IDs. Typically it refers to bad input formats or security checks (like an input array with a maxLength)
404 The server can not find the requested resource.
The ID format is valid and you can't find the resource in the data source.
If you don't follow any standard architecture, you should define how you want to manage these cases and share your thought with the team and customers.
In many legacy applications, an HTTP status 200 with errors field is very common since very-old clients were not so good to manage errors.
I'm trying to use Google Pay on my website. Once I confirm the payment Google returns this data structure:
But I need something like this:
{
"signature":"MEYCIQDTe92wpG6OUgxJ/8Qnr36XzSgjGGCM7R3LwxjgwPYMTAIhAJDrjHG9wEm1BxVM6MMMB+jGTGpi3VScEMVbHIUsObFi",
"protocolVersion":"ECv2",
"signedMessage":"{\"encryptedMessage\":\"FY8w/U3IbdsZQovX8ufNGFDOePgc/genRiMjHyvuIBqLY4a6uPz7wI0ra31K6YbFJlAnCjFhTwSvDxAYXw6hlmI8sESO5eM1eZlzfP3+NoKV80OXKvOM/xI/qOQEqpEQEVXx6Bw2EpMMFW8yBaA8XPUNee3EJlUk+/f8lRdRcNmI65QKPLAzUnySo75HzBkSc5It/8/oXdYwR93/K6HRKGZuD+bIaxy3SUvC9ehQqhBoP+A34yQX1knfJ1qjBMhhVVcPZHi+Bg6LXA4ms/lfDdim6D1Epr6XQhc2h4RZ/dT+6Enn81s/8ym+jMMs8kqsW9ib8vkdTARv9AbUu7zeGPrKTCAxwc1n6joRR72dSnNCI9j9sxd9tkuC9wuRyDmjbWT+hRZgLc1v/xzzNImo3NxdKdaPzKBE3t9XQZY5fp3lZELaoXAuxAZYtZ7bX64Mz9c28wD8EM+krvfbmGMiBjIt8EfeH48/SjeaUKfDu+yQnjPJAKbDZPhKJ1jqlY/ChP0Om7spQacT86QUVK/DwfzukwvwwRJkWydNEac5fgfS2T6ToZ+PW4VHbxkDnY/h+B0uwdlNQIL2a3Ar5Q\\u003d\\u003d\",\"ephemeralPublicKey\":\"BGkK4bSvob+e7ZgaNV/4vSJYYa10OJzd3aUk9yPEP6iNBRcfHiD/NTvhKjN4P24l0tEzH3L8TrySl6AczPJpCkw\\u003d\",\"tag\":\"xGEhEfJESIyBSfq2fExWiZxNWelnm3m4i8P7cgsarqg\\u003d\"}"
}
Could you please advice me what should I do to get the second data structure. Thank you!
The response that you are after is found under paymentMethodData.tokenizationData.token. However, the contents of this field are determined by the request parameters that you pass to loadPaymentData. Are you able to include the request that was used to generate the above response?
FYI, the following JSFiddle will produce a result similar to what you are after:
const tokenizationSpecification = {
type: 'DIRECT',
parameters: {
'protocolVersion': 'ECv2',
'publicKey': 'BMzk6xvwPgU8vjB...7KRu4tuRmhm6nv8=',
}
};
/*
{
"signature":"MEUCI...TougPg",
"protocolVersion":"ECv2",
"signedMessage": "{\"encryptedMessage\":\"VhQuaN...5o0Ny6Y\\u003d\"}"
}
*/
I achieved this by using a DIRECT tokenization specification which is discouraged:
Key Point: The Direct integration allows merchants to decrypt the Google Pay response on their servers. To qualify, you must be Payments Card Industry (PCI) Data Security Standard (DSS) Level 1 compliant. Your servers also need to have the required infrastructure to securely handle users' payment credentials.
Third parties that supply gateway or processing services on behalf of actual merchants aren't eligible to use the Direct integration. For questions about your integration as a payment service provider, contact us.
If you don't meet the necessary prerequisites, we recommend that you use a supported gateway to receive a payment token.
Not sure if this is still an open issue. But here are my 2 cents and might be the answer to your solution.
Please note: This is an answer if you are using WorldPay/Vantiv only.
From your first response above with the token, I believe you are using gateway as "vantiv"
"gateway": "vantiv"
"vantiv:merchantPayPageId": "YOUR_PAY_PAGE_ID"
"vantiv:merchantOrderId": "YOUR_ORDER_ID"
"vantiv:merchantTransactionId": "YOUR_TRANSACTION_ID"
"vantiv:merchantReportGroup": "*web"
If you want to get the second response with signature and signedMessage then all you have to do is change the gateway to "worldpay" and you should get the same response:
"gateway": "worldpay"
"gatewayMerchantId": "YOUR_WORLDPAY_MERCHANT_ID"
You can find the request here
I'm trying to wrap my head around Elm. I have experience in Haskell, and a bit of Erlang.
I want to complete the following exercise:
User is shown a login form
On submit, the frontend makes a request to localhost/auth to try and receive an auth token.
On success, the homepage is shown, which fetches some data.
On failure, the login screen displays an error.
This is quite basic, but hopefully complex enough to model the behaviour of a real webapp.
My first problem is with the Model. I only need the data if the client is authenticated. Should I wrap this in something similar to a Maybe monad?
type Model
= NoAuth String String
| AuthFetching
| AuthFailed err
| AuthSuccess String
And then the login screen can display a spinner, and error, or redirect to a new page.
This feels like it ties the rest of the applications state to the authentication state. Although is is "correct", it feels wrong to have the whole model be a (variant type?) with only one record.
It "feels" more correct to have the model like so:
type FetchStatus
= Loading
| Success val
| Err err
type Model =
{ token : RequestStatus String
, data : List number
}
But whenever you update the model, you now need to check if token is still present - i.e. pattern match within the record. In the first example, you only needed to pattern match on the whole model, which is a bit simpler.
And to hold the login form state, I'd need to add extra fields:
type Model =
{ token : RequestStatus String
, data : List number
, username : String
, password : String
}
Which feels incorrect because the password should not be held in memory after login. I'd hold these in records, but I cannot use records in custom type declarations.
All in all, I'm a bit confused. Can someone please shed some light on the most "correct", idiomatic way to do this?
All authorization related stuff should be handled on the backend side. Elm's job is only to display what server has sent to it. In my opinion the first option you proposed is the best for such a little example, but in more real-life application the typesystem would be more complex:
type LoginForm =
{ username : String
, password : String
}
type Activity
= Login LoginForm
| LoginSuccess
| LoginFailure String
type Model =
{ loggedUser : Maybe String
, activity : Activity
, ...
}
You don't need (and shouldn't) keep password on frontend. You also shouldn't perform any authorizations on the client side, as the client may easily replace any script in his browser. The backend will track whether the user is logged in by eg. session cookies. In this scenario even if the loggedUser value is set to Just "someguy" and "someguy" is not marked as logged in the server database, any action that requires authorization shall fail.
Summarizing, handling login and giving permissions to access any content is a job for backend. Elm is frontend language, so it's only purpose here is to display things.
i'm just trying to check user entitlements for user subscription data from bloomberg api's data feeds.
For this i tried to run Bloombergs example "EntitlementsVerificationSubscriptionExample". As it seems to be working at first sight, on second sight i recognized, that there aren't any entitlements for the data i receive from the api.
that means:
public void processSubscriptionDataEvent(Event eventObj, Session session)
{
foreach(Message msg in eventObj)
{
bool needsEntitlement = msg.HasElement(Name.GetName("EID"));
}
}
is always 'false', as there is never a field called "EID" available.
Is there something wrong on bloomberg service site or better, is there any kind of documentation available, how to use user entitlements within data subscriptions?
thanks in advance,
First, you need to subscribe to the "EID" field, as it's not returned by default.
If the field either is not returned in the message, or had Null value, then that means data in this message does not require entitlements. Otherwise, call the following function and pass the EID value:
bool bEntitled = userIdentity.hasEntitlements(EID);
Function return value indicates whether user is entitled or not.
Data that does not require entitlements can be shared with users who are registered in EMRS (in case of B-Pipe), or with any terminal user within the firm (in case of SAPI) with no further entitlement check. Users who are not registered in EMRS or those who are non-terminal users should not have access to either B-Pipe data, or SAPI data, respectively.
I'm trying to use the http://Astrid.com API, specifically to get data using the method under the "Request Format" section on this page - http://astrid.com/apidoc/file.README.html
The URL I built is:
https://astrid.com/api/7/task_list?app_id=[MY APP ID]&time=1&user_id=[MY USER ID]&sig=[MY REQUEST SIGNATURE]
And it returns this:
{"list":[],"time":1363131562,"status":"success"}
Seems like it worked, but does anyone know why the "list" array might be returning empty? I've created a bunch of tasks in my profile so it should be showing those.
Thanks!
You need to sign in first with the method user_signin. If successful you get a token.
Then you need to call the task_list method providing the token.
You do not need to provide a user id with the task_list method. It is only used to select tasks that you share with this user.
Example for signing in:
https://astrid.com/api/7/user_signin?provider=password&app_id=YOUR_APP_ID&secret=YOUR_ASTRID_PASSWORD&sig=SIGNATURE&time=1365715302.36&email=YOUR_EMAIL
Example for getting your tasks:
https://astrid.com/api/7/task_list?active=true&token=THE_TOKEN&sig=SIGNATURE&app_id=YOUR_APP_ID&time=1365715304.41