Hi Thomas,
Thank you so much for your reply and recognition.
2016-04-12 17:18 GMT+08:00 Thomas Mortagne <thomas.mortagne(a)xwiki.com>om>:
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/obj…
* 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/obj…
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-clien….
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
devs(a)xwiki.org
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