Design and questions about Android-authenticator

[fitz]

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?  How should I test effectively.? 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?

3) Should I create issues in JIRA?  Should I include the JIRA issue when I commit something ?

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?

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?


Thanks,
Fitz Lee

[Thomas Mortagne]

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

--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs

[Thomas Mortagne]

On Fri, May 6, 2016 at 11:43 AM, Thomas Mortagne
<[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne

--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs

[fitz]

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
<[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne

--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs