Thank you so much, my mentor, for encouraging and helping me a lot. I will keep working hard, implement more functions ASAP and try my best to make this project better and better.
Thanks, Fitz On Fri, May 6, 2016 at 11:43 AM, Thomas Mortagne <[email protected]> wrote: > Hi Fitz, > > First I'm quite impressed by the dedication you put in this project, > great work ! > > Let me answer quickly the simple questions and then I will take more > time to think more about the design issues :) > > On Thu, May 5, 2016 at 6:45 PM, fitz <[email protected]> wrote: >> Hi our dear community, >> >> I have tried to implement most of the functions for android-authenticator in >> these >> days( https://github.com/xwiki-contrib/android-authenticator/tree/feature-auth). >> But there are still a lot of detailed issues that need to be handled, like >> security, volume, bad network state, cache and so on. I will try to deal >> with these problems as soon as possible. >> >> Here, this time, first I would like to discuss whether my implementation is >> feasible enough, and second there are some other problems which need my >> mentor and our community to help me. Thanks first of all. >> >> 1. *First introduce my design* and implementation of the synchronization and >> authenticator. >> >> 1.1 *Synchronization:* >> >> 1.1.1Server->Client >> There are two choices, including synchronizing all users or synchronizing >> the users of selected groups. We use the same method for these two cases. >> 1) Add Update >> Each time while calling the method SyncAdapter.onPerformSync, we get data >> from server that has been modified since the last modified time. The data >> that we get must be updated or added to the local contact2 database. Also >> only these data need to be updated or added. >> 2) Delete >> What data should be deleted from the local database? Because the server >> does not return data that needs to be deleted, or maybe I don not know how >> to query the deleted objects? :). Therefore now I just get all the user >> IDs(HashMap<id,Ojbect>), traverse every user of the local database, find the >> data that are not in the IDs map, and then delete it. >> >> 1.1.2 Detail: >> For synchronizing all users: >> 1) Get all users as List<SearchResult> searchResults >> 2) Add Update: SearchResults include the last modified time. So according to >> the time, we can filter what data should be updated or added. Then call the >> function ContactManager.UpdateContacts to update local db. >> 3) Delete: searchResults already have user ids, so we can get the >> IDs(HashMap<id,Ojbect>), then traverse the local database to find what data >> should be deleted. >> >> For synchronizing users of selected groups: >> 1) Get all selected group ids from local sharepreference xml, as >> List<String> groupIds >> 2) Get the users’simple information(ObjectSummary) of each group one by one. >> The ObjectSummary only has the user’id without the last modified time. >> 3) Add Update: According to the user ids, we get the last modified time for >> each user, if before the given last sync time, continue; if after, we update >> the user (but we need first get the detailed information of the user). >> 4) Delete: at second step, we get ObjectSummarys which include all the user >> ids. So with these ids, we can find the data that should be deleted. >> >> 1.1.3 Client->Server >> For this part, As we will first request and update the data in server while >> editing the contact, Therefore, unnecessary synchronization mechanism is not >> required. If the server’s response is that the editor has no permission, we >> just return; if has been updated in the server, we will update the local >> database at the same time. >> >> 1.2 *Authenticator:* >> >> 1.2.1 How to grant the permission for third party apps when they calling >> getAuthToken? (Here, AuthToken is equal to Cookie.JessionId). >> >> Basically, only 3 useful interfaces, like AddNewAccount, getAuthToken, >> invalideAuthToken, are available for other third party android apps. The >> most widely used is getAuthToken. How should we grant permission for >> third-party apps? And when we grant? If adding XWiki account from one app, >> then we can trust this app and grant the getAuthToken permission. But if >> not, we should check the permission for every getAuthToken request of >> third-party apps. So the checking logic code should be in the function >> getAuthToken. But XWikiAuthenticator.getAuthToken will never be called if >> AcountManager has cached the authtoken corresponding to AuthTokenType. >> Therefore for first granting permission to third-party apps, the app should >> not pass the same authTokenType when calling getAuthToken function. Or the >> authToken value will be directly returned by AcountManager according to the >> same AuthTokenType and the method getAuthToken will never be called. So >> different apps should use the different AuthTokenType param to call the >> function getAuthToken so that the <AuthTokenType, AuthToken> will not be >> cached before granting permission for this app. >> AuthTokenType=FULL_ACCESS+PackageName. So in XWikiAuthenticator.getAuthToken >> function, if we check that the third-party app has not been granted, we >> startActivity(GrantPermissionAcvivity) to grant permission for this package >> by checking the user’s input password. And in addition the packageName can't >> be forged because we can use the bundle option.getCallUID from binder to >> verify the pakageName. >> >> 1.2.2 How to maintain authToken consistency for different third-party apps >> with different AuthTokenType? >> >> When will appear inconsistent? There are mainly two key cases, the authToken >> is expired or the third-party app calls the invalideAuthToken function. Now, >> I use the following solution to these problems. >> 1) When the authToken is expired, xwiki authenticator app will login again >> and refresh all the cached authToken for every AuthTokenType. >> 2) When the third-party app calls the invalidAuthToken function, then >> corresponding cache will be clear and getAuthToken will be called, then >> XWikiHttp.login will be called to get a new token and refresh all the cached >> authToken for every AuthTokenType. >> 3) So if any one finds the authToken has been expired, then login and >> refresh all the cached authToken to maintain consistency. In addition, I >> suggest that if the third-party app find the authToken is expired after a >> period of time, then first call getAuthToken again. If the token is >> different, then maybe authenticator has already update the token. If the >> token is the same, just call invalidAuthToken and getAuthToken again. >> > > >> 2. *There are also some questions* that need help. >> >> 1) Is the above methods ok? > > I need to spend more time to anwer the first question (I simply don't > much about some of the things you talked about :)). What I can say > right away is that what I read looks well tough and whatever I could > came up with will most probably be minor. > >> How should I test effectively.? > > You talk about Jenkins below so I guess you already started to look at > how to write unit tests. I would add that as soon as you have a > testable beta you should oficially release it and ask for tester in > the community. I need to finish setting up an Android Play dev account > for the XWiki project and will give you access ASAP. If your question was about the XWiki instance you can easily get a jetty/hsqldb distribution from Maven repository, unzip it and start it. That what we do in other integration tests that need a running instance of XWiki. > >> Or Maybe these >> implementations exist more problems that I have overlooked? > >> >> 2) Gradle or maven in Jenkins CI? >> Now gradle is the default, great and perfect tool for building android app. >> http://gradle.org/maven_vs_gradle/. And It's convenient for us to develop >> android apps in android studio. Also it's very easy to integrate with >> jenkins and maven repository, And I have already tried it and successfully >> build my android apps in jenkins with >> gradle.( https://github.com/xwiki-contrib/android-authenticator/blob/feature-auth/document/CI.md ). >> However If we use maven to build apps, it's not conducive to our >> post-maintenance and integrated development for android developers. So could >> I use gradle instead of maven to build our android apps? and can I use it in >> the jenkins? or I have to use maven? > > This is an independent project and will stay like this, I don't think > we need to integrate it in the xwiki-platform build. Android community > seems to have strongly choosen Graddle and is building around it now > and Graddle is not an issue for Jenkins so I would be for keeping to > use it. > > I will look at your documentation as quickly as possible and setup a > job for you on ci.xwiki.org. By the way I think you can move your work > to master branch, no need to keep working on a feature branch. Frankly > given the state of the current master branch there is no reason to > spare it... > >> >> 3) Should I create issues in JIRA? Should I include the JIRA issue when I >> commit something ? > > You don't need to have a different JIRA issue for each commit but it > would be nice in each commit a reference to the JIRA issue covering > the feature this commit is about. > > For the Android authenticator project, 2 issues (authenticator, > account synchronizer) should be enough IMO. > >> >> 4) HttpClient or HttpUrlConnection? Or OkHttp/Volley library? >> HttpClient(org.apache.http.client) has been deprecated and HttpUrlConnection >> is a recommended way. So now I use this UrlConnection and write a simple >> request library to communicate with server. Maybe I can use okhttp/volley >> in the future as the way of http request to efficiently process data, but it >> may increase the size of the application. But maybe it has more features >> like cache, spy, connection pool and so on. The cache should be very useful >> if large volume of users’ data have to be synchronized, Especially when >> network is not very good and we request server again and again. Should I use >> the okhttp library instead of my custom implementation of http library? Or >> other serializable library like gson/xstream instead of the XmlPullParser? > > I agree that using HttpClient is not a good idea if it's deprecated. I > know nothing about so I could not relly tell you if it's better to use > this or HttpUrlConnection. What I can tell you is that if you find it > there things that would really makes things a lot easier/better then > go for it, I'm sure we can live with an extra 320kB. > >> >> 5) Other ideas and contributions? >> Maybe after completing this authenticator app, I could rewrite the >> android-client app with android studio and update the application interfaces >> and something out of date. Maybe I can do some translation in Chinese ? >> Maybe I can update some document? >> Or maybe I can solve some useful bugs in JIRA for XWiki platform or >> extension? You know, now I'm not very familiar with such a huge code and >> even do not know how to start after looking at some of the code. I still >> need some time to explore. I think now maybe I should first well finish the >> android-authenticator. :) And then be familiar with the entire code >> architecture as soon as possible, and try to find and solve a small problem. >> What do you think? Could anyone give me some tips? > > For now you should probably concentrate on the GSOC and maybe improve > things that this project directly depend on (REST API, etc.) if you > have time and we will be very happy to discuss with you what you could > work on after that if you want to continue as member of this great > community :) > > Don't worry there is plenty of things that you could do on XWiki > project as a contributor and we can discuss that depending on what you > like to work on. One idea maybe would be to lead Android (and other > mobile) related projects (maintaining Android Authenticator, > improve/create libraries or final applications like you said, > improving the REST API, etc.) for example if you want to keep working > on Android because you will quickly become THE expert (if it's not > already the case, at least you already know more about Android > development than me or any XWiki committer I think) in XWiki community > about those projects anyway ;) > >> >> >> Thanks, >> Fitz Lee >> >> >> >> >> -- >> View this message in context: http://xwiki.475771.n2.nabble.com/Design-and-questions-about-Android-authenticator-tp7599355.html >> Sent from the XWiki- Dev mailing list archive at Nabble.com. >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
