Mobile banking development for RaiffeisenBank
A few months ago, a large update of R-Mobile mobile bank for Raiffeisen Bank customers was released in the App Store and Google Play.
The e-Legion team has been engaged in this project for more than two years, and in this post we want to talk about the technical features of the development. Our experience will be useful to those who want to write large, complex, long-lived and successfully developing mobile projects for the real world.
')
Together with users, we want to make R-Mobile even better, so we will be happy to receive constructive reviews on a special page or in the comments to the post.
Well, for technical details we ask under the cat.
A distinctive feature of this project is that interaction with web services is carried out using SOAP . It was a severe limitation on the part of the customer’s technical team, which was not discussed and with which it was necessary to somehow live. Despite a number of shortcomings (“fe, a swollen XML-based protocol in 2014”), using this protocol in capable hands can significantly speed up the implementation of the domain model, the API work layer, and the creation of mock services (about them below). And the thing is that for describing SOAP-services there is an established and generally accepted language: WSDL .
In theory, the availability of ready-made WSDL files (they were available in our case) for web services allows a single command (or pressing a button, who likes what more) to generate all of the above and throw out of my mind the care of a fairly large piece of application architecture. In practice, this is also possible, but, in our case, everything is not so cloudless.
The fact is that SOAP is a rather old protocol that was used extensively in the early 2000s, and later, by the time modern mobile platforms became widespread, it was almost completely superseded by a simpler and more flexible RESTful approach. As a result, the toolkit for working with SOAP and WSDL today is almost completely outdated, and there are very few client libraries and code generators, for example, for Cocoa. And those that are, give out a code of rather dubious quality.
At the very beginning we used the service Sudz-C. At the time of the start of the project, it was free and allowed to get a working prototype very quickly. The network code that comes with it (it works on top of the usual NSURLConnection, without AFNetworking and other stuff) had to be seriously reworked, but the result is still far from ideal.
Later, when updating the application and adding new service classes and models, we directly used Sudz-C XSLT templates, which we slightly modified for ourselves.
For those who are starting the development of an application working with SOAP today, I would advise looking towards MWSC / pico. This project uses AFNetworking, and in general, at first glance, it is made more qualitatively.
Another feature of the project is a closed test environment: the customer’s security service is categorically opposed to opening access to services outside before they pass the penetration testing, which is held closer to the release of the new version. Since the head office of the customer and the test environment are in Moscow, and our team is in St. Petersburg, the first year of development we worked almost blindly. WSDL and a tool called SoapUI have become a real salvation.
He allowed us to quickly load the mock version of the services, giving the test data, and develop, and later test the application using it. Such a solution, although far from ideal, allows catching in the application most of the errors associated with web services.
Moreover, support for scripting allows you to implement some simple business logic in the stubs. For example, choose different answers depending on the correct login and password in the request.
Almost a year after the start of the project, the bank pumped VPN to a test network from one of the St. Petersburg branches, and the developers and testers were able to test and debug the product on real web services.
A separate major task in such applications is the implementation and further support of various forms of payment with numerous types of fields supporting various validation methods, displaying comments and errors, loading data from templates and the transaction log. In addition, the forms for the “payment for services” section are implemented dynamic, i.e. the set of fields for them is not sewn into the application, but is compiled “on the fly” on the basis of requests coming from the server.
Since “Payment for services” was one of the first types of active operations in an application, from the very beginning we developed a kind of internal framework for working with forms, which allows us to build a screen presentation of a form from a set of objects describing field information. This gave a good foundation for further development of more complex, but already static (that is, having a previously known structure) forms.
Initially, it was decided to implement some sections of the application as HTML pages in the embedded browser, in particular “calculators” and “currency rates”. This is due to the fact that they have a rather complicated logic that has already been implemented in JS on the bank’s website, and the implementation and support of the native version will take an unreasonable amount of effort, taking into account the frequency of their use by a typical user.
Despite the seeming simplicity, in order to achieve as close as possible to the native sensation, this method requires quite competent work of the layout designer, as well as a number of hacks and crutches from the native side.
Mobile application security is a pretty hot topic, however, in a well-designed client-server solution, most of the security concerns fall on the server team.
Before the release of the new version, a full-fledged security audit of both the client and server code is carried out, however, until now there have been no serious comments to the application. Naturally, the whole team should know and observe the corresponding top from OWASP, however, in our case, there are not so many potential vulnerabilities on the client side that require close attention. The main vulnerable areas are:
The rest of the risks to us either turned out to be poorly applicable, or related to the server side.
One of the most difficult and undervalued things in outsourcing is building relationships with the customer's team and treating the application as your own product, rather than the usual sale of developer hours. It seems to me that we really coped with this task. From the very first version, we received and read user feedback, worried if something went wrong with users, were in a hurry to fix everything, and proudly showed our work results to our colleagues. We worked very closely with the team of Raiffeisenbank and without this, I am sure we could never have achieved the result that we have today.
We will be grateful for your user feedback, which you can leave in the form of comments below or on the project description page.
The e-Legion team has been engaged in this project for more than two years, and in this post we want to talk about the technical features of the development. Our experience will be useful to those who want to write large, complex, long-lived and successfully developing mobile projects for the real world.
')
Together with users, we want to make R-Mobile even better, so we will be happy to receive constructive reviews on a special page or in the comments to the post.
Well, for technical details we ask under the cat.
Web services
A distinctive feature of this project is that interaction with web services is carried out using SOAP . It was a severe limitation on the part of the customer’s technical team, which was not discussed and with which it was necessary to somehow live. Despite a number of shortcomings (“fe, a swollen XML-based protocol in 2014”), using this protocol in capable hands can significantly speed up the implementation of the domain model, the API work layer, and the creation of mock services (about them below). And the thing is that for describing SOAP-services there is an established and generally accepted language: WSDL .
In theory, the availability of ready-made WSDL files (they were available in our case) for web services allows a single command (or pressing a button, who likes what more) to generate all of the above and throw out of my mind the care of a fairly large piece of application architecture. In practice, this is also possible, but, in our case, everything is not so cloudless.
The fact is that SOAP is a rather old protocol that was used extensively in the early 2000s, and later, by the time modern mobile platforms became widespread, it was almost completely superseded by a simpler and more flexible RESTful approach. As a result, the toolkit for working with SOAP and WSDL today is almost completely outdated, and there are very few client libraries and code generators, for example, for Cocoa. And those that are, give out a code of rather dubious quality.
At the very beginning we used the service Sudz-C. At the time of the start of the project, it was free and allowed to get a working prototype very quickly. The network code that comes with it (it works on top of the usual NSURLConnection, without AFNetworking and other stuff) had to be seriously reworked, but the result is still far from ideal.
Later, when updating the application and adding new service classes and models, we directly used Sudz-C XSLT templates, which we slightly modified for ourselves.
For those who are starting the development of an application working with SOAP today, I would advise looking towards MWSC / pico. This project uses AFNetworking, and in general, at first glance, it is made more qualitatively.
Access to the test environment
Another feature of the project is a closed test environment: the customer’s security service is categorically opposed to opening access to services outside before they pass the penetration testing, which is held closer to the release of the new version. Since the head office of the customer and the test environment are in Moscow, and our team is in St. Petersburg, the first year of development we worked almost blindly. WSDL and a tool called SoapUI have become a real salvation.
He allowed us to quickly load the mock version of the services, giving the test data, and develop, and later test the application using it. Such a solution, although far from ideal, allows catching in the application most of the errors associated with web services.
Moreover, support for scripting allows you to implement some simple business logic in the stubs. For example, choose different answers depending on the correct login and password in the request.
Almost a year after the start of the project, the bank pumped VPN to a test network from one of the St. Petersburg branches, and the developers and testers were able to test and debug the product on real web services.
Forms of operations
A separate major task in such applications is the implementation and further support of various forms of payment with numerous types of fields supporting various validation methods, displaying comments and errors, loading data from templates and the transaction log. In addition, the forms for the “payment for services” section are implemented dynamic, i.e. the set of fields for them is not sewn into the application, but is compiled “on the fly” on the basis of requests coming from the server.
Since “Payment for services” was one of the first types of active operations in an application, from the very beginning we developed a kind of internal framework for working with forms, which allows us to build a screen presentation of a form from a set of objects describing field information. This gave a good foundation for further development of more complex, but already static (that is, having a previously known structure) forms.
HTML
Initially, it was decided to implement some sections of the application as HTML pages in the embedded browser, in particular “calculators” and “currency rates”. This is due to the fact that they have a rather complicated logic that has already been implemented in JS on the bank’s website, and the implementation and support of the native version will take an unreasonable amount of effort, taking into account the frequency of their use by a typical user.
Despite the seeming simplicity, in order to achieve as close as possible to the native sensation, this method requires quite competent work of the layout designer, as well as a number of hacks and crutches from the native side.
Security
Mobile application security is a pretty hot topic, however, in a well-designed client-server solution, most of the security concerns fall on the server team.
Before the release of the new version, a full-fledged security audit of both the client and server code is carried out, however, until now there have been no serious comments to the application. Naturally, the whole team should know and observe the corresponding top from OWASP, however, in our case, there are not so many potential vulnerabilities on the client side that require close attention. The main vulnerable areas are:
- M2: Insecure Data Storage, which is usually expressed in caching what is not needed, and logging unnecessary information, in particular, network traffic (solved using a logging library with setting logging levels; in our case, this is CocoaLumberjack).
- M3: Insufficient Transport Layer Protection, which is expressed, for example, in the fact that the certificate validation turned off on the staging was forgotten to be enabled for the release assembly.
- M9: Improper Session Handling, for protection against which it would be good to disable the session after changing IP for a reasonable period of inactivity or just after some time.
The rest of the risks to us either turned out to be poorly applicable, or related to the server side.
Conclusion
One of the most difficult and undervalued things in outsourcing is building relationships with the customer's team and treating the application as your own product, rather than the usual sale of developer hours. It seems to me that we really coped with this task. From the very first version, we received and read user feedback, worried if something went wrong with users, were in a hurry to fix everything, and proudly showed our work results to our colleagues. We worked very closely with the team of Raiffeisenbank and without this, I am sure we could never have achieved the result that we have today.
We will be grateful for your user feedback, which you can leave in the form of comments below or on the project description page.
Source: https://habr.com/ru/post/225715/
All Articles