Re: [xwiki-devs] Questions, Gsoc2016, XWiki Android-authenticator

21 Apr 2016

On Thu, Apr 21, 2016 at 9:50 AM, fitz &lt;leefits(a)gmail.com&gt; wrote:
...
  Hi Thomas,

 2016-04-20 23:11 GMT+08:00 Thomas Mortagne [via XWiki] <
 ml-node+s475771n7599102h90(a)n2.nabble.com&gt;gt;:

  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/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
>>> < 
 >>> .
>>> NAML
>>> < 
http://xwiki.475771.n2.nabble.com/template/NamlServlet.jtp?macro=macro_view…

 >>>
>>
>>
>>
>>
>> --
>> View this message in context: 
http://xwiki.475771.n2.nabble.com/Questions-Gsoc2016-XWiki-Android-authenti…
  > 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-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>

 --
 View this message in context:
http://xwiki.475771.n2.nabble.com/Questions-Gsoc2016-XWiki-Android-authenti…
 Sent from the XWiki- Dev mailing list archive at Nabble.com.
 _______________________________________________
 devs mailing list
 devs(a)xwiki.org
 http://lists.xwiki.org/mailman/listinfo/devs 

-- 
Thomas Mortagne

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Re: [xwiki-devs] Questions, Gsoc2016, XWiki Android-authenticator