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. > 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
