There's almost no documentation on anything in yodlee. I have managed to correctly handle getLoginForm by just inspecting the JSON objects returned by different sites until I was able to handle all such forms.
What I don't understand is how to get the MFA fields, what makes them different, and how I submit them differently from the regular login form fields.
I'm new to the system, can anyone with some experience explain this to me?
MFA fields are security questions/tokens/images asked as a follow up from the typical login/password (although you'll soon learn there is nothing typical in the obscure world of bank authentication).
You get the MFA fields by calling getMFAResponse (once you've gotten an ItemID from your addItemForContentService1 call) - http://developer.yodlee.com/Indy_FinApp/Aggregation_Services_Guide/REST_API_Reference/getMFAResponse
Which you then use to build another form, and take that input and submit it with putMFARequest - http://developer.yodlee.com/Indy_FinApp/Aggregation_Services_Guide/REST_API_Reference/putMFARequest
Related
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.
I'm using web api for my application on ASP.NET CORE
If someone see application soruce code, there is a backend url, isn't it?
Then, that guy can use my api if he succeed my application decompile
How protect that situation
I'm just stutdent, so... Just my curiosity
Authenticate your API
If you plan on having a private API (not open to everyone), then you should force users to authenticate themselves by using an API access token. Each token should be specific to a particular user, and there should be consequences for distributing a private key (such as revoking it and blocking the person associated with it) or else people will just share them without care. This will allow users to communicate with your server and run commands or queries as they please. Assuming you have written these functions correctly, they shouldn't allow an attacker to access much beyond his given scope of given API functions (which should be queries at most).
Document, document, document!
You shouldn't allow users access to your source code for this. You should document your API thoroughly regarding details which methods the user can use, what sort of data it expects to receive, and what sort of data you will get back from it (including all errors, possible problems with the users request, and how to fix their requests). Make sure you heavily test these too, and make sure that you can't perform any sort of malicious actions with your API. It's also a good idea to give your documentation to another person and ask them to read it. If you've missed something important, you will know afterwards because there will be a clear gap in their knowledge of the API.
What, not how
Users should know what a function should do, but not how it does it. For example, I could use /api/GetUserById. I should know that I can get a user - I shouldn't know how it gets the user. The only thing I need to know is that I perform this call and I get back a json object with details about the user. That is it.
As with any of my posts, if there's something I've missed or something you need further clarification on, please let me know in the comments and I'd be happy to explain further. I hope this helps
I was reading through the windows live developers doc here. In that I saw they are having an authentication method something like this.
GET https://oauth.live.com/authorize?client_id=CLIENT_ID&scope=SCOPES&
response_type=RESPONSE_TYPE&redirect_uri=REDIRECT_URL
I understood everything except for where do I give the username and password of the user?
I am planning to create an app(first one in my life) to learn the working.
I also have never used or coded something over REST.
When using OAuth, your application never receives the user's username or password. Rather, the user logs in to Windows Live on the Windows Live servers and authorizes your application for access to their information. After they have authorized your application, you receive an access token from Windows Live on behalf of the user. You then use that access token with the Live API to retrieve user information.
Coding something using REST protocols isn't anything too terribly complicated. It has been my experience that you're just specifying parameters to the API using GET or POST as your request method. Adding OAuth on to your requests is a matter of specifying additional parameters.
You're task is to learn two things here since you've never done REST or OAUTH before. Spend time looking at both.
Oauth is hard to get and hard to implement.
You should choose an off-the-shelf Oauth library they exists for most languages.
(Then you do not have to worry about the details. OTOH: You should know how it works to know how to set up and fix if something goes wrong.)
http://oauth.net/code/
Many sites with registration that ask email confirmation and sites use tokens in their url.
Why do they use it?
For example in case of email confirmation: why just not use registered user id instead of token?! In case of using it in web pages, i didn't get at all!!
Explanation with real applications would be appreciated!
Thanks in advance!
A token in this context is typically a disposable time-limited random string used for verification. A token of (say) 40 characters can be generated easily [such as sha1(microtime() . rand(1, 10000)))], which isn't guessable by the user and isn't brute-forceable (within reason).
For email verification, a token will be generated and linked with your account ID. When you visit the address containing the token, the account gets activated. Since we've established that a token can't be brute-forced or guessed (within reason), we've just established that a certain user does indeed have the email address they gave us.
If we just used their member number, they could do several things to just guess it, thus bypassing the email check entirely.
When logging in or submitting a form of some kind, the term "token" may be used in a slightly different context - it's still a disposable time-limited random string, but it's used to make sure that the person who submitted the form has just come from the form they tried to submit.
For example, say you log into your online banking. They might have a form to transfer money to another bank account. If you go to www.nastysite.com they might include an iframe that points to <iframe src="http://www.mybank.com/send_money.php?amount=9001&to=Joe">. If your bank don't verify that you were actually on the form, that payment will go through, and you won't be best happy. Even if you are on the form, the chances of the correct token on your form being used in the fake page-load are (almost) nil.
This is called "Cross-Site Request Forgery", or CSRF. For some more reading on CSRF, have a look at this Wikipedia article. Also, I've just got that link after writing this post and seen that they use a very similar example to mine - genuine coincidence haha.
I've got a wizard which needs to validate if a user is logged in and then at the end validate that all the details they have entered are correct.
The issue is I'm not sure where to put the validation logic.
At the moment I have a BuyMembership class which has validation on the Buy() method.
However this won't be called at the beginning of the wizard where I need to validate whether the user is unique and is eligible for buying a membership.
For this validation I've created a BuyMembershipValidation class which validates if the user is eligible.
The issue now is that I have to pass a different parameter object to the BuyMembershipValidation and the BuyMembership classes. This means the data is split.
Is there a better way of doing it. Should I only load part of the information into the BuyMembership class for the initial validation and then load the rest after?
Update:
I need to validate when they enter the wizard (check if they are logged in already) and if they aren't then they will register as a new user otherwise I have to check if they have the right settings to buy membership as all users can't buy a membership. That's why I need two sets of validation. One for whether they're eligible and another for the actual data they enter to register. However I would like to recheck that they are eligible when they make the final transaction just in case they somehow made it past the first wizard step or if the web service (where I'm doing the logic) is called from somewhere else at a later point.
Another Update:
I've added an answer with my decision.
TIA,
Jonathan.
You're actually talking about three very different things here, and like Allain said, you need to think along the lines of single-responsibility to do this right, OOP-like.
Authentication: making sure a user is known
Authorization: making sure a user can access certain logic in your application
Validation: making sure the data a user inputs is valid/safe/what's expected or needed
A validator is typically tasked with validating user supplied information, not authorization. The single responsibility principle dictates that in your case they should definitely be handed by two objects.
Passing different parameter objects is fine, but but I think the authorization one shouldn't really be passed in to the BuyMembership object, it sounds like something that should be handled externally to it.
My 2 cents.
User authentication is a broad topic. It really depends on what type of application you are building. If it is a web application, I would recommend using one of the standard methods for authentication: NTLM / kerberos
As to when to validate, I don't see any problem with holding off on the validation until the actual Buy method is called. As long as during the steps in the wizard, you are not releasing any information to them and are only collecting data from a form. The main time when you need to be concerned about authentication is when you are actually placing an order or releasing information to the user that should be locked away in a database somewhere.
If you provide more details to what you are trying to do, I will refine my answer to help you a bit more. It's a rather broad question though, so this is the best I can come up with for now.
I've decided to go with just the one class. The reason is that there is common logic / behaviour in the IsEligible and Buy methods. One determines if the inputs meet the eligibility requirements and the other validates that all the details needed to buy the membership are valid. I don't really see this as authentication related. The authentication is done in a separate web control and I just check the Identity.IsAuthenticated and Username to see if they are logged in. I then check their username and if they are eligible to buy then I let them continue, otherwise show an error message. In terms of input validation I already have validation controls on my webpage but the validation I'm concerned with here is server side business logic validation. For that reason I think it should be in the business logic class. Not some validation class separate from the logic that performs the payment. This may just be my way of looking at it but I think this fits well with the BDD ideas of keeping validation inside the entity that holds the data.