← 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.

Sandy

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


References