Received: by 10.68.230.98 with SMTP id sx2mr9774292pbc.1.1335723219364;
        Sun, 29 Apr 2012 11:13:39 -0700 (PDT)
X-BeenThere: 37signals-api@googlegroups.com
Received: by 10.68.195.100 with SMTP id id4ls8639539pbc.8.gmail; Sun, 29 Apr
 2012 11:13:38 -0700 (PDT)
Received: by 10.68.230.98 with SMTP id sx2mr9774287pbc.1.1335723218719;
        Sun, 29 Apr 2012 11:13:38 -0700 (PDT)
Received: by 10.68.230.98 with SMTP id sx2mr9774286pbc.1.1335723218707;
        Sun, 29 Apr 2012 11:13:38 -0700 (PDT)
Return-Path: <jer...@37signals.com>
Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53])
        by gmr-mx.google.com with ESMTPS id sg8si14200899pbc.0.2012.04.29.11.13.38
        (version=TLSv1/SSLv3 cipher=OTHER);
        Sun, 29 Apr 2012 11:13:38 -0700 (PDT)
Received-SPF: pass (google.com: domain of jer...@37signals.com designates 209.85.160.53 as permitted sender) client-ip=209.85.160.53;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jer...@37signals.com designates 209.85.160.53 as permitted sender) smtp.mail=jer...@37signals.com; dkim=pass header...@37signals.com
Received: by pbbrr4 with SMTP id rr4so3349593pbb.26
        for <37signals-api@googlegroups.com>; Sun, 29 Apr 2012 11:13:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=37signals.com; s=gapps;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        bh=h1Ksn/wz1vvkhALnP/RlDn4ZOL+WA8MYkbOG87KgTLE=;
        b=hNOLPpNeywKt7PePUCaBWceWTAvycVfriL97MjIj1gq1xnbrrGkl0C2RU63E88uXlL
         CLcI1iwAEsppobP32F3O9rRyj0EBctFdRJadOJJQBpceBCsLzlaJpPTrxIuHr6M1J6k1
         gdyokvSt6ZgFVMF9ufdVC+LEAwMajxl25YAzU=
        d=google.com; s=20120113;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding:x-gm-message-state;
        bh=h1Ksn/wz1vvkhALnP/RlDn4ZOL+WA8MYkbOG87KgTLE=;
        b=JrWECO51uP5p8SG4zMPQJKIkRpKWhlosPa39+dIobvdjAXjrFMof6pYM4ZRHbtIrPe
         sRlISfgoXYDuAXYVATkwv+Yto6+4lUzfUQE86jOkrQ93ygQ7OD8fPsKOEGT7BR2Z00dl
         mwRhEt/runYQTp203aQzIYhTa5gjDeFY4+17y3/+RGlhOadr5Lw4N/7l/xiYnfeq4AAn
         d+2R24eP1NiAVKU8a6l7CphVFYV/51+aXylYlJh33Jqdn8pHrvPjW22Q2VxSc3RlPkFs
         66osl8wA/VKpFb/sa6XIQxxM/zZYlpK1wq3NkC74pq3DpHS5PJYKOi38H3OQaw+NpNwQ
         PVUQ==
Received: by 10.68.129.130 with SMTP id nw2mr2369443pbb.133.1335723218336;
 Sun, 29 Apr 2012 11:13:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.31.229 with HTTP; Sun, 29 Apr 2012 11:13:18 -0700 (PDT)
In-Reply-To: <CBC1A21F.14FFF%ale...@yoxel.com>
References: <CAC2cyGJ86A3FnBN6ZLWDZ+F+LDo1ne9fkWb4tEoaq6wf0+q...@mail.gmail.com>
 <CBC1A21F.14FFF%ale...@yoxel.com>
From: Jeremy Kemper <jer...@37signals.com>
Date: Sun, 29 Apr 2012 11:13:18 -0700
Message-ID: <CAC2cyGJa0q7ARocWmR-dnmBq7uMqWN_5DQt730BMwhCUS4j...@mail.gmail.com>
Subject: Re: [37signals API] Introducing OAuth 2
To: 37signals-api@googlegroups.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkqvdI2Dy+KxCr++TLK7dhGUMZKZRulPZHlTnj3jsznB7M+obFL94NS6pAxE3uRnQ1eXKpJ

On Sat, Apr 28, 2012 at 1:33 PM, Alexey Panteleev <ale...@yoxel.com> wrote:
> Yep, just switched to OAuth2 for Highrise and BC Classic the other week,
> works fine! Just don't understand why the tokens have to be so long,
> sometimes >514bytes. Other services (i.e. Google, Evernote, Huddle, ... u=
se
> shorter strings)

It's an HMAC-signed token that contains the authorization info, so it
takes a fair bit of space.

Is it causing problems for your client?

> =C2=A0Now experimenting with the new API also. In the case when a person =
has
> multiple BC accounts (multiple 37signals ids), is there a way to ensure t=
hat
> he authorizes to the intended one? For example, for BC Classic before Oau=
th
> we still ask to specify the server name http://<company>.basecamphq.com a=
nd
> then after the Oauth we compare if the access was given to that exact
> server. I don't see a way to do something like that for the new basecamp.
> Any suggestions?

The common pattern is to reverse this flow: rather than ask for
http://<company>.basecamphq.com up front, authorize first, then fetch
the list of authorized accounts and ask this user which account to
connect to.

After you've authorized access, you can GET
https://launchpad.37signals.com/authorization.json for a list of all
accessible accounts.

This is more convenient for users -- one less thing to copy/paste --
and makes it easy for your app to support integration with multiple
accounts.

--
Jeremy Kemper
37signals