On Fri, Apr 15, 2016 at 6:25 AM, fitz <[email protected]> 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] < > [email protected]>: > >> 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 >> <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> >> > > > > > -- > 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 > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
