Yours sincerely
Fitz Lee
2016-04-14 17:33 GMT+08:00 Thomas Mortagne [via XWiki] <
ml-node+s475771n7598982h70(a)n2.nabble.com>gt;:
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/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…
>
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-authenti…
To unsubscribe from Questions, Gsoc2016, XWiki Android-authenticator, click
here
<http://xwiki.475771.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=7598932&code=bGVlZml0c0BnbWFpbC5jb218NzU5ODkzMnwtMjQ4MTUwNw==>
.
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>
.
_______________________________________________
devs mailing list
devs(a)xwiki.org