2016-04-21 17:06 GMT+08:00 Thomas Mortagne [via XWiki] < [email protected]>:
> On Thu, Apr 21, 2016 at 9:50 AM, fitz <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=7599118&i=0>> wrote: > > > Hi Thomas, > > > > 2016-04-20 23:11 GMT+08:00 Thomas Mortagne [via XWiki] < > > [hidden email] <http:///user/SendEmail.jtp?type=node&node=7599118&i=1>>: > > > > >> 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:///user/SendEmail.jtp?type=node&node=7599118&i=2> > > http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > [hidden email] <http:///user/SendEmail.jtp?type=node&node=7599118&i=3> > 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 > <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-tp7598932p7599132.html Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
