IETF Logo Mail Archive

Re: [OAUTH-WG] Issue: state in web server flow

Marius Scurtescu <mscurtescu@google.com> Mon, 19 April 2010 20:59 UTC

Return-Path: <mscurtescu@google.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE3573A6926 for <oauth@core3.amsl.com>; Mon, 19 Apr 2010 13:59:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.778
X-Spam-Level:
X-Spam-Status: No, score=-101.778 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9qgvZSLbeed for <oauth@core3.amsl.com>; Mon, 19 Apr 2010 13:59:02 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 0701E3A6959 for <oauth@ietf.org>; Mon, 19 Apr 2010 13:58:57 -0700 (PDT)
Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [10.3.21.14]) by smtp-out.google.com with ESMTP id o3JKwlkw003466 for <oauth@ietf.org>; Mon, 19 Apr 2010 22:58:48 +0200
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1271710728; bh=qq/X3QfH6rzftMh9PoXFKas9D+8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=cDyJ/3Oi+MkEv9hMXSfdMO0GAgO4BuLtWCHHg9ZiPHmZZMVd7veD2KtgDzz1J8/nD Y19RWDYBsVPy+rXGED/4w==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=UkFN5PcOmTpEt6XKmgYvqlRckTZZOWdQ+oO4P3svggvC0DRPkOLyjJvK2Mu58uF4H HCMQDsPFz1RnS9yiU7FLg==
Received: from pvg11 (pvg11.prod.google.com [10.241.210.139]) by hpaq14.eem.corp.google.com with ESMTP id o3JKwjFN016661 for <oauth@ietf.org>; Mon, 19 Apr 2010 22:58:46 +0200
Received: by pvg11 with SMTP id 11so4351247pvg.0 for <oauth@ietf.org>; Mon, 19 Apr 2010 13:58:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.141.107.2 with HTTP; Mon, 19 Apr 2010 13:58:25 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723438E5C7F1BF@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <1E39CE38-763E-4E3D-96D4-DC757BD53B9D@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723438E30A379E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4776FFF7-45E6-4945-9548-382A9DB84A95@gmail.com> <r2v74caaad21004191017id7c48d54lc5ced6e9e164591e@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723438E5C7F1BF@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: Marius Scurtescu <mscurtescu@google.com>
Date: Mon, 19 Apr 2010 13:58:25 -0700
Received: by 10.141.187.9 with SMTP id o9mr4865740rvp.211.1271710725284; Mon, 19 Apr 2010 13:58:45 -0700 (PDT)
Message-ID: <t2s74caaad21004191358h3527f320u61c6a958cda1d652@mail.gmail.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Content-Type: text/plain; charset="ISO-8859-1"
X-System-Of-Record: true
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Issue: state in web server flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Apr 2010 20:59:03 -0000

On Mon, Apr 19, 2010 at 11:53 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
>
>
>> -----Original Message-----
>> From: Marius Scurtescu [mailto:mscurtescu@google.com]
>> Sent: Monday, April 19, 2010 10:18 AM
>
>> I don't think it is possible to enforce callbacks without any query parameters.
>> See the Drupal example.
>
> In the Drupal example the client server adds its silly parameters internally. They are not included in what the client provides as its callback URI.

Silly?

The query parameter may or may not be visible in the registered callback.


> Can you give an actual callback URI example?

http://example.com/oauth2/callback
equivalent with:
http://example.com/index.php?q=oauth2/callback


> Also, if the client requires query parameters in its callback, it just means it cannot use the client state OAuth parameter.

Sure it can, perfectly valid to redirect to:
http://example.com/oauth2/callback?code=123&state=qwerty
which is the same as:
http://example.com/index.php?q=oauth2/callback&code=123&state=qwerty


Justin Richer pointed out that MediaWiki has an identical issue. My
guess is that most PHP frameworks will have this problem.


Marius

v2.23.0 | Report a Bug | By Email