← Back to team overview

tomdroid-dev team mailing list archive

Re: Web sync branch hurdles


I forgot to mention that I also made a few changes to make sure the
oauth_verifier parameter from the U1 server was used when obtaining
the access token, and I double-checked that this was done correctly.

For clarity's sake, I'm attaching a patch of my current progress.  Of
course, it does not include the updated signpost jar files, but you
can see the change in .classpath.


On Sun, Nov 8, 2009 at 2:40 PM, Sandy Armstrong
<sanfordarmstrong@xxxxxxxxx> wrote:
> On Sun, Nov 8, 2009 at 1:58 PM, Sandy Armstrong
> <sanfordarmstrong@xxxxxxxxx> wrote:
>> Hi Folks,
>> I finally got an Android environment set up (sadly, Eclipse just
>> failed totally in openSUSE, so I'm using my Mac for Android stuff).  I
>> pulled Benoit's web sync branch and decided to play around and see if
>> I could get it to work with Ubuntu One.  The first thing I did was to
>> change the default sync backend pref from "sdcard" to "snowy", because
>> without a tomdroid directory on the SD card I was getting exceptions
>> on startup.  Then I replaced the signpost jar files with the latest
>> 1.1 jar files I could find, since supposedly they contain OAuth 1.0a
>> support.  The last thing I did was to change the oauth consumer pair
>> constants from "tomdroid"/"tomdroid" to "anyone"/"anyone".
>> With these changes I was able to get pretty far in the authentication
>> process, but not far enough.  When the callback URL (tomdroid://sync)
>> was called by the browser, it seemed like a new Tomdroid instance came
>> up (or at least, the welcome message was shown again), and then
>> nothing happened.  At this point I'm kind of out of time to keep
>> digging in today, but really I'm just not sure what the expected
>> behavior is when running Tomdroid from the web sync branch, in the
>> emulator, starting with an empty SD card.
> Okay, I couldn't resist looking a bit more into this once I realized
> that Tomdroid *was* probably handing the tomdroid://sync URL, even
> though the auth process still failed.  When asked to convert the
> request token into an access token, U1's response does not contain a
> copy of the access token.  If I ignore this error and assume that
> access really was granted and that it's just a mistake in the server
> response, note sync still ends up failing with a 404 when attempting
> to access U1's URL for the user resource.  So either auth really
> didn't complete successfully, or something else is going wrong.
> I'll report more as I continue digging.
> Sandy

Attachment: u1.diff
Description: Binary data