Closed ghost closed 10 years ago
@liato if you do not have time to reimplement the swedbank support you are more than welcome to forward the information to me and I can do it.
The timeplan is that https://mobilbank.swedbank.se will be closed down the 31 of October. @liato what do you think? Should I provide @goober with the material to start the reimplementation or?
Seems that @liato is MIA. @goober do you feel up to at least start up the reimplementation and hopefully liato can accept the pull request later?
@Bacmask I am up for the challenge.
Hello @Bacmask, Apologies for my absence and late response.
I received your mail a while ago and was pleasantly surprised by your proposal to use Swedbank's REST API. You're the first bank to officially offer us access to your APIs and we're looking forward to integrating them in the app.
I'd appreciate it if you could send the API documentation to both me and @goober. You can contact me at info:cyclone:nullbyte.eu and you can find goobers contact information on his profile page. If it's alright I'll send a copy of the mail you sent me to @goober.
We'll do our best to ensure that your customers and our users get the best experience possible in Bankdroid.
Best regards, liato
@goober Have you already started working on this one or should I?
I have not had time yet, and will be quite busy the rest of the week, so you can do it if you think you have the time.
I probably wont have time this week either but I think I'll be able to find some time before the mobile site is closed down.
A Swedbank customer can have multiple profiles, e.g. one or many corporate profiles and multiple private profiles. Each profile can in turn have multiple accounts. So my question is how this should be solved within Bankdroid.
I would prefer the third alternative. That's kinda how it works today. If a user has mutiple banks a dialog with the available banks is shown. I don't think it worked with corporate accounts tho.
Current implementation throws an Exception with all alternatives: Swedbank.java#L156
Hi
Just to clarify a few areas.
The AppID identifies the request to a specific app and there is certain metadata that attached to the AppID that the REST services uses. For instance if the application is targeting private, youth or corporate customers as well as if the app is targeting Swedbank or the Savingsbanks customers are metadata that the REST services fetches from the recived AppID
This means that the depending on what AppID that is used the /profile
service will return different profiles. The AppIDs that I have supplied so far targets Swedbank and the Savingsbanks private customers. That is it isn't possible to get a Swedbank or the Savingsbanks corporate or youth profiles. Still it is important to note that a private customer may have multiple profiles, for instance customer in Sparbanken 1846 as well as Sparbanken Nord.
As I understand it is a wish that Bankdroid works on private, youth and corporate? If so I can supply four new AppIDs for youth and corporate (Swedbank and the Savingsbanks).
Due to the AppID restriction the user needs to choose what type of profile(s) he/she has when setting up Bankdroid.
Please let me know if anything is unclear.
Just want to give you a short update on the status.
I have implemented the accounts part, meaning that you can list all accounts and their balance. I am planning to implement the transactions part tomorrow and then clean up the code before I send a pull request. Hopefully everything should be ready by Wednesday.
@liato Do you think that you have time to build a beta release on Wednesday if everything goes as planned?
@Bacmask I know that Swedbank prefers that the quick balance api is used when possible. This needs to be implemented separately due to the short time frame until the mobile bank will be shut down. I hope this is ok as a temporary solution.
@goober Good job! Wednesday sounds good.
@goober I am ok with if you get a functional version that works as Bankdroid is today as a first stage. But I hope that you have the time to move to the quick balance API as soon as possible after.
New status update.
Accounts and transactions are listed as expected.
Left to do:
@liato Should we throw an exception for existing Savingsbank users that currently uses the Swedbank bank implementation telling them to use the Savingsbank implementation instead?
My plan is still to have a working solution late Wednesday evening.
@goober Sounds like a good idea. Another solution would be to try all appids until one succeeds when a user first adds the account and store the appid with the account information. But that might be too hacky?
@Bacmask Do you have any input on our proposed solutions?
From a branding perspective we would of course like the solution where the user chooses the right brand. But from a technical perspective I don't see a big issue with trying all AppIDs and then store the information on the users belonging. At least if this is the solution only for the existing users of Bankdroid and for new users they are prompted to choose Swedbank Private/Corporate/Youth or Savingsbanks Private/Corporate/Youth.
Please remember that when trying different AppID to logout the old session and then throw away all cookies before trying the next AppID.
@Bacmask If you want to separate the brands @goober's solution is probably better.
Yes the exception is a better long term solution and sparbankerna gets it's own item and logo.
I'll upload it to Google Play when i get home tonight.
Perfect. Great work @goober. Should I open an issue to solve the Quickbalance integration?
That could be a good idea @Bacmask.
@Bacmask Do you know if it will be possible to login a user in the Swedbank-app with an Intent from another app? There's currently a button in Bankdroid that lets the user open the bank's mobile website and be logged in automatically.
@liato The button should automatically login the customer with his personal code? If so this would be a security issue as data(personal code) sent with intent is being transported between app spaces. This means that a rooted phone or otherwise compromised phone(malware, rough Swedbank app) can take the data with very little effort. And this is nothing we would risk by exposing such an Intent.
But of course opening the application with the login screen directly pointing to for instance economic overview is something we could expose as Intent but currently we don't have any such Intents. If you see the need I can take an internal discussion here to see if this is something we would like to support.
@Bacmask I understand your concerns but I'm not sure It'll be a security issue for users that are not already compromised. I think it can be done without leaking any information to other apps if we first confirm the app signature with PackageManager.GET_SIGNATURES and use setPackage() on the Intent. This should make sure that the Intent is only delivered to a Swedbank app that is signed by Swedbank.
If a user has a rogue Swedbank app installed their login credentials have probably already been compromised and Bankdroid won't send an Intent because the signature won't match.
@Bacmask I've created a small proof on concept on how we (hopefully) could send the login data safely: https://github.com/liato/safeintent-android Please let me know if you find a way to extract the data from the Intent with an app other than the intended receiver.
@Bacmask The account ids in /engagement/overview change with every session, is that the intended behaviour?
@liato @goober yes the account ids change every login so don't relay on those ids to find the right account. The most permanent data you can use is the fullyFormattedNumber attribute. But as said previous I really think you should go for the quickbalance solution in the long run as you then get a permanent id that can be used from that device without the need for login every time.
@liato About sending data securely. I have been reading up on the solution you propose and it seems like a rather ok solution. The concern I have is if we expose such an intent we would rely only on trust on the clients that they actually check that it is Swedbank that is on the receiving end. That is even if Bankdroid have the right implementation we have no control over who uses the intent. And I guess there is some ways to tighten that as well but this would be a solution that we would need to look into, which means that it must be prioritized against other development activities.
@Bacmask I agree with you that the long term solution for the widget is to use the quickbalance api. However, due to implementation complexity for the current version of Bankdroid it will most probably be fixed after the next major version is completed.
In the meantime we will be using the fullyFormattedNumber as identifier for the account. See #328
@Bacmask If you're planning on opening up your APIs to third party developers you could include a section about how to securely transfer information to the Swedbank app.
It should be up to the third party software developers to make sure that the user credentials are handeled with care in their app. Swedbank has no way of safeguarding that the a user's credentials aren't sent with SMS, e-mail or in any other unsecure way. The best Swedbank can do in this case is to offer a solution that's well documented and easy to implement.
@goober I think we should use fullyFormattedNumber
until the quickbalance solution is implemented.
@Bacmask Are the quickbalance subscriptions bound to appid
s? If we add a subscription to Bankdroid will it affect the Swedbank app in any way?
@liato If we would open our APIs to third party developers in a more official way we would go for some form of OAuth2.0 solution where a third party application sends the user to a page controlled by us where we can describe what permissions the user grants the application. The user can then sign of that it is something that he/she is ok with. The third party app only get tokens that can be used on the users behalf and never needs to get the users credentials. Swedbank will never encourage a user to give his/hers credentials to an third party as it is a violation against the users agreement with the bank. In fact we always communicate not to give the credentials to third party applications. This is one of the major concerns with creating an intent. An intent that would take an OAuth token for instance is something that we would be more open to.
@liato The quickbalance is bound to appid + unique device id. So it will not affect out app in any way.
@Bacmask If we were to implemente EasyLogin (#318), would we be able to send that id with an Intent or would it only work with the same appid + device id that requested that id?
@liato The EasyLogin is only there to remove the need for users to enter the personal number so it doesn't take into consideration any of the authentication methods Swedbank supports. So if you were to send the id with an Intent the only thing our app can do is to prefill the personal number filled for the user but the user must enter his/hers credentials as usual.
Hi
Swedbanks web based mobile application that is exposed under the domain https://mobilbank.swedbank.se is being closed in a near future. I have been trying to contact you liato to give you some information how Bankdroid could integrate with Swedbanks system in the future. Could you contact me?
markus.backman [@] swedbank.se
Best regards, Markus