Questions, Gsoc2016, XWiki Android-authenticator

[fitz]

Hello Dear devs,

I am Fitz Lee, a CS Master's student from the University of Chinese Academy of Sciences. I'm very interested in this project, XWiki authenticator Android. I have submitted the final application for Gsoc2016 (https://drive.google.com/file/d/0ByNx4jI3PEaNaGRxMkt0cUU3SjA/view?usp=sharing ).
In order to furtherly understand the authenticator project, I have developed this android demo (https://github.com/fitzlee/SampleSyncAdapter), which is based on SampleSyncAdapter Google Android Sample. By deeply Analyzing the SampleSyncAdapter source,  I have implemented the material design(>=4.4) ui, the synchronization of contacts and the access of other apps .  But some functions in google server(https://samplesyncadapter2.appspot.com/sync) can't work well so that the client-to-server Synchronization function can't be tested and verified, and it needs to cooperate with server.  In my github repository(https://github.com/fitzlee/SampleSyncAdapter), I also show my analysis about the authenticator, synchronization, contactmanager, sign-in, sign-up and the whole process of the app. And now I am trying to develop the XWiki android authenticator project.

Please consider my application, and I am eager to join this project and make a contribution. It's my first time to join the open source organization for enhancing my teamwork and technical skills. Please give me a chance, and I will try my best. If there is anything I can do for this project , I will be very happy.
 
Here, i also have some questions which confuse me during my development:
1. contact synchronization
(1)Situation:
Now I have implemented the server-to-app synchronization with the modified SampleSyncAdapter (https://github.com/fitzlee/SampleSyncAdapter), and this demo can download contacts from server to local sqlite3 database. Also I can edit and modify the local contact and from logcat I have seen the dirty contacts being sent to the server. But the synchronization of server can't work so that I can't test this function.
(2)Problem:
Moreover, by analyzing the XWiki android authenticator in the repository (https://github.com/xwiki-contrib/android-authenticator). I have seen that some function has not been implemented, like getDirtyContacts and getRawContact in ContactManager. And the process of synchronisation in SynAdapter_onPerformSync also confuse me, like "ensureXWikiGroupExists>> XWikiConnector.getUsers>> ContactManager.updateContacts>> ContactManager.updateStatusMessages". I think it should be this process, like "ContactManager.getDirtyContacts>> NetworkUtilities.syncContacts>> ContactManager.updateContacts". Therefore, I don't know whether there is something wrong with me.  Could you give me some advice?
 
2. A test xwiki server and test user which may help me a lot to develop this project for testing.
I have analysed the sampleSynAdapter and implemented some function, for example material design(>=4.4), version support(2.3 with v7 library) and the synchronisation from server to the android local sqlite3 database(contacts2.db) using ContactManager.But when client sends some dirty contact data to server, the synchronisation of server in google appengine can't work well so that I can't test my app's synchronisation. And the SampleSyncAdapter server also can't provide me more apis,like signing up and other necessary function.I have tried to upload a python server to google appengine,but failed because of the incompatibility between the source code by python version 2.5 and the cloud platform by 2.7 version.
Question: Please if possible, could i have a test user and some server apis in xwiki server, or maybe i should write a test server by myself?
 
3. requirement
I think this project mainly has the following requirements.
(1) sign in
it is easy,just like my analysis of android SampleSyncAdapter, including the server connection with XWikiconnector and the account added by AccountManager
(2) sign up
may also need some other api, like getting a list of xwiki user, adding friends which can be synchronized in the local phone contacts. Also other activitie may be possibly added, therefor the authenticator app will be very complex.
(3) synchronization of contacts
(4) edit the contact
(5) access by other apps
Question: Are there more other requirements in this app, like adding friends(general person) and creating new xwiki account(administrator)?  maybe it will cause more demands and be more complex.
 
4. support version and ui
(1) ui design
* material design >=4.4 with the support library support-v7
(2) support version
* The ui design can support the lowest 2.3 version and the android sampleSynAdapter can also support 2.3 version. So I think our authenticator app can support the lowest 2.3 version if needed.
Question: Maybe there are somethings I have not noticed, so this conclusion is wrong, please give me some advice? Is that OK?
 
5. account permission
In AccountGeneral.java there are two permissions , like AUTHTOKEN_TYPE_READ_ONLY, AUTHTOKEN_TYPE_FULL_ACCESS.  Could you tell me what the permissions main?  other xwiki instance access  limits ?  Account manager? And where should I use them?
 
I am looking forward to hearing from you. Thank you very much.

Best Regards
Fitz Lee | UCAS Master
Email&Skype: [e-mail]
Github&Homepage: https://github.com/fitzlee

University of Chinese Academy of Sciences(UCAS)
Shijingshan District, Beijing, China

[Thomas Mortagne]

Hi Fitz,

Great to see so much motivation from you :)

Just don't forget that GSOC coding period is not started yet and that
we still have no idea how many slots Google will give us and who we
will select this year (this will be 22nd April).

On Tue, Apr 12, 2016 at 10:03 AM, fitz <[hidden email]> wrote:

> Hello Dear devs,
>
> I am Fitz Lee, a CS Master's student from the University of Chinese Academy
> of Sciences. I'm very interested in this project, XWiki authenticator
> Android. I have submitted the final application for Gsoc2016
> (https://drive.google.com/file/d/0ByNx4jI3PEaNaGRxMkt0cUU3SjA/view?usp=sharing
> ).
> In order to furtherly understand the authenticator project, I have developed
> this android demo (https://github.com/fitzlee/SampleSyncAdapter), which is
> based on SampleSyncAdapter Google Android Sample. By deeply Analyzing the
> SampleSyncAdapter source,  I have implemented the material design(>=4.4) ui,
> the synchronization of contacts and the access of other apps .  But some
> functions in google server(https://samplesyncadapter2.appspot.com/sync)
> can't work well so that the client-to-server Synchronization function can't
> be tested and verified, and it needs to cooperate with server.  In my github
> repository(https://github.com/fitzlee/SampleSyncAdapter), I also show my
> analysis about the authenticator, synchronization, contactmanager, sign-in,
> sign-up and the whole process of the app. And now I am trying to develop the
> XWiki android authenticator project.
>
> Please consider my application, and I am eager to join this project and make
> a contribution. It's my first time to join the open source organization for
> enhancing my teamwork and technical skills. Please give me a chance, and I
> will try my best. If there is anything I can do for this project , I will be
> very happy.
>
> Here, i also have some questions which confuse me during my development:
> 1. contact synchronization
> (1)Situation:
> Now I have implemented the server-to-app synchronization with the modified
> SampleSyncAdapter (https://github.com/fitzlee/SampleSyncAdapter), and this
> demo can download contacts from server to local sqlite3 database. Also I can
> edit and modify the local contact and from logcat I have seen the dirty
> contacts being sent to the server. But the synchronization of server can't
> work so that I can't test this function.
> (2)Problem:
> Moreover, by analyzing the XWiki android authenticator in the repository
> (https://github.com/xwiki-contrib/android-authenticator). I have seen that
> some function has not been implemented, like getDirtyContacts and
> getRawContact in ContactManager. And the process of synchronisation in
> SynAdapter_onPerformSync also confuse me, like "ensureXWikiGroupExists>>
> XWikiConnector.getUsers>> ContactManager.updateContacts>>
> ContactManager.updateStatusMessages". I think it should be this process,
> like "ContactManager.getDirtyContacts>> NetworkUtilities.syncContacts>>
> ContactManager.updateContacts". Therefore, I don't know whether there is
> something wrong with me.  Could you give me some advice?

Yes contact synchronization in
https://github.com/xwiki-contrib/android-authenticator is not the
beginning or an experiment I never had time to finish so it's more
pseudo code that never worked yet.

>
> 2. A test xwiki server and test user which may help me a lot to develop this
> project for testing.
> I have analysed the sampleSynAdapter and implemented some function, for
> example material design(>=4.4), version support(2.3 with v7 library) and the
> synchronisation from server to the android local sqlite3
> database(contacts2.db) using ContactManager.But when client sends some dirty
> contact data to server, the synchronisation of server in google appengine
> can't work well so that I can't test my app's synchronisation. And the
> SampleSyncAdapter server also can't provide me more apis,like signing up and
> other necessary function.I have tried to upload a python server to google
> appengine,but failed because of the incompatibility between the source code
> by python version 2.5 and the cloud platform by 2.7 version.
> Question: Please if possible, could i have a test user and some server apis
> in xwiki server, or maybe i should write a test server by myself?

I see two main possibility for this:
* the first thing you should do I think is download the jetty/hsqld
all in one distribution on
http://www.xwiki.org/xwiki/bin/view/Main/Download and use that as test
server (you have admin right in it and can create as many test users
or groups as you want)
* as soon as you want to test volume and compatibility with existing
instance of XWiki you can register on http://www.xwiki.org which
contains 1519 users right now

>
> 3. requirement
> I think this project mainly has the following requirements.

> (1) sign in
> it is easy,just like my analysis of android SampleSyncAdapter, including the
> server connection with XWikiconnector and the account added by
> AccountManager

Don't reduce too quickly the level of difficulty on this side, one
thing you will have to work around is that standard XWiki instance
have no token based authentication so you will have to hack an as safe
as possible BASIC auth based implementation of Android authenticator
(which mean users of the authenticator can't just ask for the token
and connect to XWiki server).

> (2) sign up
> may also need some other api, like getting a list of xwiki user, adding
> friends which can be synchronized in the local phone contacts. Also other
> activitie may be possibly added, therefor the authenticator app will be very
> complex.
> (3) synchronization of contacts
> (4) edit the contact
> (5) access by other apps
> Question: Are there more other requirements in this app, like adding
> friends(general person) and creating new xwiki account(administrator)?
> maybe it will cause more demands and be more complex.
>

There is no real "friends" system in standard XWiki and anyway the
main use case for this application being intranets you usually want to
simply synchronize all users of the wiki since those are your
coworkers. An improvement would be to allow the user to select a list
of XWiki groups to synchronize if you don't want the whole wiki in a
big company or public wiki like xwiki.org for example.

> 4. support version and ui
> (1) ui design
> * material design >=4.4 with the support library support-v7
> (2) support version
> * The ui design can support the lowest 2.3 version and the android
> sampleSynAdapter can also support 2.3 version. So I think our authenticator
> app can support the lowest 2.3 version if needed.
> Question: Maybe there are somethings I have not noticed, so this conclusion
> is wrong, please give me some advice? Is that OK?

Supporting the lowest possible version is always nicer for users but
according to http://developer.android.com/about/dashboards/index.html
no need to go beyond 4.1.

4.4 seems to still be a bit too recent and might left behind too many users.

>
> 5. account permission
> In AccountGeneral.java there are two permissions , like
> AUTHTOKEN_TYPE_READ_ONLY, AUTHTOKEN_TYPE_FULL_ACCESS.  Could you tell me
> what the permissions main?  other xwiki instance access  limits ?  Account
> manager? And where should I use them?

You have many right on XWiki (and any extension can add more) plus it
depend what part of the wiki you are accessing.

But since you don't have any concept of token associated to an
application in standard XWiki the application will have whatever right
the user have so I guess you can return AUTHTOKEN_TYPE_FULL_ACCESS all
the time in the Android authenticator (then the application will have
to deal with 403 errors).

>
> I am looking forward to hearing from you. Thank you very much.
>
> Best Regards
> Fitz Lee | UCAS Master
> Email&Skype: [hidden email]
> Github&Homepage: https://github.com/fitzlee
>
> University of Chinese Academy of Sciences(UCAS)
> Shijingshan District, Beijing, China
>
>
>
>
> --
> View this message in context: http://xwiki.475771.n2.nabble.com/Questions-Gsoc2016-XWiki-Android-authenticator-tp7598932.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

[fitz]

Hi Thomas,


Thank you so much for your reply and recognition.


2016-04-12 17:18 GMT+08:00 Thomas Mortagne <[hidden email]>:

> Hi Fitz,
>
> Great to see so much motivation from you :)
>
> Just don't forget that GSOC coding period is not started yet and that
> we still have no idea how many slots Google will give us and who we
> will select this year (this will be 22nd April).
>
>
Yeah, I know the coding period of GSoC, and now I'm just striving and
looking forward to get this project. If I really do not pass the GSoC
application, it doesn't matter and I have learned a lot. As I have said, I
will be very happy if there is anything I can help.


> Yes contact synchronization in
> https://github.com/xwiki-contrib/android-authenticator is not the
> beginning or an experiment I never had time to finish so it's more
> pseudo code that never worked yet.


Considering the XWikiRESTfulAPIs in
http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI, the apis
have been well designed so that maybe I can't modify those apis. I should
just make use of the existing api resources to design the synchronization
of contacts and the process of sign-in and sign-up.

Since there isn't the api like "/sync" in sampleSyncAdapter
google-engine-server, which can help us to get update contacts when sending
the phone's dirty contacts and the last time of synchronization to server,
we cann't use the synchronization mechanism in SampleSyncAdapter. I think
maybe we can use the following method to synchronize contacts.

* server to client (update local contacts from server when needed):
In the function, SynAdapter.onPerformSync(), the process is
"XWikiConnector.getAllUsers>> compare with the local contacts and find the
contacts which should be updated >> ContactManager.updateContacts".
Available apis:
GetAllUserList: curl
http://localhost:8080/xwiki/rest/wikis/query?q=object:XWiki.XWikiUsers
GetUserInfo: curl
http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/FitzLee/objects/XWiki.XWikiUsers/0

* client to server (edit, add, delete contacts and meanwhile synchronize
from client to server):
When editing, adding or deleting contacts in android activities, we should
first request the xwiki server. Update contacts if allowed, or discard the
modification if not be authorized or have no permission.
Available apis:
EditUser: curl -u FitzLee:fitz2xwiki -X PUT -H "Content-type:
application/x-www-form-urlencoded" -H "Accept: application/xml" -d
"className=XWiki.XWikiUsers" -d "property#company=iie"
http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/FitzLee/objects/XWiki.XWikiUsers/0

I see two main possibility for this:
> * the first thing you should do I think is download the jetty/hsqld
> all in one distribution on
> http://www.xwiki.org/xwiki/bin/view/Main/Download and use that as test
> server (you have admin right in it and can create as many test users
> or groups as you want)
> * as soon as you want to test volume and compatibility with existing
> instance of XWiki you can register on http://www.xwiki.org which
> contains 1519 users right now
>

I have downloaded the enterprise xwiki jetty server 8.0 and tried to create
some applications and understand the features of the server. Using the
administrator Admin:admin, I have create some users and groups. And I use
the python script curl to learn how to get user-list, group-list and how to
modify them with the restfull apis. In addition, I find a demo which is
useful for me to be familiar with the apis, like
xwiki-contrib/android-client(https://github.com/xwiki-contrib/android-client).
And I will write my own android restful interactive method, mainly used for
the authentication and the management of users and groups.

But for testing the volume and compatibility of the synchronization in
SynAdapter.onPerformSync(), how do we compare the contact differences
between server and client and find the update contacts which need to be
updated?  It's a big problem if there are 1519 users and maybe I should
compare one by one to find which contact should be updated because
there'are no relevant apis to get the need-to-update contacts from server
after the last time of synchronization.

> (1) sign in
> > it is easy,just like my analysis of android SampleSyncAdapter, including
> the
> > server connection with XWikiconnector and the account added by
> > AccountManager
>
> Don't reduce too quickly the level of difficulty on this side, one
> thing you will have to work around is that standard XWiki instance
> have no token based authentication so you will have to hack an as safe
> as possible BASIC auth based implementation of Android authenticator
> (which mean users of the authenticator can't just ask for the token
> and connect to XWiki server).

Thank you for your reminder.  From the restfull apis, I have seen the two
methods of authentication,  including HTTP BASIC Auth and XWiki session
auth.  But Question is how users of the authenticator to connect to XWiki
server without username and password as I can't modify the authentication
method in the server and can only use the BASIC Auth?  use BASE64 to
encrypt the password? or ask for the session and communicate with server?
and BASE64 can just enhance the security in some extent. and maybe we can
use the https to ensure the authenticator security. I am so confused. Could
you give me some tips about authentication and security?

> > (3) synchronization of contacts
> > (4) edit the contact
> > (5) access by other apps
> > Question: Are there more other requirements in this app, like adding
> > friends(general person) and creating new xwiki account(administrator)?
> > maybe it will cause more demands and be more complex.
> >
>
> There is no real "friends" system in standard XWiki and anyway the
> main use case for this application being intranets you usually want to
> simply synchronize all users of the wiki since those are your
> coworkers. An improvement would be to allow the user to select a list
> of XWiki groups to synchronize if you don't want the whole wiki in a
> big company or public wiki like xwiki.org for example.

So there are two choices:
1.  Synchronize all contacts who are my coworkers
2.  Synchronize the contacts in the XWiki group which authenticator-user
wants to select.

> 4. support version and ui
> > (1) ui design
> > * material design >=4.4 with the support library support-v7
> > (2) support version
> > * The ui design can support the lowest 2.3 version and the android
> > sampleSynAdapter can also support 2.3 version. So I think our
> authenticator
> > app can support the lowest 2.3 version if needed.
> > Question: Maybe there are somethings I have not noticed, so this
> conclusion
> > is wrong, please give me some advice? Is that OK?
>
> Supporting the lowest possible version is always nicer for users but
> according to http://developer.android.com/about/dashboards/index.html
> no need to go beyond 4.1.
>
> 4.4 seems to still be a bit too recent and might left behind too many
> users.
>
>

Yes, so 4.1 may be the best choice. For the design of UI, the support
library support-v7 can solve the problem. And I will use the perfect
material design style if the android sdk version >= 4.4.

>
> > 5. account permission
> > In AccountGeneral.java there are two permissions , like
> > AUTHTOKEN_TYPE_READ_ONLY, AUTHTOKEN_TYPE_FULL_ACCESS.  Could you tell me
> > what the permissions main?  other xwiki instance access  limits ?
> Account
> > manager? And where should I use them?
>
> You have many right on XWiki (and any extension can add more) plus it
> depend what part of the wiki you are accessing.
>
> But since you don't have any concept of token associated to an
> application in standard XWiki the application will have whatever right
> the user have so I guess you can return AUTHTOKEN_TYPE_FULL_ACCESS all
> the time in the Android authenticator (then the application will have
> to deal with 403 errors).

OK, I will return AUTHTOKEN_TYPE_FULL_ACCESS and deal with the unauthorized
or other response error.


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

 At last, should I use the xwiki JIRA to create a custom issue and give you
a pull requst when I have some new idea or make progress?

Best Regards,
Fitz Lee | UCAS Master
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs

[Thomas Mortagne]

On Thu, Apr 14, 2016 at 7:22 AM, Fitz Lee <[hidden email]> wrote:

> Hi Thomas,
>
>
> Thank you so much for your reply and recognition.
>
>
> 2016-04-12 17:18 GMT+08:00 Thomas Mortagne <[hidden email]>:
>
>> Hi Fitz,
>>
>> Great to see so much motivation from you :)
>>
>> Just don't forget that GSOC coding period is not started yet and that
>> we still have no idea how many slots Google will give us and who we
>> will select this year (this will be 22nd April).
>>
>>
> Yeah, I know the coding period of GSoC, and now I'm just striving and
> looking forward to get this project. If I really do not pass the GSoC
> application, it doesn't matter and I have learned a lot. As I have said, I
> will be very happy if there is anything I can help.
>
>
>> Yes contact synchronization in
>> https://github.com/xwiki-contrib/android-authenticator is not the
>> beginning or an experiment I never had time to finish so it's more
>> pseudo code that never worked yet.
>
>
> Considering the XWikiRESTfulAPIs in
> http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI, the apis
> have been well designed so that maybe I can't modify those apis. I should
> just make use of the existing api resources to design the synchronization
> of contacts and the process of sign-in and sign-up.
>
> Since there isn't the api like "/sync" in sampleSyncAdapter
> google-engine-server, which can help us to get update contacts when sending
> the phone's dirty contacts and the last time of synchronization to server,
> we cann't use the synchronization mechanism in SampleSyncAdapter. I think
> maybe we can use the following method to synchronize contacts.
>
> * server to client (update local contacts from server when needed):
> In the function, SynAdapter.onPerformSync(), the process is
> "XWikiConnector.getAllUsers>> compare with the local contacts and find the
> contacts which should be updated >> ContactManager.updateContacts".
> Available apis:
> GetAllUserList: curl
> http://localhost:8080/xwiki/rest/wikis/query?q=object:XWiki.XWikiUsers
> GetUserInfo: curl
> http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/FitzLee/objects/XWiki.XWikiUsers/0
>
> * client to server (edit, add, delete contacts and meanwhile synchronize
> from client to server):
> When editing, adding or deleting contacts in android activities, we should
> first request the xwiki server. Update contacts if allowed, or discard the
> modification if not be authorized or have no permission.
> Available apis:
> EditUser: curl -u FitzLee:fitz2xwiki -X PUT -H "Content-type:
> application/x-www-form-urlencoded" -H "Accept: application/xml" -d
> "className=XWiki.XWikiUsers" -d "property#company=iie"
> http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/FitzLee/objects/XWiki.XWikiUsers/0
>

Yes the goal for now is to have an application working on any existing
wiki (lets say not older than 7.4.x since that's the current LTS but
the lowest the better).

You can if you have time implement new REST APIs (it's always usefull
anyway) that would improve performances for example but the
application should not assume that these new API would exist in the
target instance that could be too old for it. So in the GSOC timeframe
it would be safer to just do with what already exist which indeed
might give more work to the application than a specific API designed
specifically for synchronization but it should be doable.

> I see two main possibility for this:
>> * the first thing you should do I think is download the jetty/hsqld
>> all in one distribution on
>> http://www.xwiki.org/xwiki/bin/view/Main/Download and use that as test
>> server (you have admin right in it and can create as many test users
>> or groups as you want)
>> * as soon as you want to test volume and compatibility with existing
>> instance of XWiki you can register on http://www.xwiki.org which
>> contains 1519 users right now
>>
>
> I have downloaded the enterprise xwiki jetty server 8.0 and tried to create
> some applications and understand the features of the server. Using the
> administrator Admin:admin, I have create some users and groups. And I use
> the python script curl to learn how to get user-list, group-list and how to
> modify them with the restfull apis. In addition, I find a demo which is
> useful for me to be familiar with the apis, like
> xwiki-contrib/android-client(https://github.com/xwiki-contrib/android-client).
> And I will write my own android restful interactive method, mainly used for
> the authentication and the management of users and groups.
>
> But for testing the volume and compatibility of the synchronization in
> SynAdapter.onPerformSync(), how do we compare the contact differences
> between server and client and find the update contacts which need to be
> updated?  It's a big problem if there are 1519 users and maybe I should
> compare one by one to find which contact should be updated because
> there'are no relevant apis to get the need-to-update contacts from server
> after the last time of synchronization.

You don't have a sync API but you have a search API in which you can
request all the documents containing a user object and that were
modified after some date for example. You can use either sql or solr.

>
>> (1) sign in
>> > it is easy,just like my analysis of android SampleSyncAdapter, including
>> the
>> > server connection with XWikiconnector and the account added by
>> > AccountManager
>>
>> Don't reduce too quickly the level of difficulty on this side, one
>> thing you will have to work around is that standard XWiki instance
>> have no token based authentication so you will have to hack an as safe
>> as possible BASIC auth based implementation of Android authenticator
>> (which mean users of the authenticator can't just ask for the token
>> and connect to XWiki server).
>
>
> Thank you for your reminder.  From the restfull apis, I have seen the two
> methods of authentication,  including HTTP BASIC Auth and XWiki session
> auth.  But Question is how users of the authenticator to connect to XWiki
> server without username and password as I can't modify the authentication
> method in the server and can only use the BASIC Auth?  use BASE64 to
> encrypt the password? or ask for the session and communicate with server?
> and BASE64 can just enhance the security in some extent. and maybe we can
> use the https to ensure the authenticator security. I am so confused. Could
> you give me some tips about authentication and security?

I did not had time to experiment on this but here as some ideas of
things to try:

1) return whatever identify the session (I had forgotten about session
access, thanks for the reminder :)). Then the application put that
session id in whatever http client tool it want to use. That's
probably the safest and what look the most like a the classical token
based access.

2) provide a preconfigured instance of Android HTTP Client in which:
2.a) a sessions have already been started with the server and the HTTP
Client keep it alive (that's the safest I can think of right now)
2.b) the BASIC auth header cannot be read from outside (for example
extends it in a custom class and forbid any public access to the
Authorization header) that can be used to request the XWiki server

3) the worst case scenario is to return the BASIC auth header (it
looks like "Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l"). It's
encoded but it's easy to decode. The application would just set it in
whatever http tool it's using. An application can use an authenticator
only if the user allows it and the alternative is that each
application deal with login/password on its side so it's still better
than nothing :)

Whatever solution is chosen the best would be to provide some small
helper library that deal with XWiki authenticator and for example
generate a pre-configured http client instance for the application
with what the authenticator return. That way it's easier to change the
way the authenticator works without breaking application (at least
application that use the recommended library).

>
>
>> > (3) synchronization of contacts
>> > (4) edit the contact
>> > (5) access by other apps
>> > Question: Are there more other requirements in this app, like adding
>> > friends(general person) and creating new xwiki account(administrator)?
>> > maybe it will cause more demands and be more complex.
>> >
>>
>> There is no real "friends" system in standard XWiki and anyway the
>> main use case for this application being intranets you usually want to
>> simply synchronize all users of the wiki since those are your
>> coworkers. An improvement would be to allow the user to select a list
>> of XWiki groups to synchronize if you don't want the whole wiki in a
>> big company or public wiki like xwiki.org for example.
>
>
> So there are two choices:
> 1.  Synchronize all contacts who are my coworkers
> 2.  Synchronize the contacts in the XWiki group which authenticator-user
> wants to select.

And possibly other idea you may have while knowing XWiki better :)

But on my side 1 and 2 would already be great.

>
>> 4. support version and ui
>> > (1) ui design
>> > * material design >=4.4 with the support library support-v7
>> > (2) support version
>> > * The ui design can support the lowest 2.3 version and the android
>> > sampleSynAdapter can also support 2.3 version. So I think our
>> authenticator
>> > app can support the lowest 2.3 version if needed.
>> > Question: Maybe there are somethings I have not noticed, so this
>> conclusion
>> > is wrong, please give me some advice? Is that OK?
>>
>> Supporting the lowest possible version is always nicer for users but
>> according to http://developer.android.com/about/dashboards/index.html
>> no need to go beyond 4.1.
>>
>> 4.4 seems to still be a bit too recent and might left behind too many
>> users.
>>
>>
> Yes, so 4.1 may be the best choice. For the design of UI, the support
> library support-v7 can solve the problem. And I will use the perfect
> material design style if the android sdk version >= 4.4.
>
>>
>> > 5. account permission
>> > In AccountGeneral.java there are two permissions , like
>> > AUTHTOKEN_TYPE_READ_ONLY, AUTHTOKEN_TYPE_FULL_ACCESS.  Could you tell me
>> > what the permissions main?  other xwiki instance access  limits ?
>> Account
>> > manager? And where should I use them?
>>
>> You have many right on XWiki (and any extension can add more) plus it
>> depend what part of the wiki you are accessing.
>>
>> But since you don't have any concept of token associated to an
>> application in standard XWiki the application will have whatever right
>> the user have so I guess you can return AUTHTOKEN_TYPE_FULL_ACCESS all
>> the time in the Android authenticator (then the application will have
>> to deal with 403 errors).
>
>
> OK, I will return AUTHTOKEN_TYPE_FULL_ACCESS and deal with the unauthorized
> or other response error.
>
>
>>
>> --
>> Thomas Mortagne
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>  At last, should I use the xwiki JIRA to create a custom issue and give you
> a pull requst when I have some new idea or make progress?

Anyone who is a member of the XWiki Contrib organization (basically
anyone who ask to be) have write access on
https://github.com/xwiki-contrib/android-authenticator so no need for
pull request. It's not like it was in a very stable state right now
anyway :)

>
> Best Regards,
> Fitz Lee | UCAS Master
> _______________________________________________
> 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

[fitz]

Hello Thomas,

Thank you very much and I really appreciate your help and guidance. And thank you for helping me improve.

I will firstly use the existing REST APIs to develop this project, And maybe in the future I can make some specific APIs to improve performance if time permits. 

Yes, the search APIs can help me get need-update contacts after the last-sync-time and solve the one by one comparing problem. And I will be familiar with the use of search APIs as soon as possible so that I can use it in the synchronization code.  Thank you for solving my confusion. 

And for authentication and security, considering your precious advice, I will try to use the first idea, and just return the session so that other xwiki android apps can use the httpclient with this session id to authenticate with the server.  And I will firstly implement this method and test the effectiveness of this scheme as soon as possible. 

For the xwiki-contrib, I will ask to join the group, develop this android project and maybe make a contribution.

Yours sincerely

Fitz Lee

2016-04-14 17:33 GMT+08:00 Thomas Mortagne [via XWiki] <[hidden email]>:

On Thu, Apr 14, 2016 at 7:22 AM, Fitz Lee <[hidden email]> wrote:

> Hi Thomas,
>
>
> Thank you so much for your reply and recognition.
>
>

> 2016-04-12 17:18 GMT+08:00 Thomas Mortagne <[hidden email]>:

>
>> Hi Fitz,
>>
>> Great to see so much motivation from you :)
>>
>> Just don't forget that GSOC coding period is not started yet and that
>> we still have no idea how many slots Google will give us and who we
>> will select this year (this will be 22nd April).
>>
>>
> Yeah, I know the coding period of GSoC, and now I'm just striving and
> looking forward to get this project. If I really do not pass the GSoC
> application, it doesn't matter and I have learned a lot. As I have said, I
> will be very happy if there is anything I can help.
>
>
>> Yes contact synchronization in
>> https://github.com/xwiki-contrib/android-authenticator is not the
>> beginning or an experiment I never had time to finish so it's more
>> pseudo code that never worked yet.
>
>
> Considering the XWikiRESTfulAPIs in
> http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI, the apis
> have been well designed so that maybe I can't modify those apis. I should
> just make use of the existing api resources to design the synchronization
> of contacts and the process of sign-in and sign-up.
>
> Since there isn't the api like "/sync" in sampleSyncAdapter
> google-engine-server, which can help us to get update contacts when sending
> the phone's dirty contacts and the last time of synchronization to server,
> we cann't use the synchronization mechanism in SampleSyncAdapter. I think
> maybe we can use the following method to synchronize contacts.
>
> * server to client (update local contacts from server when needed):
> In the function, SynAdapter.onPerformSync(), the process is
> "XWikiConnector.getAllUsers>> compare with the local contacts and find the
> contacts which should be updated >> ContactManager.updateContacts".
> Available apis:
> GetAllUserList: curl
> http://localhost:8080/xwiki/rest/wikis/query?q=object:XWiki.XWikiUsers
> GetUserInfo: curl
> http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/FitzLee/objects/XWiki.XWikiUsers/0
>
> * client to server (edit, add, delete contacts and meanwhile synchronize
> from client to server):
> When editing, adding or deleting contacts in android activities, we should
> first request the xwiki server. Update contacts if allowed, or discard the
> modification if not be authorized or have no permission.
> Available apis:
> EditUser: curl -u FitzLee:fitz2xwiki -X PUT -H "Content-type:
> application/x-www-form-urlencoded" -H "Accept: application/xml" -d
> "className=XWiki.XWikiUsers" -d "property#company=iie"
> http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/FitzLee/objects/XWiki.XWikiUsers/0
>

Yes the goal for now is to have an application working on any existing
wiki (lets say not older than 7.4.x since that's the current LTS but
the lowest the better).

You can if you have time implement new REST APIs (it's always usefull
anyway) that would improve performances for example but the
application should not assume that these new API would exist in the
target instance that could be too old for it. So in the GSOC timeframe
it would be safer to just do with what already exist which indeed
might give more work to the application than a specific API designed
specifically for synchronization but it should be doable.

> I see two main possibility for this:
>> * the first thing you should do I think is download the jetty/hsqld
>> all in one distribution on
>> http://www.xwiki.org/xwiki/bin/view/Main/Download and use that as test
>> server (you have admin right in it and can create as many test users
>> or groups as you want)
>> * as soon as you want to test volume and compatibility with existing
>> instance of XWiki you can register on http://www.xwiki.org which
>> contains 1519 users right now
>>
>
> I have downloaded the enterprise xwiki jetty server 8.0 and tried to create
> some applications and understand the features of the server. Using the
> administrator Admin:admin, I have create some users and groups. And I use
> the python script curl to learn how to get user-list, group-list and how to
> modify them with the restfull apis. In addition, I find a demo which is
> useful for me to be familiar with the apis, like
> xwiki-contrib/android-client(https://github.com/xwiki-contrib/android-client).
> And I will write my own android restful interactive method, mainly used for
> the authentication and the management of users and groups.
>
> But for testing the volume and compatibility of the synchronization in
> SynAdapter.onPerformSync(), how do we compare the contact differences
> between server and client and find the update contacts which need to be
> updated?  It's a big problem if there are 1519 users and maybe I should
> compare one by one to find which contact should be updated because
> there'are no relevant apis to get the need-to-update contacts from server
> after the last time of synchronization.

You don't have a sync API but you have a search API in which you can
request all the documents containing a user object and that were
modified after some date for example. You can use either sql or solr.

>
>> (1) sign in

>> > it is easy,just like my analysis of android SampleSyncAdapter, including
>> the
>> > server connection with XWikiconnector and the account added by
>> > AccountManager
>>
>> Don't reduce too quickly the level of difficulty on this side, one
>> thing you will have to work around is that standard XWiki instance
>> have no token based authentication so you will have to hack an as safe
>> as possible BASIC auth based implementation of Android authenticator
>> (which mean users of the authenticator can't just ask for the token
>> and connect to XWiki server).
>
>
> Thank you for your reminder.  From the restfull apis, I have seen the two
> methods of authentication,  including HTTP BASIC Auth and XWiki session
> auth.  But Question is how users of the authenticator to connect to XWiki
> server without username and password as I can't modify the authentication
> method in the server and can only use the BASIC Auth?  use BASE64 to
> encrypt the password? or ask for the session and communicate with server?
> and BASE64 can just enhance the security in some extent. and maybe we can
> use the https to ensure the authenticator security. I am so confused. Could
> you give me some tips about authentication and security?

I did not had time to experiment on this but here as some ideas of
things to try:

1) return whatever identify the session (I had forgotten about session
access, thanks for the reminder :)). Then the application put that
session id in whatever http client tool it want to use. That's
probably the safest and what look the most like a the classical token
based access.

2) provide a preconfigured instance of Android HTTP Client in which:
2.a) a sessions have already been started with the server and the HTTP
Client keep it alive (that's the safest I can think of right now)
2.b) the BASIC auth header cannot be read from outside (for example
extends it in a custom class and forbid any public access to the
Authorization header) that can be used to request the XWiki server

3) the worst case scenario is to return the BASIC auth header (it
looks like "Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l"). It's
encoded but it's easy to decode. The application would just set it in
whatever http tool it's using. An application can use an authenticator
only if the user allows it and the alternative is that each
application deal with login/password on its side so it's still better
than nothing :)

Whatever solution is chosen the best would be to provide some small
helper library that deal with XWiki authenticator and for example
generate a pre-configured http client instance for the application
with what the authenticator return. That way it's easier to change the
way the authenticator works without breaking application (at least
application that use the recommended library).

>
>
>> > (3) synchronization of contacts

>> > (4) edit the contact
>> > (5) access by other apps
>> > Question: Are there more other requirements in this app, like adding
>> > friends(general person) and creating new xwiki account(administrator)?
>> > maybe it will cause more demands and be more complex.
>> >
>>
>> There is no real "friends" system in standard XWiki and anyway the
>> main use case for this application being intranets you usually want to
>> simply synchronize all users of the wiki since those are your
>> coworkers. An improvement would be to allow the user to select a list
>> of XWiki groups to synchronize if you don't want the whole wiki in a
>> big company or public wiki like xwiki.org for example.
>
>
> So there are two choices:
> 1.  Synchronize all contacts who are my coworkers
> 2.  Synchronize the contacts in the XWiki group which authenticator-user
> wants to select.

And possibly other idea you may have while knowing XWiki better :)

But on my side 1 and 2 would already be great.

>

>> 4. support version and ui

>> > (1) ui design
>> > * material design >=4.4 with the support library support-v7
>> > (2) support version
>> > * The ui design can support the lowest 2.3 version and the android
>> > sampleSynAdapter can also support 2.3 version. So I think our
>> authenticator
>> > app can support the lowest 2.3 version if needed.
>> > Question: Maybe there are somethings I have not noticed, so this
>> conclusion
>> > is wrong, please give me some advice? Is that OK?
>>
>> Supporting the lowest possible version is always nicer for users but
>> according to http://developer.android.com/about/dashboards/index.html
>> no need to go beyond 4.1.
>>
>> 4.4 seems to still be a bit too recent and might left behind too many
>> users.
>>
>>
> Yes, so 4.1 may be the best choice. For the design of UI, the support
> library support-v7 can solve the problem. And I will use the perfect
> material design style if the android sdk version >= 4.4.
>
>>
>> > 5. account permission
>> > In AccountGeneral.java there are two permissions , like
>> > AUTHTOKEN_TYPE_READ_ONLY, AUTHTOKEN_TYPE_FULL_ACCESS.  Could you tell me
>> > what the permissions main?  other xwiki instance access  limits ?
>> Account
>> > manager? And where should I use them?
>>
>> You have many right on XWiki (and any extension can add more) plus it
>> depend what part of the wiki you are accessing.
>>
>> But since you don't have any concept of token associated to an
>> application in standard XWiki the application will have whatever right
>> the user have so I guess you can return AUTHTOKEN_TYPE_FULL_ACCESS all
>> the time in the Android authenticator (then the application will have
>> to deal with 403 errors).
>
>
> OK, I will return AUTHTOKEN_TYPE_FULL_ACCESS and deal with the unauthorized
> or other response error.
>
>
>>
>> --
>> Thomas Mortagne
>> _______________________________________________
>> devs mailing list

>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>  At last, should I use the xwiki JIRA to create a custom issue and give you
> a pull requst when I have some new idea or make progress?

Anyone who is a member of the XWiki Contrib organization (basically
anyone who ask to be) have write access on
https://github.com/xwiki-contrib/android-authenticator so no need for
pull request. It's not like it was in a very stable state right now
anyway :)

>
> Best Regards,
> Fitz Lee | UCAS Master
> _______________________________________________
> 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

---

If you reply to this email, your message will be added to the discussion below:

http://xwiki.475771.n2.nabble.com/Questions-Gsoc2016-XWiki-Android-authenticator-tp7598932p7598982.html

To unsubscribe from Questions, Gsoc2016, XWiki Android-authenticator, click here.
NAML

[Thomas Mortagne]

On Fri, Apr 15, 2016 at 6:25 AM, fitz <[hidden email]> wrote:

> Hello Thomas,
>
> Thank you very much and I really appreciate your help and guidance. And
> thank you for helping me improve.
>
> I will firstly use the existing REST APIs to develop this project, And
> maybe in the future I can make some specific APIs to improve performance if
> time permits.
>
> Yes, the search APIs can help me get need-update contacts after the
> last-sync-time and solve the one by one comparing problem. And I will be
> familiar with the use of search APIs as soon as possible so that I can use
> it in the synchronization code.  Thank you for solving my confusion.
>
> And for authentication and security, considering your precious advice, I
> will try to use the first idea, and just return the session so that other
> xwiki android apps can use the httpclient with this session id to
> authenticate with the server.  And I will firstly implement this method and
> test the effectiveness of this scheme as soon as possible.

All that sounds good.

>
> For the xwiki-contrib, I will ask to join the group, develop this android
> project and maybe make a contribution.

Looks like you are already member of XWiki Contrib actually.

>
> Yours sincerely
> Fitz Lee
>
>
> 2016-04-14 17:33 GMT+08:00 Thomas Mortagne [via XWiki] <
> [hidden email]>:
>
>> On Thu, Apr 14, 2016 at 7:22 AM, Fitz Lee <[hidden email]
>> <http:///user/SendEmail.jtp?type=node&node=7598982&i=0>> wrote:
>>
>> > Hi Thomas,
>> >
>> >
>> > Thank you so much for your reply and recognition.
>> >
>> >
>> > 2016-04-12 17:18 GMT+08:00 Thomas Mortagne <[hidden email]
>> <http:///user/SendEmail.jtp?type=node&node=7598982&i=1>>:
>> >
>> >> Hi Fitz,
>> >>
>> >> Great to see so much motivation from you :)
>> >>
>> >> Just don't forget that GSOC coding period is not started yet and that
>> >> we still have no idea how many slots Google will give us and who we
>> >> will select this year (this will be 22nd April).
>> >>
>> >>
>> > Yeah, I know the coding period of GSoC, and now I'm just striving and
>> > looking forward to get this project. If I really do not pass the GSoC
>> > application, it doesn't matter and I have learned a lot. As I have said,
>> I
>> > will be very happy if there is anything I can help.
>> >
>> >
>> >> Yes contact synchronization in
>> >> https://github.com/xwiki-contrib/android-authenticator is not the
>> >> beginning or an experiment I never had time to finish so it's more
>> >> pseudo code that never worked yet.
>> >
>> >
>> > Considering the XWikiRESTfulAPIs in
>> > http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI, the
>> apis
>> > have been well designed so that maybe I can't modify those apis. I
>> should
>> > just make use of the existing api resources to design the
>> synchronization
>> > of contacts and the process of sign-in and sign-up.
>> >
>> > Since there isn't the api like "/sync" in sampleSyncAdapter
>> > google-engine-server, which can help us to get update contacts when
>> sending
>> > the phone's dirty contacts and the last time of synchronization to
>> server,
>> > we cann't use the synchronization mechanism in SampleSyncAdapter. I
>> think
>> > maybe we can use the following method to synchronize contacts.
>> >
>> > * server to client (update local contacts from server when needed):
>> > In the function, SynAdapter.onPerformSync(), the process is
>> > "XWikiConnector.getAllUsers>> compare with the local contacts and find
>> the
>> > contacts which should be updated >> ContactManager.updateContacts".
>> > Available apis:
>> > GetAllUserList: curl
>> > http://localhost:8080/xwiki/rest/wikis/query?q=object:XWiki.XWikiUsers
>> > GetUserInfo: curl
>> >
>> http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/FitzLee/objects/XWiki.XWikiUsers/0
>> >
>> > * client to server (edit, add, delete contacts and meanwhile synchronize
>> > from client to server):
>> > When editing, adding or deleting contacts in android activities, we
>> should
>> > first request the xwiki server. Update contacts if allowed, or discard
>> the
>> > modification if not be authorized or have no permission.
>> > Available apis:
>> > EditUser: curl -u FitzLee:fitz2xwiki -X PUT -H "Content-type:
>> > application/x-www-form-urlencoded" -H "Accept: application/xml" -d
>> > "className=XWiki.XWikiUsers" -d "property#company=iie"
>> >
>> http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/FitzLee/objects/XWiki.XWikiUsers/0
>> >
>>
>> Yes the goal for now is to have an application working on any existing
>> wiki (lets say not older than 7.4.x since that's the current LTS but
>> the lowest the better).
>>
>> You can if you have time implement new REST APIs (it's always usefull
>> anyway) that would improve performances for example but the
>> application should not assume that these new API would exist in the
>> target instance that could be too old for it. So in the GSOC timeframe
>> it would be safer to just do with what already exist which indeed
>> might give more work to the application than a specific API designed
>> specifically for synchronization but it should be doable.
>>
>> > I see two main possibility for this:
>> >> * the first thing you should do I think is download the jetty/hsqld
>> >> all in one distribution on
>> >> http://www.xwiki.org/xwiki/bin/view/Main/Download and use that as test
>> >> server (you have admin right in it and can create as many test users
>> >> or groups as you want)
>> >> * as soon as you want to test volume and compatibility with existing
>> >> instance of XWiki you can register on http://www.xwiki.org which
>> >> contains 1519 users right now
>> >>
>> >
>> > I have downloaded the enterprise xwiki jetty server 8.0 and tried to
>> create
>> > some applications and understand the features of the server. Using the
>> > administrator Admin:admin, I have create some users and groups. And I
>> use
>> > the python script curl to learn how to get user-list, group-list and how
>> to
>> > modify them with the restfull apis. In addition, I find a demo which is
>> > useful for me to be familiar with the apis, like
>> > xwiki-contrib/android-client(
>> https://github.com/xwiki-contrib/android-client).
>> > And I will write my own android restful interactive method, mainly used
>> for
>> > the authentication and the management of users and groups.
>> >
>> > But for testing the volume and compatibility of the synchronization in
>> > SynAdapter.onPerformSync(), how do we compare the contact differences
>> > between server and client and find the update contacts which need to be
>> > updated?  It's a big problem if there are 1519 users and maybe I should
>> > compare one by one to find which contact should be updated because
>> > there'are no relevant apis to get the need-to-update contacts from
>> server
>> > after the last time of synchronization.
>>
>> You don't have a sync API but you have a search API in which you can
>> request all the documents containing a user object and that were
>> modified after some date for example. You can use either sql or solr.
>>
>> >
>> >> (1) sign in
>> >> > it is easy,just like my analysis of android SampleSyncAdapter,
>> including
>> >> the
>> >> > server connection with XWikiconnector and the account added by
>> >> > AccountManager
>> >>
>> >> Don't reduce too quickly the level of difficulty on this side, one
>> >> thing you will have to work around is that standard XWiki instance
>> >> have no token based authentication so you will have to hack an as safe
>> >> as possible BASIC auth based implementation of Android authenticator
>> >> (which mean users of the authenticator can't just ask for the token
>> >> and connect to XWiki server).
>> >
>> >
>> > Thank you for your reminder.  From the restfull apis, I have seen the
>> two
>> > methods of authentication,  including HTTP BASIC Auth and XWiki session
>> > auth.  But Question is how users of the authenticator to connect to
>> XWiki
>> > server without username and password as I can't modify the
>> authentication
>> > method in the server and can only use the BASIC Auth?  use BASE64 to
>> > encrypt the password? or ask for the session and communicate with
>> server?
>> > and BASE64 can just enhance the security in some extent. and maybe we
>> can
>> > use the https to ensure the authenticator security. I am so confused.
>> Could
>> > you give me some tips about authentication and security?
>>
>> I did not had time to experiment on this but here as some ideas of
>> things to try:
>>
>> 1) return whatever identify the session (I had forgotten about session
>> access, thanks for the reminder :)). Then the application put that
>> session id in whatever http client tool it want to use. That's
>> probably the safest and what look the most like a the classical token
>> based access.
>>
>> 2) provide a preconfigured instance of Android HTTP Client in which:
>> 2.a) a sessions have already been started with the server and the HTTP
>> Client keep it alive (that's the safest I can think of right now)
>> 2.b) the BASIC auth header cannot be read from outside (for example
>> extends it in a custom class and forbid any public access to the
>> Authorization header) that can be used to request the XWiki server
>>
>> 3) the worst case scenario is to return the BASIC auth header (it
>> looks like "Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l"). It's
>> encoded but it's easy to decode. The application would just set it in
>> whatever http tool it's using. An application can use an authenticator
>> only if the user allows it and the alternative is that each
>> application deal with login/password on its side so it's still better
>> than nothing :)
>>
>> Whatever solution is chosen the best would be to provide some small
>> helper library that deal with XWiki authenticator and for example
>> generate a pre-configured http client instance for the application
>> with what the authenticator return. That way it's easier to change the
>> way the authenticator works without breaking application (at least
>> application that use the recommended library).
>>
>> >
>> >
>> >> > (3) synchronization of contacts
>> >> > (4) edit the contact
>> >> > (5) access by other apps
>> >> > Question: Are there more other requirements in this app, like adding
>> >> > friends(general person) and creating new xwiki
>> account(administrator)?
>> >> > maybe it will cause more demands and be more complex.
>> >> >
>> >>
>> >> There is no real "friends" system in standard XWiki and anyway the
>> >> main use case for this application being intranets you usually want to
>> >> simply synchronize all users of the wiki since those are your
>> >> coworkers. An improvement would be to allow the user to select a list
>> >> of XWiki groups to synchronize if you don't want the whole wiki in a
>> >> big company or public wiki like xwiki.org for example.
>> >
>> >
>> > So there are two choices:
>> > 1.  Synchronize all contacts who are my coworkers
>> > 2.  Synchronize the contacts in the XWiki group which authenticator-user
>> > wants to select.
>>
>> And possibly other idea you may have while knowing XWiki better :)
>>
>> But on my side 1 and 2 would already be great.
>>
>> >
>> >> 4. support version and ui
>> >> > (1) ui design
>> >> > * material design >=4.4 with the support library support-v7
>> >> > (2) support version
>> >> > * The ui design can support the lowest 2.3 version and the android
>> >> > sampleSynAdapter can also support 2.3 version. So I think our
>> >> authenticator
>> >> > app can support the lowest 2.3 version if needed.
>> >> > Question: Maybe there are somethings I have not noticed, so this
>> >> conclusion
>> >> > is wrong, please give me some advice? Is that OK?
>> >>
>> >> Supporting the lowest possible version is always nicer for users but
>> >> according to http://developer.android.com/about/dashboards/index.html
>> >> no need to go beyond 4.1.
>> >>
>> >> 4.4 seems to still be a bit too recent and might left behind too many
>> >> users.
>> >>
>> >>
>> > Yes, so 4.1 may be the best choice. For the design of UI, the support
>> > library support-v7 can solve the problem. And I will use the perfect
>> > material design style if the android sdk version >= 4.4.
>> >
>> >>
>> >> > 5. account permission
>> >> > In AccountGeneral.java there are two permissions , like
>> >> > AUTHTOKEN_TYPE_READ_ONLY, AUTHTOKEN_TYPE_FULL_ACCESS.  Could you tell
>> me
>> >> > what the permissions main?  other xwiki instance access  limits ?
>> >> Account
>> >> > manager? And where should I use them?
>> >>
>> >> You have many right on XWiki (and any extension can add more) plus it
>> >> depend what part of the wiki you are accessing.
>> >>
>> >> But since you don't have any concept of token associated to an
>> >> application in standard XWiki the application will have whatever right
>> >> the user have so I guess you can return AUTHTOKEN_TYPE_FULL_ACCESS all
>> >> the time in the Android authenticator (then the application will have
>> >> to deal with 403 errors).
>> >
>> >
>> > OK, I will return AUTHTOKEN_TYPE_FULL_ACCESS and deal with the
>> unauthorized
>> > or other response error.
>> >
>> >
>> >>
>> >> --
>> >> Thomas Mortagne
>> >> _______________________________________________
>> >> devs mailing list
>> >> [hidden email] <http:///user/SendEmail.jtp?type=node&node=7598982&i=2>
>> >> http://lists.xwiki.org/mailman/listinfo/devs
>> >>
>> >
>> >  At last, should I use the xwiki JIRA to create a custom issue and give
>> you
>> > a pull requst when I have some new idea or make progress?
>>
>> Anyone who is a member of the XWiki Contrib organization (basically
>> anyone who ask to be) have write access on
>> https://github.com/xwiki-contrib/android-authenticator so no need for
>> pull request. It's not like it was in a very stable state right now
>> anyway :)
>>
>> >
>> > Best Regards,
>> > Fitz Lee | UCAS Master
>> > _______________________________________________
>> > devs mailing list
>> > [hidden email] <http:///user/SendEmail.jtp?type=node&node=7598982&i=3>
>> > http://lists.xwiki.org/mailman/listinfo/devs
>>
>>
>>
>> --
>> Thomas Mortagne
>> _______________________________________________
>> devs mailing list
>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=7598982&i=4>
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>>
>> ------------------------------
>> If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://xwiki.475771.n2.nabble.com/Questions-Gsoc2016-XWiki-Android-authenticator-tp7598932p7598982.html
>> To unsubscribe from Questions, Gsoc2016, XWiki Android-authenticator, click
>> here
>> <
>> .
>> NAML
>> <http://xwiki.475771.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
>
>
>
> --
> View this message in context: http://xwiki.475771.n2.nabble.com/Questions-Gsoc2016-XWiki-Android-authenticator-tp7598932p7599003.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 Tue, Apr 19, 2016 at 12:56 PM, Thomas Mortagne
<[hidden email]> wrote:

> On Fri, Apr 15, 2016 at 6:25 AM, fitz <[hidden email]> wrote:
>> Hello Thomas,
>>
>> Thank you very much and I really appreciate your help and guidance. And
>> thank you for helping me improve.
>>
>> I will firstly use the existing REST APIs to develop this project, And
>> maybe in the future I can make some specific APIs to improve performance if
>> time permits.
>>
>> Yes, the search APIs can help me get need-update contacts after the
>> last-sync-time and solve the one by one comparing problem. And I will be
>> familiar with the use of search APIs as soon as possible so that I can use
>> it in the synchronization code.  Thank you for solving my confusion.
>>
>> And for authentication and security, considering your precious advice, I
>> will try to use the first idea, and just return the session so that other
>> xwiki android apps can use the httpclient with this session id to
>> authenticate with the server.  And I will firstly implement this method and
>> test the effectiveness of this scheme as soon as possible.
>
> All that sounds good.
>
>>
>> For the xwiki-contrib, I will ask to join the group, develop this android
>> project and maybe make a contribution.
>
> Looks like you are already member of XWiki Contrib actually.

Just saw the other mail (I'm a bit late with my mails...).

>
>>
>> Yours sincerely
>> Fitz Lee
>>
>>
>> 2016-04-14 17:33 GMT+08:00 Thomas Mortagne [via XWiki] <
>> [hidden email]>:
>>
>>> On Thu, Apr 14, 2016 at 7:22 AM, Fitz Lee <[hidden email]
>>> <http:///user/SendEmail.jtp?type=node&node=7598982&i=0>> wrote:
>>>
>>> > Hi Thomas,
>>> >
>>> >
>>> > Thank you so much for your reply and recognition.
>>> >
>>> >
>>> > 2016-04-12 17:18 GMT+08:00 Thomas Mortagne <[hidden email]
>>> <http:///user/SendEmail.jtp?type=node&node=7598982&i=1>>:
>>> >
>>> >> Hi Fitz,
>>> >>
>>> >> Great to see so much motivation from you :)
>>> >>
>>> >> Just don't forget that GSOC coding period is not started yet and that
>>> >> we still have no idea how many slots Google will give us and who we
>>> >> will select this year (this will be 22nd April).
>>> >>
>>> >>
>>> > Yeah, I know the coding period of GSoC, and now I'm just striving and
>>> > looking forward to get this project. If I really do not pass the GSoC
>>> > application, it doesn't matter and I have learned a lot. As I have said,
>>> I
>>> > will be very happy if there is anything I can help.
>>> >
>>> >
>>> >> Yes contact synchronization in
>>> >> https://github.com/xwiki-contrib/android-authenticator is not the
>>> >> beginning or an experiment I never had time to finish so it's more
>>> >> pseudo code that never worked yet.
>>> >
>>> >
>>> > Considering the XWikiRESTfulAPIs in
>>> > http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI, the
>>> apis
>>> > have been well designed so that maybe I can't modify those apis. I
>>> should
>>> > just make use of the existing api resources to design the
>>> synchronization
>>> > of contacts and the process of sign-in and sign-up.
>>> >
>>> > Since there isn't the api like "/sync" in sampleSyncAdapter
>>> > google-engine-server, which can help us to get update contacts when
>>> sending
>>> > the phone's dirty contacts and the last time of synchronization to
>>> server,
>>> > we cann't use the synchronization mechanism in SampleSyncAdapter. I
>>> think
>>> > maybe we can use the following method to synchronize contacts.
>>> >
>>> > * server to client (update local contacts from server when needed):
>>> > In the function, SynAdapter.onPerformSync(), the process is
>>> > "XWikiConnector.getAllUsers>> compare with the local contacts and find
>>> the
>>> > contacts which should be updated >> ContactManager.updateContacts".
>>> > Available apis:
>>> > GetAllUserList: curl
>>> > http://localhost:8080/xwiki/rest/wikis/query?q=object:XWiki.XWikiUsers
>>> > GetUserInfo: curl
>>> >
>>> http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/FitzLee/objects/XWiki.XWikiUsers/0
>>> >
>>> > * client to server (edit, add, delete contacts and meanwhile synchronize
>>> > from client to server):
>>> > When editing, adding or deleting contacts in android activities, we
>>> should
>>> > first request the xwiki server. Update contacts if allowed, or discard
>>> the
>>> > modification if not be authorized or have no permission.
>>> > Available apis:
>>> > EditUser: curl -u FitzLee:fitz2xwiki -X PUT -H "Content-type:
>>> > application/x-www-form-urlencoded" -H "Accept: application/xml" -d
>>> > "className=XWiki.XWikiUsers" -d "property#company=iie"
>>> >
>>> http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/FitzLee/objects/XWiki.XWikiUsers/0
>>> >
>>>
>>> Yes the goal for now is to have an application working on any existing
>>> wiki (lets say not older than 7.4.x since that's the current LTS but
>>> the lowest the better).
>>>
>>> You can if you have time implement new REST APIs (it's always usefull
>>> anyway) that would improve performances for example but the
>>> application should not assume that these new API would exist in the
>>> target instance that could be too old for it. So in the GSOC timeframe
>>> it would be safer to just do with what already exist which indeed
>>> might give more work to the application than a specific API designed
>>> specifically for synchronization but it should be doable.
>>>
>>> > I see two main possibility for this:
>>> >> * the first thing you should do I think is download the jetty/hsqld
>>> >> all in one distribution on
>>> >> http://www.xwiki.org/xwiki/bin/view/Main/Download and use that as test
>>> >> server (you have admin right in it and can create as many test users
>>> >> or groups as you want)
>>> >> * as soon as you want to test volume and compatibility with existing
>>> >> instance of XWiki you can register on http://www.xwiki.org which
>>> >> contains 1519 users right now
>>> >>
>>> >
>>> > I have downloaded the enterprise xwiki jetty server 8.0 and tried to
>>> create
>>> > some applications and understand the features of the server. Using the
>>> > administrator Admin:admin, I have create some users and groups. And I
>>> use
>>> > the python script curl to learn how to get user-list, group-list and how
>>> to
>>> > modify them with the restfull apis. In addition, I find a demo which is
>>> > useful for me to be familiar with the apis, like
>>> > xwiki-contrib/android-client(
>>> https://github.com/xwiki-contrib/android-client).
>>> > And I will write my own android restful interactive method, mainly used
>>> for
>>> > the authentication and the management of users and groups.
>>> >
>>> > But for testing the volume and compatibility of the synchronization in
>>> > SynAdapter.onPerformSync(), how do we compare the contact differences
>>> > between server and client and find the update contacts which need to be
>>> > updated?  It's a big problem if there are 1519 users and maybe I should
>>> > compare one by one to find which contact should be updated because
>>> > there'are no relevant apis to get the need-to-update contacts from
>>> server
>>> > after the last time of synchronization.
>>>
>>> You don't have a sync API but you have a search API in which you can
>>> request all the documents containing a user object and that were
>>> modified after some date for example. You can use either sql or solr.
>>>
>>> >
>>> >> (1) sign in
>>> >> > it is easy,just like my analysis of android SampleSyncAdapter,
>>> including
>>> >> the
>>> >> > server connection with XWikiconnector and the account added by
>>> >> > AccountManager
>>> >>
>>> >> Don't reduce too quickly the level of difficulty on this side, one
>>> >> thing you will have to work around is that standard XWiki instance
>>> >> have no token based authentication so you will have to hack an as safe
>>> >> as possible BASIC auth based implementation of Android authenticator
>>> >> (which mean users of the authenticator can't just ask for the token
>>> >> and connect to XWiki server).
>>> >
>>> >
>>> > Thank you for your reminder.  From the restfull apis, I have seen the
>>> two
>>> > methods of authentication,  including HTTP BASIC Auth and XWiki session
>>> > auth.  But Question is how users of the authenticator to connect to
>>> XWiki
>>> > server without username and password as I can't modify the
>>> authentication
>>> > method in the server and can only use the BASIC Auth?  use BASE64 to
>>> > encrypt the password? or ask for the session and communicate with
>>> server?
>>> > and BASE64 can just enhance the security in some extent. and maybe we
>>> can
>>> > use the https to ensure the authenticator security. I am so confused.
>>> Could
>>> > you give me some tips about authentication and security?
>>>
>>> I did not had time to experiment on this but here as some ideas of
>>> things to try:
>>>
>>> 1) return whatever identify the session (I had forgotten about session
>>> access, thanks for the reminder :)). Then the application put that
>>> session id in whatever http client tool it want to use. That's
>>> probably the safest and what look the most like a the classical token
>>> based access.
>>>
>>> 2) provide a preconfigured instance of Android HTTP Client in which:
>>> 2.a) a sessions have already been started with the server and the HTTP
>>> Client keep it alive (that's the safest I can think of right now)
>>> 2.b) the BASIC auth header cannot be read from outside (for example
>>> extends it in a custom class and forbid any public access to the
>>> Authorization header) that can be used to request the XWiki server
>>>
>>> 3) the worst case scenario is to return the BASIC auth header (it
>>> looks like "Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l"). It's
>>> encoded but it's easy to decode. The application would just set it in
>>> whatever http tool it's using. An application can use an authenticator
>>> only if the user allows it and the alternative is that each
>>> application deal with login/password on its side so it's still better
>>> than nothing :)
>>>
>>> Whatever solution is chosen the best would be to provide some small
>>> helper library that deal with XWiki authenticator and for example
>>> generate a pre-configured http client instance for the application
>>> with what the authenticator return. That way it's easier to change the
>>> way the authenticator works without breaking application (at least
>>> application that use the recommended library).
>>>
>>> >
>>> >
>>> >> > (3) synchronization of contacts
>>> >> > (4) edit the contact
>>> >> > (5) access by other apps
>>> >> > Question: Are there more other requirements in this app, like adding
>>> >> > friends(general person) and creating new xwiki
>>> account(administrator)?
>>> >> > maybe it will cause more demands and be more complex.
>>> >> >
>>> >>
>>> >> There is no real "friends" system in standard XWiki and anyway the
>>> >> main use case for this application being intranets you usually want to
>>> >> simply synchronize all users of the wiki since those are your
>>> >> coworkers. An improvement would be to allow the user to select a list
>>> >> of XWiki groups to synchronize if you don't want the whole wiki in a
>>> >> big company or public wiki like xwiki.org for example.
>>> >
>>> >
>>> > So there are two choices:
>>> > 1.  Synchronize all contacts who are my coworkers
>>> > 2.  Synchronize the contacts in the XWiki group which authenticator-user
>>> > wants to select.
>>>
>>> And possibly other idea you may have while knowing XWiki better :)
>>>
>>> But on my side 1 and 2 would already be great.
>>>
>>> >
>>> >> 4. support version and ui
>>> >> > (1) ui design
>>> >> > * material design >=4.4 with the support library support-v7
>>> >> > (2) support version
>>> >> > * The ui design can support the lowest 2.3 version and the android
>>> >> > sampleSynAdapter can also support 2.3 version. So I think our
>>> >> authenticator
>>> >> > app can support the lowest 2.3 version if needed.
>>> >> > Question: Maybe there are somethings I have not noticed, so this
>>> >> conclusion
>>> >> > is wrong, please give me some advice? Is that OK?
>>> >>
>>> >> Supporting the lowest possible version is always nicer for users but
>>> >> according to http://developer.android.com/about/dashboards/index.html
>>> >> no need to go beyond 4.1.
>>> >>
>>> >> 4.4 seems to still be a bit too recent and might left behind too many
>>> >> users.
>>> >>
>>> >>
>>> > Yes, so 4.1 may be the best choice. For the design of UI, the support
>>> > library support-v7 can solve the problem. And I will use the perfect
>>> > material design style if the android sdk version >= 4.4.
>>> >
>>> >>
>>> >> > 5. account permission
>>> >> > In AccountGeneral.java there are two permissions , like
>>> >> > AUTHTOKEN_TYPE_READ_ONLY, AUTHTOKEN_TYPE_FULL_ACCESS.  Could you tell
>>> me
>>> >> > what the permissions main?  other xwiki instance access  limits ?
>>> >> Account
>>> >> > manager? And where should I use them?
>>> >>
>>> >> You have many right on XWiki (and any extension can add more) plus it
>>> >> depend what part of the wiki you are accessing.
>>> >>
>>> >> But since you don't have any concept of token associated to an
>>> >> application in standard XWiki the application will have whatever right
>>> >> the user have so I guess you can return AUTHTOKEN_TYPE_FULL_ACCESS all
>>> >> the time in the Android authenticator (then the application will have
>>> >> to deal with 403 errors).
>>> >
>>> >
>>> > OK, I will return AUTHTOKEN_TYPE_FULL_ACCESS and deal with the
>>> unauthorized
>>> > or other response error.
>>> >
>>> >
>>> >>
>>> >> --
>>> >> Thomas Mortagne
>>> >> _______________________________________________
>>> >> devs mailing list
>>> >> [hidden email] <http:///user/SendEmail.jtp?type=node&node=7598982&i=2>
>>> >> http://lists.xwiki.org/mailman/listinfo/devs
>>> >>
>>> >
>>> >  At last, should I use the xwiki JIRA to create a custom issue and give
>>> you
>>> > a pull requst when I have some new idea or make progress?
>>>
>>> Anyone who is a member of the XWiki Contrib organization (basically
>>> anyone who ask to be) have write access on
>>> https://github.com/xwiki-contrib/android-authenticator so no need for
>>> pull request. It's not like it was in a very stable state right now
>>> anyway :)
>>>
>>> >
>>> > Best Regards,
>>> > Fitz Lee | UCAS Master
>>> > _______________________________________________
>>> > devs mailing list
>>> > [hidden email] <http:///user/SendEmail.jtp?type=node&node=7598982&i=3>
>>> > http://lists.xwiki.org/mailman/listinfo/devs
>>>
>>>
>>>
>>> --
>>> Thomas Mortagne
>>> _______________________________________________
>>> devs mailing list
>>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=7598982&i=4>
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>
>>>
>>> ------------------------------
>>> If you reply to this email, your message will be added to the discussion
>>> below:
>>>
>>> http://xwiki.475771.n2.nabble.com/Questions-Gsoc2016-XWiki-Android-authenticator-tp7598932p7598982.html
>>> To unsubscribe from Questions, Gsoc2016, XWiki Android-authenticator, click
>>> here
>>> <
>>> .
>>> NAML
>>> <http://xwiki.475771.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>>
>>
>>
>>
>>
>> --
>> View this message in context: http://xwiki.475771.n2.nabble.com/Questions-Gsoc2016-XWiki-Android-authenticator-tp7598932p7599003.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

[Thomas Mortagne]

Actually after thinking more about it session id does not seems such a
good idea in practice: sessions are quite short lived scope and users
might end up authenticating again and again. Also when synchronizer
wake up there is a good chance the session is dead and we are not
going to constantly ask credential to the user out of the blue for
what is supposed to be an invisible background task.

On Tue, Apr 19, 2016 at 12:57 PM, Thomas Mortagne
<[hidden email]> wrote:

> On Tue, Apr 19, 2016 at 12:56 PM, Thomas Mortagne
> <[hidden email]> wrote:
>> On Fri, Apr 15, 2016 at 6:25 AM, fitz <[hidden email]> wrote:
>>> Hello Thomas,
>>>
>>> Thank you very much and I really appreciate your help and guidance. And
>>> thank you for helping me improve.
>>>
>>> I will firstly use the existing REST APIs to develop this project, And
>>> maybe in the future I can make some specific APIs to improve performance if
>>> time permits.
>>>
>>> Yes, the search APIs can help me get need-update contacts after the
>>> last-sync-time and solve the one by one comparing problem. And I will be
>>> familiar with the use of search APIs as soon as possible so that I can use
>>> it in the synchronization code.  Thank you for solving my confusion.
>>>
>>> And for authentication and security, considering your precious advice, I
>>> will try to use the first idea, and just return the session so that other
>>> xwiki android apps can use the httpclient with this session id to
>>> authenticate with the server.  And I will firstly implement this method and
>>> test the effectiveness of this scheme as soon as possible.
>>
>> All that sounds good.
>>
>>>
>>> For the xwiki-contrib, I will ask to join the group, develop this android
>>> project and maybe make a contribution.
>>
>> Looks like you are already member of XWiki Contrib actually.
>
> Just saw the other mail (I'm a bit late with my mails...).
>
>>
>>>
>>> Yours sincerely
>>> Fitz Lee
>>>
>>>
>>> 2016-04-14 17:33 GMT+08:00 Thomas Mortagne [via XWiki] <
>>> [hidden email]>:
>>>
>>>> On Thu, Apr 14, 2016 at 7:22 AM, Fitz Lee <[hidden email]
>>>> <http:///user/SendEmail.jtp?type=node&node=7598982&i=0>> wrote:
>>>>
>>>> > Hi Thomas,
>>>> >
>>>> >
>>>> > Thank you so much for your reply and recognition.
>>>> >
>>>> >
>>>> > 2016-04-12 17:18 GMT+08:00 Thomas Mortagne <[hidden email]
>>>> <http:///user/SendEmail.jtp?type=node&node=7598982&i=1>>:
>>>> >
>>>> >> Hi Fitz,
>>>> >>
>>>> >> Great to see so much motivation from you :)
>>>> >>
>>>> >> Just don't forget that GSOC coding period is not started yet and that
>>>> >> we still have no idea how many slots Google will give us and who we
>>>> >> will select this year (this will be 22nd April).
>>>> >>
>>>> >>
>>>> > Yeah, I know the coding period of GSoC, and now I'm just striving and
>>>> > looking forward to get this project. If I really do not pass the GSoC
>>>> > application, it doesn't matter and I have learned a lot. As I have said,
>>>> I
>>>> > will be very happy if there is anything I can help.
>>>> >
>>>> >
>>>> >> Yes contact synchronization in
>>>> >> https://github.com/xwiki-contrib/android-authenticator is not the
>>>> >> beginning or an experiment I never had time to finish so it's more
>>>> >> pseudo code that never worked yet.
>>>> >
>>>> >
>>>> > Considering the XWikiRESTfulAPIs in
>>>> > http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI, the
>>>> apis
>>>> > have been well designed so that maybe I can't modify those apis. I
>>>> should
>>>> > just make use of the existing api resources to design the
>>>> synchronization
>>>> > of contacts and the process of sign-in and sign-up.
>>>> >
>>>> > Since there isn't the api like "/sync" in sampleSyncAdapter
>>>> > google-engine-server, which can help us to get update contacts when
>>>> sending
>>>> > the phone's dirty contacts and the last time of synchronization to
>>>> server,
>>>> > we cann't use the synchronization mechanism in SampleSyncAdapter. I
>>>> think
>>>> > maybe we can use the following method to synchronize contacts.
>>>> >
>>>> > * server to client (update local contacts from server when needed):
>>>> > In the function, SynAdapter.onPerformSync(), the process is
>>>> > "XWikiConnector.getAllUsers>> compare with the local contacts and find
>>>> the
>>>> > contacts which should be updated >> ContactManager.updateContacts".
>>>> > Available apis:
>>>> > GetAllUserList: curl
>>>> > http://localhost:8080/xwiki/rest/wikis/query?q=object:XWiki.XWikiUsers
>>>> > GetUserInfo: curl
>>>> >
>>>> http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/FitzLee/objects/XWiki.XWikiUsers/0
>>>> >
>>>> > * client to server (edit, add, delete contacts and meanwhile synchronize
>>>> > from client to server):
>>>> > When editing, adding or deleting contacts in android activities, we
>>>> should
>>>> > first request the xwiki server. Update contacts if allowed, or discard
>>>> the
>>>> > modification if not be authorized or have no permission.
>>>> > Available apis:
>>>> > EditUser: curl -u FitzLee:fitz2xwiki -X PUT -H "Content-type:
>>>> > application/x-www-form-urlencoded" -H "Accept: application/xml" -d
>>>> > "className=XWiki.XWikiUsers" -d "property#company=iie"
>>>> >
>>>> http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/FitzLee/objects/XWiki.XWikiUsers/0
>>>> >
>>>>
>>>> Yes the goal for now is to have an application working on any existing
>>>> wiki (lets say not older than 7.4.x since that's the current LTS but
>>>> the lowest the better).
>>>>
>>>> You can if you have time implement new REST APIs (it's always usefull
>>>> anyway) that would improve performances for example but the
>>>> application should not assume that these new API would exist in the
>>>> target instance that could be too old for it. So in the GSOC timeframe
>>>> it would be safer to just do with what already exist which indeed
>>>> might give more work to the application than a specific API designed
>>>> specifically for synchronization but it should be doable.
>>>>
>>>> > I see two main possibility for this:
>>>> >> * the first thing you should do I think is download the jetty/hsqld
>>>> >> all in one distribution on
>>>> >> http://www.xwiki.org/xwiki/bin/view/Main/Download and use that as test
>>>> >> server (you have admin right in it and can create as many test users
>>>> >> or groups as you want)
>>>> >> * as soon as you want to test volume and compatibility with existing
>>>> >> instance of XWiki you can register on http://www.xwiki.org which
>>>> >> contains 1519 users right now
>>>> >>
>>>> >
>>>> > I have downloaded the enterprise xwiki jetty server 8.0 and tried to
>>>> create
>>>> > some applications and understand the features of the server. Using the
>>>> > administrator Admin:admin, I have create some users and groups. And I
>>>> use
>>>> > the python script curl to learn how to get user-list, group-list and how
>>>> to
>>>> > modify them with the restfull apis. In addition, I find a demo which is
>>>> > useful for me to be familiar with the apis, like
>>>> > xwiki-contrib/android-client(
>>>> https://github.com/xwiki-contrib/android-client).
>>>> > And I will write my own android restful interactive method, mainly used
>>>> for
>>>> > the authentication and the management of users and groups.
>>>> >
>>>> > But for testing the volume and compatibility of the synchronization in
>>>> > SynAdapter.onPerformSync(), how do we compare the contact differences
>>>> > between server and client and find the update contacts which need to be
>>>> > updated?  It's a big problem if there are 1519 users and maybe I should
>>>> > compare one by one to find which contact should be updated because
>>>> > there'are no relevant apis to get the need-to-update contacts from
>>>> server
>>>> > after the last time of synchronization.
>>>>
>>>> You don't have a sync API but you have a search API in which you can
>>>> request all the documents containing a user object and that were
>>>> modified after some date for example. You can use either sql or solr.
>>>>
>>>> >
>>>> >> (1) sign in
>>>> >> > it is easy,just like my analysis of android SampleSyncAdapter,
>>>> including
>>>> >> the
>>>> >> > server connection with XWikiconnector and the account added by
>>>> >> > AccountManager
>>>> >>
>>>> >> Don't reduce too quickly the level of difficulty on this side, one
>>>> >> thing you will have to work around is that standard XWiki instance
>>>> >> have no token based authentication so you will have to hack an as safe
>>>> >> as possible BASIC auth based implementation of Android authenticator
>>>> >> (which mean users of the authenticator can't just ask for the token
>>>> >> and connect to XWiki server).
>>>> >
>>>> >
>>>> > Thank you for your reminder.  From the restfull apis, I have seen the
>>>> two
>>>> > methods of authentication,  including HTTP BASIC Auth and XWiki session
>>>> > auth.  But Question is how users of the authenticator to connect to
>>>> XWiki
>>>> > server without username and password as I can't modify the
>>>> authentication
>>>> > method in the server and can only use the BASIC Auth?  use BASE64 to
>>>> > encrypt the password? or ask for the session and communicate with
>>>> server?
>>>> > and BASE64 can just enhance the security in some extent. and maybe we
>>>> can
>>>> > use the https to ensure the authenticator security. I am so confused.
>>>> Could
>>>> > you give me some tips about authentication and security?
>>>>
>>>> I did not had time to experiment on this but here as some ideas of
>>>> things to try:
>>>>
>>>> 1) return whatever identify the session (I had forgotten about session
>>>> access, thanks for the reminder :)). Then the application put that
>>>> session id in whatever http client tool it want to use. That's
>>>> probably the safest and what look the most like a the classical token
>>>> based access.
>>>>
>>>> 2) provide a preconfigured instance of Android HTTP Client in which:
>>>> 2.a) a sessions have already been started with the server and the HTTP
>>>> Client keep it alive (that's the safest I can think of right now)
>>>> 2.b) the BASIC auth header cannot be read from outside (for example
>>>> extends it in a custom class and forbid any public access to the
>>>> Authorization header) that can be used to request the XWiki server
>>>>
>>>> 3) the worst case scenario is to return the BASIC auth header (it
>>>> looks like "Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l"). It's
>>>> encoded but it's easy to decode. The application would just set it in
>>>> whatever http tool it's using. An application can use an authenticator
>>>> only if the user allows it and the alternative is that each
>>>> application deal with login/password on its side so it's still better
>>>> than nothing :)
>>>>
>>>> Whatever solution is chosen the best would be to provide some small
>>>> helper library that deal with XWiki authenticator and for example
>>>> generate a pre-configured http client instance for the application
>>>> with what the authenticator return. That way it's easier to change the
>>>> way the authenticator works without breaking application (at least
>>>> application that use the recommended library).
>>>>
>>>> >
>>>> >
>>>> >> > (3) synchronization of contacts
>>>> >> > (4) edit the contact
>>>> >> > (5) access by other apps
>>>> >> > Question: Are there more other requirements in this app, like adding
>>>> >> > friends(general person) and creating new xwiki
>>>> account(administrator)?
>>>> >> > maybe it will cause more demands and be more complex.
>>>> >> >
>>>> >>
>>>> >> There is no real "friends" system in standard XWiki and anyway the
>>>> >> main use case for this application being intranets you usually want to
>>>> >> simply synchronize all users of the wiki since those are your
>>>> >> coworkers. An improvement would be to allow the user to select a list
>>>> >> of XWiki groups to synchronize if you don't want the whole wiki in a
>>>> >> big company or public wiki like xwiki.org for example.
>>>> >
>>>> >
>>>> > So there are two choices:
>>>> > 1.  Synchronize all contacts who are my coworkers
>>>> > 2.  Synchronize the contacts in the XWiki group which authenticator-user
>>>> > wants to select.
>>>>
>>>> And possibly other idea you may have while knowing XWiki better :)
>>>>
>>>> But on my side 1 and 2 would already be great.
>>>>
>>>> >
>>>> >> 4. support version and ui
>>>> >> > (1) ui design
>>>> >> > * material design >=4.4 with the support library support-v7
>>>> >> > (2) support version
>>>> >> > * The ui design can support the lowest 2.3 version and the android
>>>> >> > sampleSynAdapter can also support 2.3 version. So I think our
>>>> >> authenticator
>>>> >> > app can support the lowest 2.3 version if needed.
>>>> >> > Question: Maybe there are somethings I have not noticed, so this
>>>> >> conclusion
>>>> >> > is wrong, please give me some advice? Is that OK?
>>>> >>
>>>> >> Supporting the lowest possible version is always nicer for users but
>>>> >> according to http://developer.android.com/about/dashboards/index.html
>>>> >> no need to go beyond 4.1.
>>>> >>
>>>> >> 4.4 seems to still be a bit too recent and might left behind too many
>>>> >> users.
>>>> >>
>>>> >>
>>>> > Yes, so 4.1 may be the best choice. For the design of UI, the support
>>>> > library support-v7 can solve the problem. And I will use the perfect
>>>> > material design style if the android sdk version >= 4.4.
>>>> >
>>>> >>
>>>> >> > 5. account permission
>>>> >> > In AccountGeneral.java there are two permissions , like
>>>> >> > AUTHTOKEN_TYPE_READ_ONLY, AUTHTOKEN_TYPE_FULL_ACCESS.  Could you tell
>>>> me
>>>> >> > what the permissions main?  other xwiki instance access  limits ?
>>>> >> Account
>>>> >> > manager? And where should I use them?
>>>> >>
>>>> >> You have many right on XWiki (and any extension can add more) plus it
>>>> >> depend what part of the wiki you are accessing.
>>>> >>
>>>> >> But since you don't have any concept of token associated to an
>>>> >> application in standard XWiki the application will have whatever right
>>>> >> the user have so I guess you can return AUTHTOKEN_TYPE_FULL_ACCESS all
>>>> >> the time in the Android authenticator (then the application will have
>>>> >> to deal with 403 errors).
>>>> >
>>>> >
>>>> > OK, I will return AUTHTOKEN_TYPE_FULL_ACCESS and deal with the
>>>> unauthorized
>>>> > or other response error.
>>>> >
>>>> >
>>>> >>
>>>> >> --
>>>> >> Thomas Mortagne
>>>> >> _______________________________________________
>>>> >> devs mailing list
>>>> >> [hidden email] <http:///user/SendEmail.jtp?type=node&node=7598982&i=2>
>>>> >> http://lists.xwiki.org/mailman/listinfo/devs
>>>> >>
>>>> >
>>>> >  At last, should I use the xwiki JIRA to create a custom issue and give
>>>> you
>>>> > a pull requst when I have some new idea or make progress?
>>>>
>>>> Anyone who is a member of the XWiki Contrib organization (basically
>>>> anyone who ask to be) have write access on
>>>> https://github.com/xwiki-contrib/android-authenticator so no need for
>>>> pull request. It's not like it was in a very stable state right now
>>>> anyway :)
>>>>
>>>> >
>>>> > Best Regards,
>>>> > Fitz Lee | UCAS Master
>>>> > _______________________________________________
>>>> > devs mailing list
>>>> > [hidden email] <http:///user/SendEmail.jtp?type=node&node=7598982&i=3>
>>>> > http://lists.xwiki.org/mailman/listinfo/devs
>>>>
>>>>
>>>>
>>>> --
>>>> Thomas Mortagne
>>>> _______________________________________________
>>>> devs mailing list
>>>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=7598982&i=4>
>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>
>>>>
>>>> ------------------------------
>>>> If you reply to this email, your message will be added to the discussion
>>>> below:
>>>>
>>>> http://xwiki.475771.n2.nabble.com/Questions-Gsoc2016-XWiki-Android-authenticator-tp7598932p7598982.html
>>>> To unsubscribe from Questions, Gsoc2016, XWiki Android-authenticator, click
>>>> here
>>>> <
>>>> .
>>>> NAML
>>>> <http://xwiki.475771.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context: http://xwiki.475771.n2.nabble.com/Questions-Gsoc2016-XWiki-Android-authenticator-tp7598932p7599003.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

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

[fitz]

Hi Thomas, 

2016-04-20 23:11 GMT+08:00 Thomas Mortagne [via XWiki] <[hidden email]>:

Actually after thinking more about it session id does not seems such a
good idea in practice: sessions are quite short lived scope and users
might end up authenticating again and again. Also when synchronizer
wake up there is a good chance the session is dead and we are not
going to constantly ask credential to the user out of the blue for
what is supposed to be an invisible background task.

Yeah, As we have discussed, there are three ways for the user app to authenticate and communicate with XWiki-server: 

1.session id

It may be the best and simple choice because user app just gets sessionid from the authenticator and doesn't need to know username and passwd.   

However as you have said, sessions are quite short lived scope and maybe it is dead while the user app is using. That's really a big problem. Maybe there are some methods to avoid this failure. For example, the authenticator can send the sessionid with expiration time. When it's expired, ask for the sessionid again. Or, the authenticator also can send broadcast to all user apps when the session is expired. User apps ask to get a new sessionid while receiving the broadcast.

2. Basic Auth

if the user app use the BASIC auth header(Base64) to authenticate with XWiki-server, there's no security at all because Base64 is easy to decode and all user apps can decrypt and get username and passwd easily. So I think only in this case that we trust all the user apps, for example these apps are signed and released by us, the authenticator can return Base64 to user apps.

3. A preconfigured httpclient/httpurlconnection

To be honest, I don't know how to achieve this method and how to provide a preconfigured httpclient instance.  That means returning the serialized httpclient by the authenticator service?  And maybe services with "aidl" can just return all primitive types(http://developer.android.com/guide/components/aidl.html#Create), like int, char and list<int>, so we cann't provide a preconfigured httpclient object to the other apps. Or maybe we can provide all the restful apis as a library in our authenticator, in this way, httpclient is invisible to user apps. But it may cause a lot of work. Really confused! :)

On Tue, Apr 19, 2016 at 12:57 PM, Thomas Mortagne
<[hidden email]> wrote:

> On Tue, Apr 19, 2016 at 12:56 PM, Thomas Mortagne
> <[hidden email]> wrote:
>> On Fri, Apr 15, 2016 at 6:25 AM, fitz <[hidden email]> wrote:

>>> Hello Thomas,
>>>
>>> Thank you very much and I really appreciate your help and guidance. And
>>> thank you for helping me improve.
>>>
>>> I will firstly use the existing REST APIs to develop this project, And
>>> maybe in the future I can make some specific APIs to improve performance if
>>> time permits.
>>>
>>> Yes, the search APIs can help me get need-update contacts after the
>>> last-sync-time and solve the one by one comparing problem. And I will be
>>> familiar with the use of search APIs as soon as possible so that I can use
>>> it in the synchronization code.  Thank you for solving my confusion.
>>>
>>> And for authentication and security, considering your precious advice, I
>>> will try to use the first idea, and just return the session so that other
>>> xwiki android apps can use the httpclient with this session id to
>>> authenticate with the server.  And I will firstly implement this method and
>>> test the effectiveness of this scheme as soon as possible.
>>
>> All that sounds good.
>>
>>>
>>> For the xwiki-contrib, I will ask to join the group, develop this android
>>> project and maybe make a contribution.
>>
>> Looks like you are already member of XWiki Contrib actually.
>
> Just saw the other mail (I'm a bit late with my mails...).

Never mind, Thank you anyway all the same. :)

Recently I have learned and understood solr query, restful apis and xmlpullparser. Now the android-authenticator can basically communicate with the XWiki-server to get all the contacts.  I have commit my code to the feature-rest branch of the android-authenticator repository.  As soon as possible I will implement the ideas above and test the effectiveness. There may be some other difficult issues in the future.

Best Regards,

Fitz Lee

>
>>
>>>
>>> Yours sincerely
>>> Fitz Lee
>>>
>>>
>>> 2016-04-14 17:33 GMT+08:00 Thomas Mortagne [via XWiki] <
>>> [hidden email]>:

>>>

>>>> On Thu, Apr 14, 2016 at 7:22 AM, Fitz Lee <[hidden email]
>>>> <http:///user/SendEmail.jtp?type=node&node=7598982&i=0>> wrote:
>>>>
>>>> > Hi Thomas,
>>>> >
>>>> >
>>>> > Thank you so much for your reply and recognition.
>>>> >
>>>> >
>>>> > 2016-04-12 17:18 GMT+08:00 Thomas Mortagne <[hidden email]
>>>> <http:///user/SendEmail.jtp?type=node&node=7598982&i=1>>:
>>>> >
>>>> >> Hi Fitz,
>>>> >>
>>>> >> Great to see so much motivation from you :)
>>>> >>
>>>> >> Just don't forget that GSOC coding period is not started yet and that
>>>> >> we still have no idea how many slots Google will give us and who we
>>>> >> will select this year (this will be 22nd April).
>>>> >>
>>>> >>
>>>> > Yeah, I know the coding period of GSoC, and now I'm just striving and
>>>> > looking forward to get this project. If I really do not pass the GSoC
>>>> > application, it doesn't matter and I have learned a lot. As I have said,
>>>> I
>>>> > will be very happy if there is anything I can help.
>>>> >
>>>> >
>>>> >> Yes contact synchronization in
>>>> >> https://github.com/xwiki-contrib/android-authenticator is not the
>>>> >> beginning or an experiment I never had time to finish so it's more
>>>> >> pseudo code that never worked yet.
>>>> >
>>>> >
>>>> > Considering the XWikiRESTfulAPIs in
>>>> > http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI, the
>>>> apis
>>>> > have been well designed so that maybe I can't modify those apis. I
>>>> should
>>>> > just make use of the existing api resources to design the
>>>> synchronization
>>>> > of contacts and the process of sign-in and sign-up.
>>>> >
>>>> > Since there isn't the api like "/sync" in sampleSyncAdapter
>>>> > google-engine-server, which can help us to get update contacts when
>>>> sending
>>>> > the phone's dirty contacts and the last time of synchronization to
>>>> server,
>>>> > we cann't use the synchronization mechanism in SampleSyncAdapter. I
>>>> think
>>>> > maybe we can use the following method to synchronize contacts.
>>>> >
>>>> > * server to client (update local contacts from server when needed):
>>>> > In the function, SynAdapter.onPerformSync(), the process is
>>>> > "XWikiConnector.getAllUsers>> compare with the local contacts and find
>>>> the
>>>> > contacts which should be updated >> ContactManager.updateContacts".
>>>> > Available apis:
>>>> > GetAllUserList: curl
>>>> > http://localhost:8080/xwiki/rest/wikis/query?q=object:XWiki.XWikiUsers
>>>> > GetUserInfo: curl
>>>> >
>>>> http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/FitzLee/objects/XWiki.XWikiUsers/0
>>>> >
>>>> > * client to server (edit, add, delete contacts and meanwhile synchronize
>>>> > from client to server):
>>>> > When editing, adding or deleting contacts in android activities, we
>>>> should
>>>> > first request the xwiki server. Update contacts if allowed, or discard
>>>> the
>>>> > modification if not be authorized or have no permission.
>>>> > Available apis:
>>>> > EditUser: curl -u FitzLee:fitz2xwiki -X PUT -H "Content-type:
>>>> > application/x-www-form-urlencoded" -H "Accept: application/xml" -d
>>>> > "className=XWiki.XWikiUsers" -d "property#company=iie"
>>>> >
>>>> http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/FitzLee/objects/XWiki.XWikiUsers/0
>>>> >
>>>>
>>>> Yes the goal for now is to have an application working on any existing
>>>> wiki (lets say not older than 7.4.x since that's the current LTS but
>>>> the lowest the better).
>>>>
>>>> You can if you have time implement new REST APIs (it's always usefull
>>>> anyway) that would improve performances for example but the
>>>> application should not assume that these new API would exist in the
>>>> target instance that could be too old for it. So in the GSOC timeframe
>>>> it would be safer to just do with what already exist which indeed
>>>> might give more work to the application than a specific API designed
>>>> specifically for synchronization but it should be doable.
>>>>
>>>> > I see two main possibility for this:
>>>> >> * the first thing you should do I think is download the jetty/hsqld
>>>> >> all in one distribution on
>>>> >> http://www.xwiki.org/xwiki/bin/view/Main/Download and use that as test
>>>> >> server (you have admin right in it and can create as many test users
>>>> >> or groups as you want)
>>>> >> * as soon as you want to test volume and compatibility with existing
>>>> >> instance of XWiki you can register on http://www.xwiki.org which
>>>> >> contains 1519 users right now
>>>> >>
>>>> >
>>>> > I have downloaded the enterprise xwiki jetty server 8.0 and tried to
>>>> create
>>>> > some applications and understand the features of the server. Using the
>>>> > administrator Admin:admin, I have create some users and groups. And I
>>>> use
>>>> > the python script curl to learn how to get user-list, group-list and how
>>>> to
>>>> > modify them with the restfull apis. In addition, I find a demo which is
>>>> > useful for me to be familiar with the apis, like
>>>> > xwiki-contrib/android-client(
>>>> https://github.com/xwiki-contrib/android-client).
>>>> > And I will write my own android restful interactive method, mainly used
>>>> for
>>>> > the authentication and the management of users and groups.
>>>> >
>>>> > But for testing the volume and compatibility of the synchronization in
>>>> > SynAdapter.onPerformSync(), how do we compare the contact differences
>>>> > between server and client and find the update contacts which need to be
>>>> > updated?  It's a big problem if there are 1519 users and maybe I should
>>>> > compare one by one to find which contact should be updated because
>>>> > there'are no relevant apis to get the need-to-update contacts from
>>>> server
>>>> > after the last time of synchronization.
>>>>
>>>> You don't have a sync API but you have a search API in which you can
>>>> request all the documents containing a user object and that were
>>>> modified after some date for example. You can use either sql or solr.
>>>>
>>>> >
>>>> >> (1) sign in
>>>> >> > it is easy,just like my analysis of android SampleSyncAdapter,
>>>> including
>>>> >> the
>>>> >> > server connection with XWikiconnector and the account added by
>>>> >> > AccountManager
>>>> >>
>>>> >> Don't reduce too quickly the level of difficulty on this side, one
>>>> >> thing you will have to work around is that standard XWiki instance
>>>> >> have no token based authentication so you will have to hack an as safe
>>>> >> as possible BASIC auth based implementation of Android authenticator
>>>> >> (which mean users of the authenticator can't just ask for the token
>>>> >> and connect to XWiki server).
>>>> >
>>>> >
>>>> > Thank you for your reminder.  From the restfull apis, I have seen the
>>>> two
>>>> > methods of authentication,  including HTTP BASIC Auth and XWiki session
>>>> > auth.  But Question is how users of the authenticator to connect to
>>>> XWiki
>>>> > server without username and password as I can't modify the
>>>> authentication
>>>> > method in the server and can only use the BASIC Auth?  use BASE64 to
>>>> > encrypt the password? or ask for the session and communicate with
>>>> server?
>>>> > and BASE64 can just enhance the security in some extent. and maybe we
>>>> can
>>>> > use the https to ensure the authenticator security. I am so confused.
>>>> Could
>>>> > you give me some tips about authentication and security?
>>>>
>>>> I did not had time to experiment on this but here as some ideas of
>>>> things to try:
>>>>
>>>> 1) return whatever identify the session (I had forgotten about session
>>>> access, thanks for the reminder :)). Then the application put that
>>>> session id in whatever http client tool it want to use. That's
>>>> probably the safest and what look the most like a the classical token
>>>> based access.
>>>>
>>>> 2) provide a preconfigured instance of Android HTTP Client in which:
>>>> 2.a) a sessions have already been started with the server and the HTTP
>>>> Client keep it alive (that's the safest I can think of right now)
>>>> 2.b) the BASIC auth header cannot be read from outside (for example
>>>> extends it in a custom class and forbid any public access to the
>>>> Authorization header) that can be used to request the XWiki server
>>>>
>>>> 3) the worst case scenario is to return the BASIC auth header (it
>>>> looks like "Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l"). It's
>>>> encoded but it's easy to decode. The application would just set it in
>>>> whatever http tool it's using. An application can use an authenticator
>>>> only if the user allows it and the alternative is that each
>>>> application deal with login/password on its side so it's still better
>>>> than nothing :)
>>>>
>>>> Whatever solution is chosen the best would be to provide some small
>>>> helper library that deal with XWiki authenticator and for example
>>>> generate a pre-configured http client instance for the application
>>>> with what the authenticator return. That way it's easier to change the
>>>> way the authenticator works without breaking application (at least
>>>> application that use the recommended library).
>>>>
>>>> >
>>>> >
>>>> >> > (3) synchronization of contacts
>>>> >> > (4) edit the contact
>>>> >> > (5) access by other apps
>>>> >> > Question: Are there more other requirements in this app, like adding
>>>> >> > friends(general person) and creating new xwiki
>>>> account(administrator)?
>>>> >> > maybe it will cause more demands and be more complex.
>>>> >> >
>>>> >>
>>>> >> There is no real "friends" system in standard XWiki and anyway the
>>>> >> main use case for this application being intranets you usually want to
>>>> >> simply synchronize all users of the wiki since those are your
>>>> >> coworkers. An improvement would be to allow the user to select a list
>>>> >> of XWiki groups to synchronize if you don't want the whole wiki in a
>>>> >> big company or public wiki like xwiki.org for example.
>>>> >
>>>> >
>>>> > So there are two choices:
>>>> > 1.  Synchronize all contacts who are my coworkers
>>>> > 2.  Synchronize the contacts in the XWiki group which authenticator-user
>>>> > wants to select.
>>>>
>>>> And possibly other idea you may have while knowing XWiki better :)
>>>>
>>>> But on my side 1 and 2 would already be great.
>>>>
>>>> >
>>>> >> 4. support version and ui
>>>> >> > (1) ui design
>>>> >> > * material design >=4.4 with the support library support-v7
>>>> >> > (2) support version
>>>> >> > * The ui design can support the lowest 2.3 version and the android
>>>> >> > sampleSynAdapter can also support 2.3 version. So I think our
>>>> >> authenticator
>>>> >> > app can support the lowest 2.3 version if needed.
>>>> >> > Question: Maybe there are somethings I have not noticed, so this
>>>> >> conclusion
>>>> >> > is wrong, please give me some advice? Is that OK?
>>>> >>
>>>> >> Supporting the lowest possible version is always nicer for users but
>>>> >> according to http://developer.android.com/about/dashboards/index.html
>>>> >> no need to go beyond 4.1.
>>>> >>
>>>> >> 4.4 seems to still be a bit too recent and might left behind too many
>>>> >> users.
>>>> >>
>>>> >>
>>>> > Yes, so 4.1 may be the best choice. For the design of UI, the support
>>>> > library support-v7 can solve the problem. And I will use the perfect
>>>> > material design style if the android sdk version >= 4.4.
>>>> >
>>>> >>
>>>> >> > 5. account permission
>>>> >> > In AccountGeneral.java there are two permissions , like
>>>> >> > AUTHTOKEN_TYPE_READ_ONLY, AUTHTOKEN_TYPE_FULL_ACCESS.  Could you tell
>>>> me
>>>> >> > what the permissions main?  other xwiki instance access  limits ?
>>>> >> Account
>>>> >> > manager? And where should I use them?
>>>> >>
>>>> >> You have many right on XWiki (and any extension can add more) plus it
>>>> >> depend what part of the wiki you are accessing.
>>>> >>
>>>> >> But since you don't have any concept of token associated to an
>>>> >> application in standard XWiki the application will have whatever right
>>>> >> the user have so I guess you can return AUTHTOKEN_TYPE_FULL_ACCESS all
>>>> >> the time in the Android authenticator (then the application will have
>>>> >> to deal with 403 errors).
>>>> >
>>>> >
>>>> > OK, I will return AUTHTOKEN_TYPE_FULL_ACCESS and deal with the
>>>> unauthorized
>>>> > or other response error.
>>>> >
>>>> >
>>>> >>
>>>> >> --
>>>> >> Thomas Mortagne
>>>> >> _______________________________________________
>>>> >> devs mailing list
>>>> >> [hidden email] <http:///user/SendEmail.jtp?type=node&node=7598982&i=2>
>>>> >> http://lists.xwiki.org/mailman/listinfo/devs
>>>> >>
>>>> >
>>>> >  At last, should I use the xwiki JIRA to create a custom issue and give
>>>> you
>>>> > a pull requst when I have some new idea or make progress?
>>>>
>>>> Anyone who is a member of the XWiki Contrib organization (basically
>>>> anyone who ask to be) have write access on
>>>> https://github.com/xwiki-contrib/android-authenticator so no need for
>>>> pull request. It's not like it was in a very stable state right now
>>>> anyway :)
>>>>
>>>> >
>>>> > Best Regards,
>>>> > Fitz Lee | UCAS Master
>>>> > _______________________________________________
>>>> > devs mailing list
>>>> > [hidden email] <http:///user/SendEmail.jtp?type=node&node=7598982&i=3>
>>>> > http://lists.xwiki.org/mailman/listinfo/devs
>>>>
>>>>
>>>>
>>>> --
>>>> Thomas Mortagne
>>>> _______________________________________________
>>>> devs mailing list
>>>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=7598982&i=4>
>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>
>>>>
>>>> ------------------------------
>>>> If you reply to this email, your message will be added to the discussion
>>>> below:
>>>>
>>>> http://xwiki.475771.n2.nabble.com/Questions-Gsoc2016-XWiki-Android-authenticator-tp7598932p7598982.html
>>>> To unsubscribe from Questions, Gsoc2016, XWiki Android-authenticator, click
>>>> here
>>>> <

>>>> .

>>>> NAML
>>>> <http://xwiki.475771.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context: http://xwiki.475771.n2.nabble.com/Questions-Gsoc2016-XWiki-Android-authenticator-tp7598932p7599003.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

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

---

If you reply to this email, your message will be added to the discussion below:

http://xwiki.475771.n2.nabble.com/Questions-Gsoc2016-XWiki-Android-authenticator-tp7598932p7599102.html

To unsubscribe from Questions, Gsoc2016, XWiki Android-authenticator, click here.
NAML

[Thomas Mortagne]

On Thu, Apr 21, 2016 at 9:50 AM, fitz <[hidden email]> wrote:

> Hi Thomas,
>
> 2016-04-20 23:11 GMT+08:00 Thomas Mortagne [via XWiki] <
> [hidden email]>:
>
>> Actually after thinking more about it session id does not seems such a
>> good idea in practice: sessions are quite short lived scope and users
>> might end up authenticating again and again. Also when synchronizer
>> wake up there is a good chance the session is dead and we are not
>> going to constantly ask credential to the user out of the blue for
>> what is supposed to be an invisible background task.
>>
>ed
> Yeah, As we have discussed, there are three ways for the user app to
> authenticate and communicate with XWiki-server:
> 1.session id
> It may be the best and simple choice because user app just gets sessionid
> from the authenticator and doesn't need to know username and passwd.
> However as you have said, sessions are quite short lived scope and maybe it
> is dead while the user app is using. That's really a big problem. Maybe
> there are some methods to avoid this failure. For example, the
> authenticator can send the sessionid with expiration time. When it's
> expired, ask for the sessionid again. Or, the authenticator also can send
> broadcast to all user apps when the session is expired. User apps ask to
> get a new sessionid while receiving the broadcast.
>
> 2. Basic Auth
> if the user app use the BASIC auth header(Base64) to authenticate with
> XWiki-server, there's no security at all because Base64 is easy to decode
> and all user apps can decrypt and get username and passwd easily. So I
> think only in this case that we trust all the user apps, for example these
> apps are signed and released by us, the authenticator can return Base64 to
> user apps.

I don't think it's required. AFAIK application need user authorization
to access an authenticator. Having the authenticator work only with
application we write make it pretty much useless IMO since the main
goal is to make easier for application to manipulate XWiki instances.
If an application cannot use the authenticator it will simply ask the
user/password to the user anyway.

> 3. A preconfigured httpclient/httpurlconnection
> To be honest, I don't know how to achieve this method and how to provide a
> preconfigured httpclient instance.  That means returning the serialized
> httpclient by the authenticator service?  And maybe services with "aidl"
> can just return all primitive types(
> http://developer.android.com/guide/components/aidl.html#Create), like int,
> char and list<int>, so we cann't provide a preconfigured httpclient object
> to the other apps. Or maybe we can provide all the restful apis as a
> library in our authenticator, in this way, httpclient is invisible to user
> apps. But it may cause a lot of work. Really confused! :)

I didn't had time to play with it so not sure if it make sense but
what I had in mind is that getAuthToken return a Bundle and not a
String. And Bundle seems to have the possibility to contain many kind
of objects associated to a custom String key. As far as I can see you
don't really have a put(String, Object) but maybe this can go trough
put(String, Serializable) since Bunlde itself does not seem to
serialize it and maybe it's taking a Serializable just in case and is
really serialized in rare cases (I don't see why Android would need to
store the token most of the time). So maybe an app could do something
like bundler.get("org.apache.http.client.HttpClient") and get a
pre-configured (and protected) instance of
org.apache.http.client.HttpClient. To be tested I guess.

>
>
>
>> On Tue, Apr 19, 2016 at 12:57 PM, Thomas Mortagne
>> <[hidden email] <http:///user/SendEmail.jtp?type=node&node=7599102&i=0>>
>> wrote:
>>
>> > On Tue, Apr 19, 2016 at 12:56 PM, Thomas Mortagne
>> > <[hidden email] <http:///user/SendEmail.jtp?type=node&node=7599102&i=1>>
>> wrote:
>> >> On Fri, Apr 15, 2016 at 6:25 AM, fitz <[hidden email]
>> <http:///user/SendEmail.jtp?type=node&node=7599102&i=2>> wrote:
>> >>> Hello Thomas,
>> >>>
>> >>> Thank you very much and I really appreciate your help and guidance.
>> And
>> >>> thank you for helping me improve.
>> >>>
>> >>> I will firstly use the existing REST APIs to develop this project, And
>> >>> maybe in the future I can make some specific APIs to improve
>> performance if
>> >>> time permits.
>> >>>
>> >>> Yes, the search APIs can help me get need-update contacts after the
>> >>> last-sync-time and solve the one by one comparing problem. And I will
>> be
>> >>> familiar with the use of search APIs as soon as possible so that I can
>> use
>> >>> it in the synchronization code.  Thank you for solving my confusion.
>> >>>
>> >>> And for authentication and security, considering your precious advice,
>> I
>> >>> will try to use the first idea, and just return the session so that
>> other
>> >>> xwiki android apps can use the httpclient with this session id to
>> >>> authenticate with the server.  And I will firstly implement this
>> method and
>> >>> test the effectiveness of this scheme as soon as possible.
>> >>
>> >> All that sounds good.
>> >>
>> >>>
>> >>> For the xwiki-contrib, I will ask to join the group, develop this
>> android
>> >>> project and maybe make a contribution.
>> >>
>> >> Looks like you are already member of XWiki Contrib actually.
>> >
>> > Just saw the other mail (I'm a bit late with my mails...).
>>
>
> Never mind, Thank you anyway all the same. :)
>
> Recently I have learned and understood solr query, restful apis and
> xmlpullparser. Now the android-authenticator can basically communicate with
> the XWiki-server to get all the contacts.  I have commit my code to the
> feature-rest branch of the android-authenticator repository.  As soon as
> possible I will implement the ideas above and test the effectiveness. There
> may be some other difficult issues in the future.
>
> Best Regards,
> Fitz Lee
>
>>
>> >>
>> >>>
>> >>> Yours sincerely
>> >>> Fitz Lee
>> >>>
>> >>>
>> >>> 2016-04-14 17:33 GMT+08:00 Thomas Mortagne [via XWiki] <
>> >>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=7599102&i=3>>:
>>
>> >>>
>> >>>> On Thu, Apr 14, 2016 at 7:22 AM, Fitz Lee <[hidden email]
>> >>>> <http:///user/SendEmail.jtp?type=node&node=7598982&i=0>> wrote:
>> >>>>
>> >>>> > Hi Thomas,
>> >>>> >
>> >>>> >
>> >>>> > Thank you so much for your reply and recognition.
>> >>>> >
>> >>>> >
>> >>>> > 2016-04-12 17:18 GMT+08:00 Thomas Mortagne <[hidden email]
>> >>>> <http:///user/SendEmail.jtp?type=node&node=7598982&i=1>>:
>> >>>> >
>> >>>> >> Hi Fitz,
>> >>>> >>
>> >>>> >> Great to see so much motivation from you :)
>> >>>> >>
>> >>>> >> Just don't forget that GSOC coding period is not started yet and
>> that
>> >>>> >> we still have no idea how many slots Google will give us and who
>> we
>> >>>> >> will select this year (this will be 22nd April).
>> >>>> >>
>> >>>> >>
>> >>>> > Yeah, I know the coding period of GSoC, and now I'm just striving
>> and
>> >>>> > looking forward to get this project. If I really do not pass the
>> GSoC
>> >>>> > application, it doesn't matter and I have learned a lot. As I have
>> said,
>> >>>> I
>> >>>> > will be very happy if there is anything I can help.
>> >>>> >
>> >>>> >
>> >>>> >> Yes contact synchronization in
>> >>>> >> https://github.com/xwiki-contrib/android-authenticator is not the
>> >>>> >> beginning or an experiment I never had time to finish so it's more
>> >>>> >> pseudo code that never worked yet.
>> >>>> >
>> >>>> >
>> >>>> > Considering the XWikiRESTfulAPIs in
>> >>>> > http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI,
>> the
>> >>>> apis
>> >>>> > have been well designed so that maybe I can't modify those apis. I
>> >>>> should
>> >>>> > just make use of the existing api resources to design the
>> >>>> synchronization
>> >>>> > of contacts and the process of sign-in and sign-up.
>> >>>> >
>> >>>> > Since there isn't the api like "/sync" in sampleSyncAdapter
>> >>>> > google-engine-server, which can help us to get update contacts when
>> >>>> sending
>> >>>> > the phone's dirty contacts and the last time of synchronization to
>> >>>> server,
>> >>>> > we cann't use the synchronization mechanism in SampleSyncAdapter. I
>> >>>> think
>> >>>> > maybe we can use the following method to synchronize contacts.
>> >>>> >
>> >>>> > * server to client (update local contacts from server when needed):
>> >>>> > In the function, SynAdapter.onPerformSync(), the process is
>> >>>> > "XWikiConnector.getAllUsers>> compare with the local contacts and
>> find
>> >>>> the
>> >>>> > contacts which should be updated >> ContactManager.updateContacts".
>> >>>> > Available apis:
>> >>>> > GetAllUserList: curl
>> >>>> >
>> http://localhost:8080/xwiki/rest/wikis/query?q=object:XWiki.XWikiUsers
>> >>>> > GetUserInfo: curl
>> >>>> >
>> >>>>
>> http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/FitzLee/objects/XWiki.XWikiUsers/0
>> >>>> >
>> >>>> > * client to server (edit, add, delete contacts and meanwhile
>> synchronize
>> >>>> > from client to server):
>> >>>> > When editing, adding or deleting contacts in android activities, we
>> >>>> should
>> >>>> > first request the xwiki server. Update contacts if allowed, or
>> discard
>> >>>> the
>> >>>> > modification if not be authorized or have no permission.
>> >>>> > Available apis:
>> >>>> > EditUser: curl -u FitzLee:fitz2xwiki -X PUT -H "Content-type:
>> >>>> > application/x-www-form-urlencoded" -H "Accept: application/xml" -d
>> >>>> > "className=XWiki.XWikiUsers" -d "property#company=iie"
>> >>>> >
>> >>>>
>> http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/FitzLee/objects/XWiki.XWikiUsers/0
>> >>>> >
>> >>>>
>> >>>> Yes the goal for now is to have an application working on any
>> existing
>> >>>> wiki (lets say not older than 7.4.x since that's the current LTS but
>> >>>> the lowest the better).
>> >>>>
>> >>>> You can if you have time implement new REST APIs (it's always usefull
>> >>>> anyway) that would improve performances for example but the
>> >>>> application should not assume that these new API would exist in the
>> >>>> target instance that could be too old for it. So in the GSOC
>> timeframe
>> >>>> it would be safer to just do with what already exist which indeed
>> >>>> might give more work to the application than a specific API designed
>> >>>> specifically for synchronization but it should be doable.
>> >>>>
>> >>>> > I see two main possibility for this:
>> >>>> >> * the first thing you should do I think is download the
>> jetty/hsqld
>> >>>> >> all in one distribution on
>> >>>> >> http://www.xwiki.org/xwiki/bin/view/Main/Download and use that as
>> test
>> >>>> >> server (you have admin right in it and can create as many test
>> users
>> >>>> >> or groups as you want)
>> >>>> >> * as soon as you want to test volume and compatibility with
>> existing
>> >>>> >> instance of XWiki you can register on http://www.xwiki.org which
>> >>>> >> contains 1519 users right now
>> >>>> >>
>> >>>> >
>> >>>> > I have downloaded the enterprise xwiki jetty server 8.0 and tried
>> to
>> >>>> create
>> >>>> > some applications and understand the features of the server. Using
>> the
>> >>>> > administrator Admin:admin, I have create some users and groups. And
>> I
>> >>>> use
>> >>>> > the python script curl to learn how to get user-list, group-list
>> and how
>> >>>> to
>> >>>> > modify them with the restfull apis. In addition, I find a demo
>> which is
>> >>>> > useful for me to be familiar with the apis, like
>> >>>> > xwiki-contrib/android-client(
>> >>>> https://github.com/xwiki-contrib/android-client).
>> >>>> > And I will write my own android restful interactive method, mainly
>> used
>> >>>> for
>> >>>> > the authentication and the management of users and groups.
>> >>>> >
>> >>>> > But for testing the volume and compatibility of the synchronization
>> in
>> >>>> > SynAdapter.onPerformSync(), how do we compare the contact
>> differences
>> >>>> > between server and client and find the update contacts which need
>> to be
>> >>>> > updated?  It's a big problem if there are 1519 users and maybe I
>> should
>> >>>> > compare one by one to find which contact should be updated because
>> >>>> > there'are no relevant apis to get the need-to-update contacts from
>> >>>> server
>> >>>> > after the last time of synchronization.
>> >>>>
>> >>>> You don't have a sync API but you have a search API in which you can
>> >>>> request all the documents containing a user object and that were
>> >>>> modified after some date for example. You can use either sql or solr.
>> >>>>
>> >>>> >
>> >>>> >> (1) sign in
>> >>>> >> > it is easy,just like my analysis of android SampleSyncAdapter,
>> >>>> including
>> >>>> >> the
>> >>>> >> > server connection with XWikiconnector and the account added by
>> >>>> >> > AccountManager
>> >>>> >>
>> >>>> >> Don't reduce too quickly the level of difficulty on this side, one
>> >>>> >> thing you will have to work around is that standard XWiki instance
>> >>>> >> have no token based authentication so you will have to hack an as
>> safe
>> >>>> >> as possible BASIC auth based implementation of Android
>> authenticator
>> >>>> >> (which mean users of the authenticator can't just ask for the
>> token
>> >>>> >> and connect to XWiki server).
>> >>>> >
>> >>>> >
>> >>>> > Thank you for your reminder.  From the restfull apis, I have seen
>> the
>> >>>> two
>> >>>> > methods of authentication,  including HTTP BASIC Auth and XWiki
>> session
>> >>>> > auth.  But Question is how users of the authenticator to connect to
>> >>>> XWiki
>> >>>> > server without username and password as I can't modify the
>> >>>> authentication
>> >>>> > method in the server and can only use the BASIC Auth?  use BASE64
>> to
>> >>>> > encrypt the password? or ask for the session and communicate with
>> >>>> server?
>> >>>> > and BASE64 can just enhance the security in some extent. and maybe
>> we
>> >>>> can
>> >>>> > use the https to ensure the authenticator security. I am so
>> confused.
>> >>>> Could
>> >>>> > you give me some tips about authentication and security?
>> >>>>
>> >>>> I did not had time to experiment on this but here as some ideas of
>> >>>> things to try:
>> >>>>
>> >>>> 1) return whatever identify the session (I had forgotten about
>> session
>> >>>> access, thanks for the reminder :)). Then the application put that
>> >>>> session id in whatever http client tool it want to use. That's
>> >>>> probably the safest and what look the most like a the classical token
>> >>>> based access.
>> >>>>
>> >>>> 2) provide a preconfigured instance of Android HTTP Client in which:
>> >>>> 2.a) a sessions have already been started with the server and the
>> HTTP
>> >>>> Client keep it alive (that's the safest I can think of right now)
>> >>>> 2.b) the BASIC auth header cannot be read from outside (for example
>> >>>> extends it in a custom class and forbid any public access to the
>> >>>> Authorization header) that can be used to request the XWiki server
>> >>>>
>> >>>> 3) the worst case scenario is to return the BASIC auth header (it
>> >>>> looks like "Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l"). It's
>> >>>> encoded but it's easy to decode. The application would just set it in
>> >>>> whatever http tool it's using. An application can use an
>> authenticator
>> >>>> only if the user allows it and the alternative is that each
>> >>>> application deal with login/password on its side so it's still better
>> >>>> than nothing :)
>> >>>>
>> >>>> Whatever solution is chosen the best would be to provide some small
>> >>>> helper library that deal with XWiki authenticator and for example
>> >>>> generate a pre-configured http client instance for the application
>> >>>> with what the authenticator return. That way it's easier to change
>> the
>> >>>> way the authenticator works without breaking application (at least
>> >>>> application that use the recommended library).
>> >>>>
>> >>>> >
>> >>>> >
>> >>>> >> > (3) synchronization of contacts
>> >>>> >> > (4) edit the contact
>> >>>> >> > (5) access by other apps
>> >>>> >> > Question: Are there more other requirements in this app, like
>> adding
>> >>>> >> > friends(general person) and creating new xwiki
>> >>>> account(administrator)?
>> >>>> >> > maybe it will cause more demands and be more complex.
>> >>>> >> >
>> >>>> >>
>> >>>> >> There is no real "friends" system in standard XWiki and anyway the
>> >>>> >> main use case for this application being intranets you usually
>> want to
>> >>>> >> simply synchronize all users of the wiki since those are your
>> >>>> >> coworkers. An improvement would be to allow the user to select a
>> list
>> >>>> >> of XWiki groups to synchronize if you don't want the whole wiki in
>> a
>> >>>> >> big company or public wiki like xwiki.org for example.
>> >>>> >
>> >>>> >
>> >>>> > So there are two choices:
>> >>>> > 1.  Synchronize all contacts who are my coworkers
>> >>>> > 2.  Synchronize the contacts in the XWiki group which
>> authenticator-user
>> >>>> > wants to select.
>> >>>>
>> >>>> And possibly other idea you may have while knowing XWiki better :)
>> >>>>
>> >>>> But on my side 1 and 2 would already be great.
>> >>>>
>> >>>> >
>> >>>> >> 4. support version and ui
>> >>>> >> > (1) ui design
>> >>>> >> > * material design >=4.4 with the support library support-v7
>> >>>> >> > (2) support version
>> >>>> >> > * The ui design can support the lowest 2.3 version and the
>> android
>> >>>> >> > sampleSynAdapter can also support 2.3 version. So I think our
>> >>>> >> authenticator
>> >>>> >> > app can support the lowest 2.3 version if needed.
>> >>>> >> > Question: Maybe there are somethings I have not noticed, so this
>> >>>> >> conclusion
>> >>>> >> > is wrong, please give me some advice? Is that OK?
>> >>>> >>
>> >>>> >> Supporting the lowest possible version is always nicer for users
>> but
>> >>>> >> according to
>> http://developer.android.com/about/dashboards/index.html
>> >>>> >> no need to go beyond 4.1.
>> >>>> >>
>> >>>> >> 4.4 seems to still be a bit too recent and might left behind too
>> many
>> >>>> >> users.
>> >>>> >>
>> >>>> >>
>> >>>> > Yes, so 4.1 may be the best choice. For the design of UI, the
>> support
>> >>>> > library support-v7 can solve the problem. And I will use the
>> perfect
>> >>>> > material design style if the android sdk version >= 4.4.
>> >>>> >
>> >>>> >>
>> >>>> >> > 5. account permission
>> >>>> >> > In AccountGeneral.java there are two permissions , like
>> >>>> >> > AUTHTOKEN_TYPE_READ_ONLY, AUTHTOKEN_TYPE_FULL_ACCESS.  Could you
>> tell
>> >>>> me
>> >>>> >> > what the permissions main?  other xwiki instance access  limits
>> ?
>> >>>> >> Account
>> >>>> >> > manager? And where should I use them?
>> >>>> >>
>> >>>> >> You have many right on XWiki (and any extension can add more) plus
>> it
>> >>>> >> depend what part of the wiki you are accessing.
>> >>>> >>
>> >>>> >> But since you don't have any concept of token associated to an
>> >>>> >> application in standard XWiki the application will have whatever
>> right
>> >>>> >> the user have so I guess you can return AUTHTOKEN_TYPE_FULL_ACCESS
>> all
>> >>>> >> the time in the Android authenticator (then the application will
>> have
>> >>>> >> to deal with 403 errors).
>> >>>> >
>> >>>> >
>> >>>> > OK, I will return AUTHTOKEN_TYPE_FULL_ACCESS and deal with the
>> >>>> unauthorized
>> >>>> > or other response error.
>> >>>> >
>> >>>> >
>> >>>> >>
>> >>>> >> --
>> >>>> >> Thomas Mortagne
>> >>>> >> _______________________________________________
>> >>>> >> devs mailing list
>> >>>> >> [hidden email] <
>> http:///user/SendEmail.jtp?type=node&node=7598982&i=2>
>> >>>> >> http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>
>> >>>> >
>> >>>> >  At last, should I use the xwiki JIRA to create a custom issue and
>> give
>> >>>> you
>> >>>> > a pull requst when I have some new idea or make progress?
>> >>>>
>> >>>> Anyone who is a member of the XWiki Contrib organization (basically
>> >>>> anyone who ask to be) have write access on
>> >>>> https://github.com/xwiki-contrib/android-authenticator so no need
>> for
>> >>>> pull request. It's not like it was in a very stable state right now
>> >>>> anyway :)
>> >>>>
>> >>>> >
>> >>>> > Best Regards,
>> >>>> > Fitz Lee | UCAS Master
>> >>>> > _______________________________________________
>> >>>> > devs mailing list
>> >>>> > [hidden email] <
>> http:///user/SendEmail.jtp?type=node&node=7598982&i=3>
>> >>>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Thomas Mortagne
>> >>>> _______________________________________________
>> >>>> devs mailing list
>> >>>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=7598982&i=4>
>>
>> >>>> http://lists.xwiki.org/mailman/listinfo/devs
>> >>>>
>> >>>>
>> >>>> ------------------------------
>> >>>> If you reply to this email, your message will be added to the
>> discussion
>> >>>> below:
>> >>>>
>> >>>>
>> http://xwiki.475771.n2.nabble.com/Questions-Gsoc2016-XWiki-Android-authenticator-tp7598932p7598982.html
>> >>>> To unsubscribe from Questions, Gsoc2016, XWiki Android-authenticator,
>> click
>> >>>> here
>> >>>> <
>>
>> >>>> .
>> >>>> NAML
>> >>>> <
>> http://xwiki.475771.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> View this message in context:
>> http://xwiki.475771.n2.nabble.com/Questions-Gsoc2016-XWiki-Android-authenticator-tp7598932p7599003.html
>> >>> Sent from the XWiki- Dev mailing list archive at Nabble.com.
>> >>> _______________________________________________
>> >>> devs mailing list
>> >>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=7599102&i=4>
>> >>> http://lists.xwiki.org/mailman/listinfo/devs
>> >>
>> >>
>> >>
>> >> --
>> >> Thomas Mortagne
>> >
>> >
>> >
>> > --
>> > Thomas Mortagne
>>
>>
>>
>> --
>> Thomas Mortagne
>> _______________________________________________
>> devs mailing list
>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=7599102&i=5>
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>>
>> ------------------------------
>> If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://xwiki.475771.n2.nabble.com/Questions-Gsoc2016-XWiki-Android-authenticator-tp7598932p7599102.html
>> To unsubscribe from Questions, Gsoc2016, XWiki Android-authenticator, click
>> here
>> <
>> .
>> NAML
>> <http://xwiki.475771.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
>
>
>
> --
> View this message in context: http://xwiki.475771.n2.nabble.com/Questions-Gsoc2016-XWiki-Android-authenticator-tp7598932p7599117.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

[fitz]

2016-04-21 17:06 GMT+08:00 Thomas Mortagne [via XWiki] <[hidden email]>:

On Thu, Apr 21, 2016 at 9:50 AM, fitz <[hidden email]> wrote:

> Hi Thomas,
>
> 2016-04-20 23:11 GMT+08:00 Thomas Mortagne [via XWiki] <
> [hidden email]>:
>
>> Actually after thinking more about it session id does not seems such a
>> good idea in practice: sessions are quite short lived scope and users
>> might end up authenticating again and again. Also when synchronizer
>> wake up there is a good chance the session is dead and we are not
>> going to constantly ask credential to the user out of the blue for
>> what is supposed to be an invisible background task.
>>
>ed
> Yeah, As we have discussed, there are three ways for the user app to

> authenticate and communicate with XWiki-server:
> 1.session id
> It may be the best and simple choice because user app just gets sessionid
> from the authenticator and doesn't need to know username and passwd.
> However as you have said, sessions are quite short lived scope and maybe it
> is dead while the user app is using. That's really a big problem. Maybe
> there are some methods to avoid this failure. For example, the
> authenticator can send the sessionid with expiration time. When it's
> expired, ask for the sessionid again. Or, the authenticator also can send
> broadcast to all user apps when the session is expired. User apps ask to
> get a new sessionid while receiving the broadcast.
>
> 2. Basic Auth
> if the user app use the BASIC auth header(Base64) to authenticate with
> XWiki-server, there's no security at all because Base64 is easy to decode
> and all user apps can decrypt and get username and passwd easily. So I
> think only in this case that we trust all the user apps, for example these
> apps are signed and released by us, the authenticator can return Base64 to
> user apps.

I don't think it's required. AFAIK application need user authorization
to access an authenticator. Having the authenticator work only with
application we write make it pretty much useless IMO since the main
goal is to make easier for application to manipulate XWiki instances.
If an application cannot use the authenticator it will simply ask the
user/password to the user anyway.

> 3. A preconfigured httpclient/httpurlconnection
> To be honest, I don't know how to achieve this method and how to provide a
> preconfigured httpclient instance.  That means returning the serialized
> httpclient by the authenticator service?  And maybe services with "aidl"
> can just return all primitive types(
> http://developer.android.com/guide/components/aidl.html#Create), like int,
> char and list<int>, so we cann't provide a preconfigured httpclient object
> to the other apps. Or maybe we can provide all the restful apis as a
> library in our authenticator, in this way, httpclient is invisible to user
> apps. But it may cause a lot of work. Really confused! :)

I didn't had time to play with it so not sure if it make sense but
what I had in mind is that getAuthToken return a Bundle and not a
String. And Bundle seems to have the possibility to contain many kind
of objects associated to a custom String key. As far as I can see you
don't really have a put(String, Object) but maybe this can go trough
put(String, Serializable) since Bunlde itself does not seem to
serialize it and maybe it's taking a Serializable just in case and is
really serialized in rare cases (I don't see why Android would need to
store the token most of the time). So maybe an app could do something
like bundler.get("org.apache.http.client.HttpClient") and get a
pre-configured (and protected) instance of
org.apache.http.client.HttpClient. To be tested I guess.

Ok, I see. Thank you so much.

I will try to implement these methods and test their effectiveness ASAP, ha ha.

Thanks,

Fitz

 

>
>
>
>> On Tue, Apr 19, 2016 at 12:57 PM, Thomas Mortagne
>> <[hidden email] <http:///user/SendEmail.jtp?type=node&node=7599102&i=0>>
>> wrote:
>>
>> > On Tue, Apr 19, 2016 at 12:56 PM, Thomas Mortagne
>> > <[hidden email] <http:///user/SendEmail.jtp?type=node&node=7599102&i=1>>
>> wrote:
>> >> On Fri, Apr 15, 2016 at 6:25 AM, fitz <[hidden email]

>> <http:///user/SendEmail.jtp?type=node&node=7599102&i=2>> wrote:

>> >>> Hello Thomas,
>> >>>
>> >>> Thank you very much and I really appreciate your help and guidance.
>> And
>> >>> thank you for helping me improve.
>> >>>
>> >>> I will firstly use the existing REST APIs to develop this project, And
>> >>> maybe in the future I can make some specific APIs to improve
>> performance if
>> >>> time permits.
>> >>>
>> >>> Yes, the search APIs can help me get need-update contacts after the
>> >>> last-sync-time and solve the one by one comparing problem. And I will
>> be
>> >>> familiar with the use of search APIs as soon as possible so that I can
>> use
>> >>> it in the synchronization code.  Thank you for solving my confusion.
>> >>>
>> >>> And for authentication and security, considering your precious advice,
>> I
>> >>> will try to use the first idea, and just return the session so that
>> other
>> >>> xwiki android apps can use the httpclient with this session id to
>> >>> authenticate with the server.  And I will firstly implement this
>> method and
>> >>> test the effectiveness of this scheme as soon as possible.
>> >>
>> >> All that sounds good.
>> >>
>> >>>
>> >>> For the xwiki-contrib, I will ask to join the group, develop this
>> android
>> >>> project and maybe make a contribution.
>> >>
>> >> Looks like you are already member of XWiki Contrib actually.
>> >
>> > Just saw the other mail (I'm a bit late with my mails...).
>>
>
> Never mind, Thank you anyway all the same. :)
>
> Recently I have learned and understood solr query, restful apis and
> xmlpullparser. Now the android-authenticator can basically communicate with
> the XWiki-server to get all the contacts.  I have commit my code to the
> feature-rest branch of the android-authenticator repository.  As soon as
> possible I will implement the ideas above and test the effectiveness. There
> may be some other difficult issues in the future.
>
> Best Regards,
> Fitz Lee
>
>>
>> >>
>> >>>
>> >>> Yours sincerely
>> >>> Fitz Lee
>> >>>
>> >>>
>> >>> 2016-04-14 17:33 GMT+08:00 Thomas Mortagne [via XWiki] <

>> >>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=7599102&i=3>>:

>>

>> >>>
>> >>>> On Thu, Apr 14, 2016 at 7:22 AM, Fitz Lee <[hidden email]
>> >>>> <http:///user/SendEmail.jtp?type=node&node=7598982&i=0>> wrote:
>> >>>>
>> >>>> > Hi Thomas,
>> >>>> >
>> >>>> >
>> >>>> > Thank you so much for your reply and recognition.
>> >>>> >
>> >>>> >
>> >>>> > 2016-04-12 17:18 GMT+08:00 Thomas Mortagne <[hidden email]
>> >>>> <http:///user/SendEmail.jtp?type=node&node=7598982&i=1>>:
>> >>>> >
>> >>>> >> Hi Fitz,
>> >>>> >>
>> >>>> >> Great to see so much motivation from you :)
>> >>>> >>
>> >>>> >> Just don't forget that GSOC coding period is not started yet and
>> that
>> >>>> >> we still have no idea how many slots Google will give us and who
>> we
>> >>>> >> will select this year (this will be 22nd April).
>> >>>> >>
>> >>>> >>
>> >>>> > Yeah, I know the coding period of GSoC, and now I'm just striving
>> and
>> >>>> > looking forward to get this project. If I really do not pass the
>> GSoC
>> >>>> > application, it doesn't matter and I have learned a lot. As I have
>> said,
>> >>>> I
>> >>>> > will be very happy if there is anything I can help.
>> >>>> >
>> >>>> >
>> >>>> >> Yes contact synchronization in
>> >>>> >> https://github.com/xwiki-contrib/android-authenticator is not the
>> >>>> >> beginning or an experiment I never had time to finish so it's more
>> >>>> >> pseudo code that never worked yet.
>> >>>> >
>> >>>> >
>> >>>> > Considering the XWikiRESTfulAPIs in
>> >>>> > http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI,
>> the
>> >>>> apis
>> >>>> > have been well designed so that maybe I can't modify those apis. I
>> >>>> should
>> >>>> > just make use of the existing api resources to design the
>> >>>> synchronization
>> >>>> > of contacts and the process of sign-in and sign-up.
>> >>>> >
>> >>>> > Since there isn't the api like "/sync" in sampleSyncAdapter
>> >>>> > google-engine-server, which can help us to get update contacts when
>> >>>> sending
>> >>>> > the phone's dirty contacts and the last time of synchronization to
>> >>>> server,
>> >>>> > we cann't use the synchronization mechanism in SampleSyncAdapter. I
>> >>>> think
>> >>>> > maybe we can use the following method to synchronize contacts.
>> >>>> >
>> >>>> > * server to client (update local contacts from server when needed):
>> >>>> > In the function, SynAdapter.onPerformSync(), the process is
>> >>>> > "XWikiConnector.getAllUsers>> compare with the local contacts and
>> find
>> >>>> the
>> >>>> > contacts which should be updated >> ContactManager.updateContacts".
>> >>>> > Available apis:
>> >>>> > GetAllUserList: curl
>> >>>> >
>> http://localhost:8080/xwiki/rest/wikis/query?q=object:XWiki.XWikiUsers
>> >>>> > GetUserInfo: curl
>> >>>> >
>> >>>>
>> http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/FitzLee/objects/XWiki.XWikiUsers/0
>> >>>> >
>> >>>> > * client to server (edit, add, delete contacts and meanwhile
>> synchronize
>> >>>> > from client to server):
>> >>>> > When editing, adding or deleting contacts in android activities, we
>> >>>> should
>> >>>> > first request the xwiki server. Update contacts if allowed, or
>> discard
>> >>>> the
>> >>>> > modification if not be authorized or have no permission.
>> >>>> > Available apis:
>> >>>> > EditUser: curl -u FitzLee:fitz2xwiki -X PUT -H "Content-type:
>> >>>> > application/x-www-form-urlencoded" -H "Accept: application/xml" -d
>> >>>> > "className=XWiki.XWikiUsers" -d "property#company=iie"
>> >>>> >
>> >>>>
>> http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/FitzLee/objects/XWiki.XWikiUsers/0
>> >>>> >
>> >>>>
>> >>>> Yes the goal for now is to have an application working on any
>> existing
>> >>>> wiki (lets say not older than 7.4.x since that's the current LTS but
>> >>>> the lowest the better).
>> >>>>
>> >>>> You can if you have time implement new REST APIs (it's always usefull
>> >>>> anyway) that would improve performances for example but the
>> >>>> application should not assume that these new API would exist in the
>> >>>> target instance that could be too old for it. So in the GSOC
>> timeframe
>> >>>> it would be safer to just do with what already exist which indeed
>> >>>> might give more work to the application than a specific API designed
>> >>>> specifically for synchronization but it should be doable.
>> >>>>
>> >>>> > I see two main possibility for this:
>> >>>> >> * the first thing you should do I think is download the
>> jetty/hsqld
>> >>>> >> all in one distribution on
>> >>>> >> http://www.xwiki.org/xwiki/bin/view/Main/Download and use that as
>> test
>> >>>> >> server (you have admin right in it and can create as many test
>> users
>> >>>> >> or groups as you want)
>> >>>> >> * as soon as you want to test volume and compatibility with
>> existing
>> >>>> >> instance of XWiki you can register on http://www.xwiki.org which
>> >>>> >> contains 1519 users right now
>> >>>> >>
>> >>>> >
>> >>>> > I have downloaded the enterprise xwiki jetty server 8.0 and tried
>> to
>> >>>> create
>> >>>> > some applications and understand the features of the server. Using
>> the
>> >>>> > administrator Admin:admin, I have create some users and groups. And
>> I
>> >>>> use
>> >>>> > the python script curl to learn how to get user-list, group-list
>> and how
>> >>>> to
>> >>>> > modify them with the restfull apis. In addition, I find a demo
>> which is
>> >>>> > useful for me to be familiar with the apis, like
>> >>>> > xwiki-contrib/android-client(
>> >>>> https://github.com/xwiki-contrib/android-client).
>> >>>> > And I will write my own android restful interactive method, mainly
>> used
>> >>>> for
>> >>>> > the authentication and the management of users and groups.
>> >>>> >
>> >>>> > But for testing the volume and compatibility of the synchronization
>> in
>> >>>> > SynAdapter.onPerformSync(), how do we compare the contact
>> differences
>> >>>> > between server and client and find the update contacts which need
>> to be
>> >>>> > updated?  It's a big problem if there are 1519 users and maybe I
>> should
>> >>>> > compare one by one to find which contact should be updated because
>> >>>> > there'are no relevant apis to get the need-to-update contacts from
>> >>>> server
>> >>>> > after the last time of synchronization.
>> >>>>
>> >>>> You don't have a sync API but you have a search API in which you can
>> >>>> request all the documents containing a user object and that were
>> >>>> modified after some date for example. You can use either sql or solr.
>> >>>>
>> >>>> >
>> >>>> >> (1) sign in
>> >>>> >> > it is easy,just like my analysis of android SampleSyncAdapter,
>> >>>> including
>> >>>> >> the
>> >>>> >> > server connection with XWikiconnector and the account added by
>> >>>> >> > AccountManager
>> >>>> >>
>> >>>> >> Don't reduce too quickly the level of difficulty on this side, one
>> >>>> >> thing you will have to work around is that standard XWiki instance
>> >>>> >> have no token based authentication so you will have to hack an as
>> safe
>> >>>> >> as possible BASIC auth based implementation of Android
>> authenticator
>> >>>> >> (which mean users of the authenticator can't just ask for the
>> token
>> >>>> >> and connect to XWiki server).
>> >>>> >
>> >>>> >
>> >>>> > Thank you for your reminder.  From the restfull apis, I have seen
>> the
>> >>>> two
>> >>>> > methods of authentication,  including HTTP BASIC Auth and XWiki
>> session
>> >>>> > auth.  But Question is how users of the authenticator to connect to
>> >>>> XWiki
>> >>>> > server without username and password as I can't modify the
>> >>>> authentication
>> >>>> > method in the server and can only use the BASIC Auth?  use BASE64
>> to
>> >>>> > encrypt the password? or ask for the session and communicate with
>> >>>> server?
>> >>>> > and BASE64 can just enhance the security in some extent. and maybe
>> we
>> >>>> can
>> >>>> > use the https to ensure the authenticator security. I am so
>> confused.
>> >>>> Could
>> >>>> > you give me some tips about authentication and security?
>> >>>>
>> >>>> I did not had time to experiment on this but here as some ideas of
>> >>>> things to try:
>> >>>>
>> >>>> 1) return whatever identify the session (I had forgotten about
>> session
>> >>>> access, thanks for the reminder :)). Then the application put that
>> >>>> session id in whatever http client tool it want to use. That's
>> >>>> probably the safest and what look the most like a the classical token
>> >>>> based access.
>> >>>>
>> >>>> 2) provide a preconfigured instance of Android HTTP Client in which:
>> >>>> 2.a) a sessions have already been started with the server and the
>> HTTP
>> >>>> Client keep it alive (that's the safest I can think of right now)
>> >>>> 2.b) the BASIC auth header cannot be read from outside (for example
>> >>>> extends it in a custom class and forbid any public access to the
>> >>>> Authorization header) that can be used to request the XWiki server
>> >>>>
>> >>>> 3) the worst case scenario is to return the BASIC auth header (it
>> >>>> looks like "Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l"). It's
>> >>>> encoded but it's easy to decode. The application would just set it in
>> >>>> whatever http tool it's using. An application can use an
>> authenticator
>> >>>> only if the user allows it and the alternative is that each
>> >>>> application deal with login/password on its side so it's still better
>> >>>> than nothing :)
>> >>>>
>> >>>> Whatever solution is chosen the best would be to provide some small
>> >>>> helper library that deal with XWiki authenticator and for example
>> >>>> generate a pre-configured http client instance for the application
>> >>>> with what the authenticator return. That way it's easier to change
>> the
>> >>>> way the authenticator works without breaking application (at least
>> >>>> application that use the recommended library).
>> >>>>
>> >>>> >
>> >>>> >
>> >>>> >> > (3) synchronization of contacts
>> >>>> >> > (4) edit the contact
>> >>>> >> > (5) access by other apps
>> >>>> >> > Question: Are there more other requirements in this app, like
>> adding
>> >>>> >> > friends(general person) and creating new xwiki
>> >>>> account(administrator)?
>> >>>> >> > maybe it will cause more demands and be more complex.
>> >>>> >> >
>> >>>> >>
>> >>>> >> There is no real "friends" system in standard XWiki and anyway the
>> >>>> >> main use case for this application being intranets you usually
>> want to
>> >>>> >> simply synchronize all users of the wiki since those are your
>> >>>> >> coworkers. An improvement would be to allow the user to select a
>> list
>> >>>> >> of XWiki groups to synchronize if you don't want the whole wiki in
>> a
>> >>>> >> big company or public wiki like xwiki.org for example.
>> >>>> >
>> >>>> >
>> >>>> > So there are two choices:
>> >>>> > 1.  Synchronize all contacts who are my coworkers
>> >>>> > 2.  Synchronize the contacts in the XWiki group which
>> authenticator-user
>> >>>> > wants to select.
>> >>>>
>> >>>> And possibly other idea you may have while knowing XWiki better :)
>> >>>>
>> >>>> But on my side 1 and 2 would already be great.
>> >>>>
>> >>>> >
>> >>>> >> 4. support version and ui
>> >>>> >> > (1) ui design
>> >>>> >> > * material design >=4.4 with the support library support-v7
>> >>>> >> > (2) support version
>> >>>> >> > * The ui design can support the lowest 2.3 version and the
>> android
>> >>>> >> > sampleSynAdapter can also support 2.3 version. So I think our
>> >>>> >> authenticator
>> >>>> >> > app can support the lowest 2.3 version if needed.
>> >>>> >> > Question: Maybe there are somethings I have not noticed, so this
>> >>>> >> conclusion
>> >>>> >> > is wrong, please give me some advice? Is that OK?
>> >>>> >>
>> >>>> >> Supporting the lowest possible version is always nicer for users
>> but
>> >>>> >> according to
>> http://developer.android.com/about/dashboards/index.html
>> >>>> >> no need to go beyond 4.1.
>> >>>> >>
>> >>>> >> 4.4 seems to still be a bit too recent and might left behind too
>> many
>> >>>> >> users.
>> >>>> >>
>> >>>> >>
>> >>>> > Yes, so 4.1 may be the best choice. For the design of UI, the
>> support
>> >>>> > library support-v7 can solve the problem. And I will use the
>> perfect
>> >>>> > material design style if the android sdk version >= 4.4.
>> >>>> >
>> >>>> >>
>> >>>> >> > 5. account permission
>> >>>> >> > In AccountGeneral.java there are two permissions , like
>> >>>> >> > AUTHTOKEN_TYPE_READ_ONLY, AUTHTOKEN_TYPE_FULL_ACCESS.  Could you
>> tell
>> >>>> me
>> >>>> >> > what the permissions main?  other xwiki instance access  limits
>> ?
>> >>>> >> Account
>> >>>> >> > manager? And where should I use them?
>> >>>> >>
>> >>>> >> You have many right on XWiki (and any extension can add more) plus
>> it
>> >>>> >> depend what part of the wiki you are accessing.
>> >>>> >>
>> >>>> >> But since you don't have any concept of token associated to an
>> >>>> >> application in standard XWiki the application will have whatever
>> right
>> >>>> >> the user have so I guess you can return AUTHTOKEN_TYPE_FULL_ACCESS
>> all
>> >>>> >> the time in the Android authenticator (then the application will
>> have
>> >>>> >> to deal with 403 errors).
>> >>>> >
>> >>>> >
>> >>>> > OK, I will return AUTHTOKEN_TYPE_FULL_ACCESS and deal with the
>> >>>> unauthorized
>> >>>> > or other response error.
>> >>>> >
>> >>>> >
>> >>>> >>
>> >>>> >> --
>> >>>> >> Thomas Mortagne
>> >>>> >> _______________________________________________
>> >>>> >> devs mailing list
>> >>>> >> [hidden email] <
>> http:///user/SendEmail.jtp?type=node&node=7598982&i=2>
>> >>>> >> http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>
>> >>>> >
>> >>>> >  At last, should I use the xwiki JIRA to create a custom issue and
>> give
>> >>>> you
>> >>>> > a pull requst when I have some new idea or make progress?
>> >>>>
>> >>>> Anyone who is a member of the XWiki Contrib organization (basically
>> >>>> anyone who ask to be) have write access on
>> >>>> https://github.com/xwiki-contrib/android-authenticator so no need
>> for
>> >>>> pull request. It's not like it was in a very stable state right now
>> >>>> anyway :)
>> >>>>
>> >>>> >
>> >>>> > Best Regards,
>> >>>> > Fitz Lee | UCAS Master
>> >>>> > _______________________________________________
>> >>>> > devs mailing list
>> >>>> > [hidden email] <
>> http:///user/SendEmail.jtp?type=node&node=7598982&i=3>
>> >>>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Thomas Mortagne
>> >>>> _______________________________________________
>> >>>> devs mailing list
>> >>>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=7598982&i=4>
>>
>> >>>> http://lists.xwiki.org/mailman/listinfo/devs
>> >>>>
>> >>>>
>> >>>> ------------------------------
>> >>>> If you reply to this email, your message will be added to the
>> discussion
>> >>>> below:
>> >>>>
>> >>>>
>> http://xwiki.475771.n2.nabble.com/Questions-Gsoc2016-XWiki-Android-authenticator-tp7598932p7598982.html
>> >>>> To unsubscribe from Questions, Gsoc2016, XWiki Android-authenticator,
>> click
>> >>>> here
>> >>>> <
>>
>> >>>> .
>> >>>> NAML
>> >>>> <
>> http://xwiki.475771.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> View this message in context:
>> http://xwiki.475771.n2.nabble.com/Questions-Gsoc2016-XWiki-Android-authenticator-tp7598932p7599003.html
>> >>> Sent from the XWiki- Dev mailing list archive at Nabble.com.
>> >>> _______________________________________________
>> >>> devs mailing list

>> >>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=7599102&i=4>
>> >>> http://lists.xwiki.org/mailman/listinfo/devs

>> >>
>> >>
>> >>
>> >> --
>> >> Thomas Mortagne
>> >
>> >
>> >
>> > --
>> > Thomas Mortagne
>>
>>
>>
>> --
>> Thomas Mortagne
>> _______________________________________________
>> devs mailing list

>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=7599102&i=5>
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>>
>> ------------------------------
>> If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://xwiki.475771.n2.nabble.com/Questions-Gsoc2016-XWiki-Android-authenticator-tp7598932p7599102.html
>> To unsubscribe from Questions, Gsoc2016, XWiki Android-authenticator, click
>> here
>> <
>> .

>> NAML
>> <http://xwiki.475771.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
>
>
>
> --
> View this message in context: http://xwiki.475771.n2.nabble.com/Questions-Gsoc2016-XWiki-Android-authenticator-tp7598932p7599117.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

---

If you reply to this email, your message will be added to the discussion below:

http://xwiki.475771.n2.nabble.com/Questions-Gsoc2016-XWiki-Android-authenticator-tp7598932p7599118.html

To unsubscribe from Questions, Gsoc2016, XWiki Android-authenticator, click here.
NAML