code review 6452058: goauth2: adding a jwt package to support server to serv...

goauth2: adding a jwt package to support server to server applications.

The jwt package allows the user to define a jwt.Token containing the
required and optional fields for constructing the serialized and encoded
JWT to be used for requesting an access_token.  Integrating this package
into oauth/oauth.go will require some redesign of the parent package.
These changes have been postponed for a later CL.

The descriptions of the standards this change implements can be found on
the following web page.

https://developers.google.com/accounts/docs/OAuth2ServiceAccount

This addition to the library will allow for example a GAE instance to
make requests to service like BigQuery.

[gavaletz_google, 2012-07-27 21:05:56]

Hello adg@google.com (cc: bradfitz@google.com, golang-dev@googlegroups.com,
jcgregorio@google.com, tiziana@google.com),

I'd like you to review this change to
https://code.google.com/p/goauth2/

[adg, 2012-07-30 09:24:26]

I am still thinking about how to integrate. I think this approach is wrong.

One thing we don't want to lose is the ability to refresh the token. That
transparent refresh is one of the only things that the oauth package buys us -
otherwise we might as well just write a separate jwt package.

Maybe there's an argument for a 

type TokenUpdater interface {
    UpdateToken(*Token, v url.Values) error
}

And then we can have a TokenUpdater field in oauth.Config, which, if nil, uses
the default implementaiton. Then our jwt.Token can implement UpdateToken.

How does that feel to you?

http://codereview.appspot.com/6452058/diff/1001/oauth/jwt/jwt.go
File oauth/jwt/jwt.go (right):

http://codereview.appspot.com/6452058/diff/1001/oauth/jwt/jwt.go#newcode8
oauth/jwt/jwt.go:8: "../../oauth"
code.google.com/p/goauth2/oauth

[gavaletz_google, 2012-07-30 16:00:20]

I just need to know that we are all on the same page, and that I am reading
the documentation the same way everyone else is.

When you say "this approach" are you referring to the way that things are
implemented now, or the way I suggested in our original thread (copied here
for clarity).  This proposal does not lose the ability to refresh the token
for the client login, but since there is no refresh support for service
accounts it makes sense to just alias it to re-encode and sign a new JWT
and use it to request a new access token.

I think that this
post<http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/>by
one of the oauth2.0 specification authors brings important context to
this discussion.  In particular It seems that the specification has so
much extensibility and flexibility that pretty much anything goes (and it
shows).  The fact that there are many different ways to authenticate (and
that they are covered under the OAuth 2.0 umbrella) does not mean that they
operate the same.

Oauth 2.0 user login and service accounts are very different, but should be
included in the same package as long as we pretend that this is one
specification - protocol sic.

BEGIN
PASTE============================================================================

I have implemented what we talked about (CL 6452058), but I think that
after looking at it with fresh eyes that something is off.

The first thing is that the oauth.Config is an Assertion of sorts and it
feels weird to be using it this way.  For instance there is nothing used
from the oauth.Config in the

func (*Config) Assert(Assertion) (*Token, error)

function.  What I see the practical interface for the Assertions being is
something like this:

type Assertion interface {
        BuildRequest() (*http.Request, error)
        BuildRefreshRequest() (*http.Request, error) // In the case of JWT
this would alias BuildRequest.
        HandleResponse(*http.Response) (*Token, error)
}

Then we could have:

type Transport struct {

        *Assertion
        *Token
        Transport http.RoundTripper
}

Where Config implements the Assertion interface.  The interface we talked
about last night means that the Assert function could get complicated and
need to handle funky corner cases (the Oauth2 site lists 6 different cases
for authentication!).

Withing Transport we could have something as simple as:

func (t *Transport) Exchange() error {

        req, err := t.Assertion.BuildRequest()

        if err != nil {

                return err

        }

        c := &http.Client{}

        resp, err := c.Do(req)

        if err != nil {

                return err

        }

        t.Token, err = t.Assertion.HandleResponse(resp)

        return err
}

// The refresh function would be almost the same except it would use a
BuildRefreshRequest.

t := &Transport{
        Assertion: jwt, // Or a config
}

err := t.Exchange()
...
err := t.Refresh()

END
PASTE==============================================================================


On Mon, Jul 30, 2012 at 2:24 AM, <adg@golang.org> wrote:

> I am still thinking about how to integrate. I think this approach is
> wrong.
>
> One thing we don't want to lose is the ability to refresh the token.
> That transparent refresh is one of the only things that the oauth
> package buys us - otherwise we might as well just write a separate jwt
> package.
>
> Maybe there's an argument for a
>
> type TokenUpdater interface {
>     UpdateToken(*Token, v url.Values) error
> }
>
> And then we can have a TokenUpdater field in oauth.Config, which, if
> nil, uses the default implementaiton. Then our jwt.Token can implement
> UpdateToken.
>
> How does that feel to you?
>
>
>
http://codereview.appspot.com/**6452058/diff/1001/oauth/jwt/**jwt.go<http://c...
> File oauth/jwt/jwt.go (right):
>
> http://codereview.appspot.com/**6452058/diff/1001/oauth/jwt/**
>
jwt.go#newcode8<http://codereview.appspot.com/6452058/diff/1001/oauth/jwt/jwt.go#newcode8>
> oauth/jwt/jwt.go:8: "../../oauth"
> code.google.com/p/goauth2/**oauth <http://code.google.com/p/goauth2/oauth>
>
>
http://codereview.appspot.com/**6452058/<http://codereview.appspot.com/6452058/>
>

[jcgregorio_google, 2012-07-30 16:50:05]

On Mon, Jul 30, 2012 at 11:59 AM, Eric Gavaletz <gavaletz@google.com> wrote:
> I just need to know that we are all on the same page, and that I am reading
> the documentation the same way everyone else is.
>
> When you say "this approach" are you referring to the way that things are
> implemented now, or the way I suggested in our original thread (copied here
> for clarity).  This proposal does not lose the ability to refresh the token
> for the client login, but since there is no refresh support for service
> accounts it makes sense to just alias it to re-encode and sign a new JWT and
> use it to request a new access token.

In the Python client library I broke apart things into Flows and
Credentials. The Credentials
are what does the auth, and the Flows represent the oauth dance you
have to go through
to get a Credential. Usually you go through the dance to get a
Credentials, but there
are cases, like the SignedJwtAssertionCredentials, where you can just
construct one and use it
directly. See this page for more details:

  https://developers.google.com/api-client-library/python/guide/aaa_oauth

I think this would map to goauth as Transport taking in a Credentials
object, Credentials objects
that know how to refresh themselves, and many of the operations on
Transport being moved
into a Flow object, but I'm not sure how idiomatic that is in Go.

>
> I think that this post by one of the oauth2.0 specification authors brings
> important context to this discussion.  In particular It seems that the
> specification has so much extensibility and flexibility that pretty much
> anything goes (and it shows).  The fact that there are many different ways
> to authenticate (and that they are covered under the OAuth 2.0 umbrella)
> does not mean that they operate the same.

I don't quite agree with Eran's position, here's my public thoughts on
the subject:

  https://plus.google.com/u/0/118148240205592032989/posts/Qudedrg7JqJ

  -joe


>
> Oauth 2.0 user login and service accounts are very different, but should be
> included in the same package as long as we pretend that this is one
> specification - protocol sic.
>
> BEGIN
>
PASTE============================================================================
>
> I have implemented what we talked about (CL 6452058), but I think that after
> looking at it with fresh eyes that something is off.
>
> The first thing is that the oauth.Config is an Assertion of sorts and it
> feels weird to be using it this way.  For instance there is nothing used
> from the oauth.Config in the
>
> func (*Config) Assert(Assertion) (*Token, error)
>
> function.  What I see the practical interface for the Assertions being is
> something like this:
>
> type Assertion interface {
>         BuildRequest() (*http.Request, error)
>         BuildRefreshRequest() (*http.Request, error) // In the case of JWT
> this would alias BuildRequest.
>         HandleResponse(*http.Response) (*Token, error)
> }
>
> Then we could have:
>
> type Transport struct {
>         *Assertion
>         *Token
>         Transport http.RoundTripper
> }
>
> Where Config implements the Assertion interface.  The interface we talked
> about last night means that the Assert function could get complicated and
> need to handle funky corner cases (the Oauth2 site lists 6 different cases
> for authentication!).
>
> Withing Transport we could have something as simple as:
>
> func (t *Transport) Exchange() error {
>         req, err := t.Assertion.BuildRequest()
>         if err != nil {
>                 return err
>         }
>         c := &http.Client{}
>         resp, err := c.Do(req)
>         if err != nil {
>                 return err
>         }
>         t.Token, err = t.Assertion.HandleResponse(resp)
>         return err
> }
>
> // The refresh function would be almost the same except it would use a
> BuildRefreshRequest.
>
> t := &Transport{
>         Assertion: jwt, // Or a config
> }
>
> err := t.Exchange()
> ...
> err := t.Refresh()
>
> END
>
PASTE==============================================================================
>
>
> On Mon, Jul 30, 2012 at 2:24 AM, <adg@golang.org> wrote:
>>
>> I am still thinking about how to integrate. I think this approach is
>> wrong.
>>
>> One thing we don't want to lose is the ability to refresh the token.
>> That transparent refresh is one of the only things that the oauth
>> package buys us - otherwise we might as well just write a separate jwt
>> package.
>>
>> Maybe there's an argument for a
>>
>> type TokenUpdater interface {
>>     UpdateToken(*Token, v url.Values) error
>> }
>>
>> And then we can have a TokenUpdater field in oauth.Config, which, if
>> nil, uses the default implementaiton. Then our jwt.Token can implement
>> UpdateToken.
>>
>> How does that feel to you?
>>
>>
>> http://codereview.appspot.com/6452058/diff/1001/oauth/jwt/jwt.go
>> File oauth/jwt/jwt.go (right):
>>
>> http://codereview.appspot.com/6452058/diff/1001/oauth/jwt/jwt.go#newcode8
>> oauth/jwt/jwt.go:8: "../../oauth"
>> code.google.com/p/goauth2/oauth
>>
>> http://codereview.appspot.com/6452058/
>
>

[gavaletz_google, 2012-07-30 17:45:29]

Borrowing from your public thoughts on the subject:

"Breaking the protocol apart into separate flows for different situations
allows each of those flows to be easier to understand and implement
correctly."

When Andrew and I were first discussing how integrate JWT into the existing
library, the idea of adding another level of abstraction didn't sound  good
to Andrew.  Being very new to Go I was easily convinced, but now I am not
so sure.  To borrow Joe's analogy of a dance, it isn't just enough to do
the same dance (flow) with a different partner (authorization code/JWT),
but based on the type of credentials you have (and the desired result)
there is a different dance altogether.

Also taking from the Google
documentation<https://developers.google.com/accounts/docs/OAuth2Login>
:

"Given the security implications of getting the implementation correct, we *
strongly* encourage developers to use OAuth 2.0 libraries when interacting
with Google's OAuth 2.0 endpoints (see Client
libraries<https://developers.google.com/accounts/docs/OAuth2#libraries>
for
more information). "

I think that given the complexity and the various dances based on input
that we should make this easier on the developer depending on the library.
 I think having a Credentials->(OpenIdConnectConfig/JWT) that is used by a
Transport to initiate/refresh an authenticated connection seems like the
way to go.  This level of abstraction will probably be useful in the future
as this specification is a moving target and again according to the
Google documentation "these Google endpoints will update as the
specification matures."

With that in mind the interface for the Assertion (Credentials in Joe's
response) may still not be generic enough to handle the various dances that
oauth requires (or will require).

type Assertion interface {
        BuildRequest() (*http.Request, error)
        BuildRefreshRequest() (*http.Request, error) // In the case of JWT
this would alias BuildRequest.
        HandleResponse(*http.Response) (*Token, error)
}

This case does not handle the SignedJwtAssertionCredentials type flow/dance
and would mean that we would again have to take on this pain again in the
future.

~Eric


On Mon, Jul 30, 2012 at 9:50 AM, Joe Gregorio <jcgregorio@google.com> wrote:

> On Mon, Jul 30, 2012 at 11:59 AM, Eric Gavaletz <gavaletz@google.com>
> wrote:
> > I just need to know that we are all on the same page, and that I am
> reading
> > the documentation the same way everyone else is.
> >
> > When you say "this approach" are you referring to the way that things are
> > implemented now, or the way I suggested in our original thread (copied
> here
> > for clarity).  This proposal does not lose the ability to refresh the
> token
> > for the client login, but since there is no refresh support for service
> > accounts it makes sense to just alias it to re-encode and sign a new JWT
> and
> > use it to request a new access token.
>
> In the Python client library I broke apart things into Flows and
> Credentials. The Credentials
> are what does the auth, and the Flows represent the oauth dance you
> have to go through
> to get a Credential. Usually you go through the dance to get a
> Credentials, but there
> are cases, like the SignedJwtAssertionCredentials, where you can just
> construct one and use it
> directly. See this page for more details:
>
>   https://developers.google.com/api-client-library/python/guide/aaa_oauth
>
> I think this would map to goauth as Transport taking in a Credentials
> object, Credentials objects
> that know how to refresh themselves, and many of the operations on
> Transport being moved
> into a Flow object, but I'm not sure how idiomatic that is in Go.
>
> >
> > I think that this post by one of the oauth2.0 specification authors
> brings
> > important context to this discussion.  In particular It seems that the
> > specification has so much extensibility and flexibility that pretty much
> > anything goes (and it shows).  The fact that there are many different
> ways
> > to authenticate (and that they are covered under the OAuth 2.0 umbrella)
> > does not mean that they operate the same.
>
> I don't quite agree with Eran's position, here's my public thoughts on
> the subject:
>
>   https://plus.google.com/u/0/118148240205592032989/posts/Qudedrg7JqJ
>
>   -joe
>
>
> >
> > Oauth 2.0 user login and service accounts are very different, but should
> be
> > included in the same package as long as we pretend that this is one
> > specification - protocol sic.
> >
> > BEGIN
> >
>
PASTE============================================================================
> >
> > I have implemented what we talked about (CL 6452058), but I think that
> after
> > looking at it with fresh eyes that something is off.
> >
> > The first thing is that the oauth.Config is an Assertion of sorts and it
> > feels weird to be using it this way.  For instance there is nothing used
> > from the oauth.Config in the
> >
> > func (*Config) Assert(Assertion) (*Token, error)
> >
> > function.  What I see the practical interface for the Assertions being is
> > something like this:
> >
> > type Assertion interface {
> >         BuildRequest() (*http.Request, error)
> >         BuildRefreshRequest() (*http.Request, error) // In the case of
> JWT
> > this would alias BuildRequest.
> >         HandleResponse(*http.Response) (*Token, error)
> > }
> >
> > Then we could have:
> >
> > type Transport struct {
> >         *Assertion
> >         *Token
> >         Transport http.RoundTripper
> > }
> >
> > Where Config implements the Assertion interface.  The interface we talked
> > about last night means that the Assert function could get complicated and
> > need to handle funky corner cases (the Oauth2 site lists 6 different
> cases
> > for authentication!).
> >
> > Withing Transport we could have something as simple as:
> >
> > func (t *Transport) Exchange() error {
> >         req, err := t.Assertion.BuildRequest()
> >         if err != nil {
> >                 return err
> >         }
> >         c := &http.Client{}
> >         resp, err := c.Do(req)
> >         if err != nil {
> >                 return err
> >         }
> >         t.Token, err = t.Assertion.HandleResponse(resp)
> >         return err
> > }
> >
> > // The refresh function would be almost the same except it would use a
> > BuildRefreshRequest.
> >
> > t := &Transport{
> >         Assertion: jwt, // Or a config
> > }
> >
> > err := t.Exchange()
> > ...
> > err := t.Refresh()
> >
> > END
> >
>
PASTE==============================================================================
> >
> >
> > On Mon, Jul 30, 2012 at 2:24 AM, <adg@golang.org> wrote:
> >>
> >> I am still thinking about how to integrate. I think this approach is
> >> wrong.
> >>
> >> One thing we don't want to lose is the ability to refresh the token.
> >> That transparent refresh is one of the only things that the oauth
> >> package buys us - otherwise we might as well just write a separate jwt
> >> package.
> >>
> >> Maybe there's an argument for a
> >>
> >> type TokenUpdater interface {
> >>     UpdateToken(*Token, v url.Values) error
> >> }
> >>
> >> And then we can have a TokenUpdater field in oauth.Config, which, if
> >> nil, uses the default implementaiton. Then our jwt.Token can implement
> >> UpdateToken.
> >>
> >> How does that feel to you?
> >>
> >>
> >> http://codereview.appspot.com/6452058/diff/1001/oauth/jwt/jwt.go
> >> File oauth/jwt/jwt.go (right):
> >>
> >>
> http://codereview.appspot.com/6452058/diff/1001/oauth/jwt/jwt.go#newcode8
> >> oauth/jwt/jwt.go:8: "../../oauth"
> >> code.google.com/p/goauth2/oauth
> >>
> >> http://codereview.appspot.com/6452058/
> >
> >
>

[adg1, 2012-08-01 07:43:17]

In its current state, we might as well put a function in the jwt
package that returns an *oauth.Token and leave the oauth package
alone.

I think that's probably the only reasonable way to proceed without
redesigning the oauth package, which is something I'd like to do but
not now.

Please do that. More review comments to follow.

Andrew

[adg, 2012-08-01 07:45:19]

http://codereview.appspot.com/6452058/diff/1001/oauth/jwt/jwt.go
File oauth/jwt/jwt.go (right):

http://codereview.appspot.com/6452058/diff/1001/oauth/jwt/jwt.go#newcode48
oauth/jwt/jwt.go:48: type Segment interface {
This doesn't seem to be used anywhere.

http://codereview.appspot.com/6452058/diff/1001/oauth/jwt/jwt.go#newcode161
oauth/jwt/jwt.go:161: func (t *Token) Assertion() (string, error) {
make this Encode, as it was before

http://codereview.appspot.com/6452058/diff/1001/oauth/jwt/jwt.go#newcode225
oauth/jwt/jwt.go:225: func (t *Token) BuildRequest() (*http.Request, error) {
Let's combine this with HandleResponse and rename it to 

func (*Token) Assert() (*oauth.Token, error)

[gavaletz_google, 2012-08-01 18:54:04]

Responding to feedback.

http://codereview.appspot.com/6452058/diff/1001/oauth/jwt/jwt.go
File oauth/jwt/jwt.go (right):

http://codereview.appspot.com/6452058/diff/1001/oauth/jwt/jwt.go#newcode8
oauth/jwt/jwt.go:8: "../../oauth"
On 2012/07/30 09:24:26, adg wrote:
> code.google.com/p/goauth2/oauth

This change has been made; however, I am having trouble getting my tests to run
now.  To begin working on the project I checked out the code with "hg clone
https://code.google.com/p/goauth2/", but should I have used "go get
code.google.com/p/goauth2/oauth"?  Would that have given me a fully functional
hg client?

http://codereview.appspot.com/6452058/diff/1001/oauth/jwt/jwt.go#newcode48
oauth/jwt/jwt.go:48: type Segment interface {
On 2012/08/01 07:45:19, adg wrote:
> This doesn't seem to be used anywhere.

Removed.

http://codereview.appspot.com/6452058/diff/1001/oauth/jwt/jwt.go#newcode161
oauth/jwt/jwt.go:161: func (t *Token) Assertion() (string, error) {
On 2012/08/01 07:45:19, adg wrote:
> make this Encode, as it was before

Done.

http://codereview.appspot.com/6452058/diff/1001/oauth/jwt/jwt.go#newcode225
oauth/jwt/jwt.go:225: func (t *Token) BuildRequest() (*http.Request, error) {
On 2012/08/01 07:45:19, adg wrote:
> Let's combine this with HandleResponse and rename it to 
> 
> func (*Token) Assert() (*oauth.Token, error)

I left these two functions in place and moved the Assert function that was in
oauth/oauth.go here (with a few edits).

http://codereview.appspot.com/6452058/diff/1001/oauth/oauth.go
File oauth/oauth.go (right):

http://codereview.appspot.com/6452058/diff/1001/oauth/oauth.go#newcode82
oauth/oauth.go:82: type Assertion interface {
Removed for now.

http://codereview.appspot.com/6452058/diff/1001/oauth/oauth.go#newcode102
oauth/oauth.go:102: func (c *Config) Assert(a Assertion) (*Token, error) {
Moved to oauth/jwt/jwt.go as:
func (t *Token) Assert() (*oauth.Token, error)

[gavaletz_google, 2012-08-01 19:00:09]

Hello adg@google.com, adg@golang.org (cc: bradfitz@google.com,
golang-dev@googlegroups.com, jcgregorio@google.com, tiziana@google.com),

Please take another look.

[jcgregorio_google, 2012-08-02 18:41:22]

http://codereview.appspot.com/6452058/diff/7004/oauth/jwt/jwt.go
File oauth/jwt/jwt.go (right):

http://codereview.appspot.com/6452058/diff/7004/oauth/jwt/jwt.go#newcode100
oauth/jwt/jwt.go:100: // one hour from then (or the time in the request)?
The exp time is the time that this assertion will expire. It has no bearing on
the lifetime of the access_token you receive.

Yes, you could encode an assertion and sit on it and then send it to the server,
as long as you send it before the 'exp' time is reached it will still work.

[gavaletz_google, 2012-08-02 19:09:37]

http://codereview.appspot.com/6452058/diff/7004/oauth/jwt/jwt.go
File oauth/jwt/jwt.go (right):

http://codereview.appspot.com/6452058/diff/7004/oauth/jwt/jwt.go#newcode100
oauth/jwt/jwt.go:100: // one hour from then (or the time in the request)?
On 2012/08/02 18:41:22, jcgregorio_google wrote:
> The exp time is the time that this assertion will expire. It has no bearing on
> the lifetime of the access_token you receive.
> 
> Yes, you could encode an assertion and sit on it and then send it to the
server,
> as long as you send it before the 'exp' time is reached it will still work.

Ok, so that means that the encoded JWT can be used to request an access_token
for up to one hour from the time it was encoded.  If the access_token were to
expire before the expiration of the JWT then we could use the same JWT to
request a fresh access_token.  That said, since the access_token expires in an
hour it effectively makes the encoded JWT disposable.

Unless there is a common circumstance where a access_token would expire in less
than an hour I don't think it makes sense to try to re-use a JWT for a corner
case.

Do you agree?

[jcgregorio_google, 2012-08-02 19:20:58]

http://codereview.appspot.com/6452058/diff/7004/oauth/jwt/jwt.go
File oauth/jwt/jwt.go (right):

http://codereview.appspot.com/6452058/diff/7004/oauth/jwt/jwt.go#newcode100
oauth/jwt/jwt.go:100: // one hour from then (or the time in the request)?
Agreed, do not try to reuse a JWT.

On 2012/08/02 19:09:37, gavaletz_google wrote:
> On 2012/08/02 18:41:22, jcgregorio_google wrote:
> > The exp time is the time that this assertion will expire. It has no bearing
on
> > the lifetime of the access_token you receive.
> > 
> > Yes, you could encode an assertion and sit on it and then send it to the
> server,
> > as long as you send it before the 'exp' time is reached it will still work.
> 
> Ok, so that means that the encoded JWT can be used to request an access_token
> for up to one hour from the time it was encoded.  If the access_token were to
> expire before the expiration of the JWT then we could use the same JWT to
> request a fresh access_token.  That said, since the access_token expires in an
> hour it effectively makes the encoded JWT disposable.
> 
> Unless there is a common circumstance where a access_token would expire in
less
> than an hour I don't think it makes sense to try to re-use a JWT for a corner
> case.
> 
> Do you agree?
>

[gavaletz_google, 2012-08-02 19:44:36]

Hello adg@google.com, adg@golang.org, jcgregorio@google.com (cc:
bradfitz@google.com, golang-dev@googlegroups.com, tiziana@google.com),

Please take another look.

[gavaletz_google, 2012-08-02 19:45:36]

http://codereview.appspot.com/6452058/diff/7004/oauth/jwt/jwt.go
File oauth/jwt/jwt.go (right):

http://codereview.appspot.com/6452058/diff/7004/oauth/jwt/jwt.go#newcode100
oauth/jwt/jwt.go:100: // one hour from then (or the time in the request)?
On 2012/08/02 19:20:59, jcgregorio_google wrote:
> Agreed, do not try to reuse a JWT.
> 
> On 2012/08/02 19:09:37, gavaletz_google wrote:
> > On 2012/08/02 18:41:22, jcgregorio_google wrote:
> > > The exp time is the time that this assertion will expire. It has no
bearing
> on
> > > the lifetime of the access_token you receive.
> > > 
> > > Yes, you could encode an assertion and sit on it and then send it to the
> > server,
> > > as long as you send it before the 'exp' time is reached it will still
work.
> > 
> > Ok, so that means that the encoded JWT can be used to request an
access_token
> > for up to one hour from the time it was encoded.  If the access_token were
to
> > expire before the expiration of the JWT then we could use the same JWT to
> > request a fresh access_token.  That said, since the access_token expires in
an
> > hour it effectively makes the encoded JWT disposable.
> > 
> > Unless there is a common circumstance where a access_token would expire in
> less
> > than an hour I don't think it makes sense to try to re-use a JWT for a
corner
> > case.
> > 
> > Do you agree?
> > 
> 

Commentary updated to reflect this new understanding.

[adg, 2012-08-06 02:01:03]

http://codereview.appspot.com/6452058/diff/7005/oauth/jwt/jwt.go
File oauth/jwt/jwt.go (right):

http://codereview.appspot.com/6452058/diff/7005/oauth/jwt/jwt.go#newcode35
oauth/jwt/jwt.go:35: StdAlgorithm     = "RS256"
these should be unexported

http://codereview.appspot.com/6452058/diff/7005/oauth/jwt/jwt.go#newcode42
oauth/jwt/jwt.go:42: ErrInvKey = errors.New("Invalid Key")
ErrInvalidKey

http://codereview.appspot.com/6452058/diff/7005/oauth/jwt/jwt.go#newcode63
oauth/jwt/jwt.go:63: type Header struct {
I'm not sure we should expose this or Signature. The user just constructs the
ClaimSet, right, and the rest is all derived from that?

http://codereview.appspot.com/6452058/diff/7005/oauth/jwt/jwt.go#newcode229
oauth/jwt/jwt.go:229: // Assert returns an *oauth.Token that can be used to make
future requests.  The
Say what it does. It's obvious that it returns an *oauth.Token. Say that it gets
a token by exchanging these credentials.

http://codereview.appspot.com/6452058/diff/7005/oauth/jwt/jwt.go#newcode252
oauth/jwt/jwt.go:252: // Most users should simply use the Assert method.
I would prefer to expose as little as possible in the public API. This makes it
easier for us to make changes later on. Let's hide this and the HandleResponse
method, for now.

[gavaletz_google, 2012-08-06 16:30:52]

Sending update to CL 6452058.

http://codereview.appspot.com/6452058/diff/7005/oauth/jwt/jwt.go
File oauth/jwt/jwt.go (right):

http://codereview.appspot.com/6452058/diff/7005/oauth/jwt/jwt.go#newcode35
oauth/jwt/jwt.go:35: StdAlgorithm     = "RS256"
On 2012/08/06 02:01:03, adg wrote:
> these should be unexported

Done.

http://codereview.appspot.com/6452058/diff/7005/oauth/jwt/jwt.go#newcode42
oauth/jwt/jwt.go:42: ErrInvKey = errors.New("Invalid Key")
On 2012/08/06 02:01:03, adg wrote:
> ErrInvalidKey

Done.

http://codereview.appspot.com/6452058/diff/7005/oauth/jwt/jwt.go#newcode63
oauth/jwt/jwt.go:63: type Header struct {
On 2012/08/06 02:01:03, adg wrote:
> I'm not sure we should expose this or Signature. The user just constructs the
> ClaimSet, right, and the rest is all derived from that?
To make this work with Google's servers all you would need to fill in is the
claim set.  That said even if someone put the necessary values in here to
satisfy another server's requirements, it would not change the fact that the
signature methods would continue to use RS256.  So I agree that we could hide
everything but the claim set for now and always use the StdHeader.

If that is the case you could simply have the encoded form of the header stored
as a constant sting (see const HeaderEnc in jwt_test.go).

Since this would be a significant change I will wait for your response to this
comment before making that update.  See more comments on line 139.

http://codereview.appspot.com/6452058/diff/7005/oauth/jwt/jwt.go#newcode139
oauth/jwt/jwt.go:139: type Token struct {
If we want hide things and making this library so that it only works with Google
servers, then we could reduce this down to a union of the ClaimSet and the Key
(call it a Config) and just have the 

func (c *Config) Assert() (*oauth.Token, error) 

function.

http://codereview.appspot.com/6452058/diff/7005/oauth/jwt/jwt.go#newcode229
oauth/jwt/jwt.go:229: // Assert returns an *oauth.Token that can be used to make
future requests.  The
On 2012/08/06 02:01:03, adg wrote:
> Say what it does. It's obvious that it returns an *oauth.Token. Say that it
gets
> a token by exchanging these credentials.

PTAL

http://codereview.appspot.com/6452058/diff/7005/oauth/jwt/jwt.go#newcode252
oauth/jwt/jwt.go:252: // Most users should simply use the Assert method.
On 2012/08/06 02:01:03, adg wrote:
> I would prefer to expose as little as possible in the public API. This makes
it
> easier for us to make changes later on. Let's hide this and the HandleResponse
> method, for now.

Done.

[gavaletz_google, 2012-08-06 16:32:51]

Hello adg@google.com, adg@golang.org, jcgregorio@google.com (cc:
bradfitz@google.com, golang-dev@googlegroups.com, tiziana@google.com),

Please take another look.

[gavaletz_google, 2012-08-06 17:44:47]

Possible issue making use of the .p12 file that Google API console gives us when
we expected a un-encrypted .pem file.

http://codereview.appspot.com/6452058/diff/11001/oauth/jwt/jwt.go
File oauth/jwt/jwt.go (right):

http://codereview.appspot.com/6452058/diff/11001/oauth/jwt/jwt.go#newcode142
oauth/jwt/jwt.go:142: Key       []byte
Due to an upcoming deadline I had to give an "advanced copy" of this to my GSoC
student to get started.  He did run into a problem with the type of key that the
API console gave him.  The key is encrypted using the "notasecret" password, and
to get a pem file I used openssl like this:

openssl pkcs12 -in <privatekey.p12> -nocerts -passin pass:notasecret -nodes -out
<privatekey.pem>

Obviously we would like to be able to use the key provided by Google directly. 
The answer in the pyhton lib can be found in the oauth2client/crypt.py file on
line 124:

pkey = crypto.load_pkcs12(key, password).get_privatekey()

Where crypto comes from OpenSSL.  I looked but did not find a way to do this
using a std go pkg.  Do you know of a way to avoid putting this in the comments?

[adg, 2012-08-08 00:43:15]

Am I still waiting on an additional change from you?

[gavaletz_google, 2012-08-08 00:50:36]

Yes, and given the feedback that Joe has gotten on the issue with the .p12
file I think I am going to have to include commentary about unpacking the
key using openssl.  My GSoC student also highlighted that there was an
issue with having an assert method that makes use of the default http
client.  When running on GAE we need to be able to use the url fetch.  So I
am going to have to take another look at that too.

For something that should have been a simple fix it is taking a lot of time
and effort.  I appreciate your patience and will have an updated CL to you
soon.

~Eric


On Tue, Aug 7, 2012 at 5:43 PM, <adg@golang.org> wrote:

> Am I still waiting on an additional change from you?
>
>
http://codereview.appspot.com/**6452058/<http://codereview.appspot.com/6452058/>
>

[adg1, 2012-08-08 00:51:44]

On 8 August 2012 10:50, Eric Gavaletz <gavaletz@google.com> wrote:
> Yes, and given the feedback that Joe has gotten on the issue with the .p12
> file I think I am going to have to include commentary about unpacking the
> key using openssl.  My GSoC student also highlighted that there was an issue
> with having an assert method that makes use of the default http client.
> When running on GAE we need to be able to use the url fetch.  So I am going
> to have to take another look at that too.
>
> For something that should have been a simple fix it is taking a lot of time
> and effort.  I appreciate your patience and will have an updated CL to you
> soon.

I appreciate your hard work more :-)

Thanks.

[gavaletz_google, 2012-08-10 20:26:59]

Hello adg@google.com, adg@golang.org, jcgregorio@google.com (cc:
bradfitz@google.com, golang-dev@googlegroups.com, tiziana@google.com),

Please take another look.

[gavaletz_google, 2012-08-10 20:28:59]

Hello adg@google.com, adg@golang.org, jcgregorio@google.com (cc:
bradfitz@google.com, golang-dev@googlegroups.com, tiziana@google.com),

Please take another look.

[gavaletz_google, 2012-08-10 20:32:24]

Today is my last day at Google (at least for the next year).  I would like
to get this submitted before I have to leave, but if there are issues that
will prevent that how should I handle this using my external email/account (
gavaletz@gmail.com).

~Eric


On Fri, Aug 10, 2012 at 1:28 PM, <gavaletz@google.com> wrote:

> Hello adg@google.com, adg@golang.org, jcgregorio@google.com (cc:
> bradfitz@google.com, golang-dev@googlegroups.com, tiziana@google.com),
>
> Please take another look.
>
>
>
http://codereview.appspot.com/**6452058/<http://codereview.appspot.com/6452058/>
>

[iant2, 2012-08-10 20:58:19]

On Fri, Aug 10, 2012 at 1:32 PM, Eric Gavaletz <gavaletz@google.com> wrote:
> Today is my last day at Google (at least for the next year).  I would like
> to get this submitted before I have to leave, but if there are issues that
> will prevent that how should I handle this using my external email/account
> (gavaletz@gmail.com).

Unfortunately I think both adg and bradfitz are out today.

Anybody else feel up on goauth2?

Ian

> On Fri, Aug 10, 2012 at 1:28 PM, <gavaletz@google.com> wrote:
>>
>> Hello adg@google.com, adg@golang.org, jcgregorio@google.com (cc:
>> bradfitz@google.com, golang-dev@googlegroups.com, tiziana@google.com),
>>
>> Please take another look.
>>
>>
>> http://codereview.appspot.com/6452058/
>
>

[gavaletz_google, 2012-08-10 21:02:12]

Since this CL has a fair amount of history I guess the better question
would be how to continue working on this CL with my gmail account.  I am
new to this review system and mercurial.  Would it be sufficient to tar the
directory and login to the review system with my gmail address?

~Eric


On Fri, Aug 10, 2012 at 1:58 PM, Ian Lance Taylor <iant@google.com> wrote:

> On Fri, Aug 10, 2012 at 1:32 PM, Eric Gavaletz <gavaletz@google.com>
> wrote:
> > Today is my last day at Google (at least for the next year).  I would
> like
> > to get this submitted before I have to leave, but if there are issues
> that
> > will prevent that how should I handle this using my external
> email/account
> > (gavaletz@gmail.com).
>
> Unfortunately I think both adg and bradfitz are out today.
>
> Anybody else feel up on goauth2?
>
> Ian
>
> > On Fri, Aug 10, 2012 at 1:28 PM, <gavaletz@google.com> wrote:
> >>
> >> Hello adg@google.com, adg@golang.org, jcgregorio@google.com (cc:
> >> bradfitz@google.com, golang-dev@googlegroups.com, tiziana@google.com),
> >>
> >> Please take another look.
> >>
> >>
> >> http://codereview.appspot.com/6452058/
> >
> >
>

[iant2, 2012-08-10 21:14:54]

On Fri, Aug 10, 2012 at 2:01 PM, Eric Gavaletz <gavaletz@google.com> wrote:
> Since this CL has a fair amount of history I guess the better question would
> be how to continue working on this CL with my gmail account.  I am new to
> this review system and mercurial.  Would it be sufficient to tar the
> directory and login to the review system with my gmail address?

I honestly don't know, but worst case you can "hg clpatch 6452058; hg
change -D 6452058" and then start a new CL with your non-Google
account.

Ian


> On Fri, Aug 10, 2012 at 1:58 PM, Ian Lance Taylor <iant@google.com> wrote:
>>
>> On Fri, Aug 10, 2012 at 1:32 PM, Eric Gavaletz <gavaletz@google.com>
>> wrote:
>> > Today is my last day at Google (at least for the next year).  I would
>> > like
>> > to get this submitted before I have to leave, but if there are issues
>> > that
>> > will prevent that how should I handle this using my external
>> > email/account
>> > (gavaletz@gmail.com).
>>
>> Unfortunately I think both adg and bradfitz are out today.
>>
>> Anybody else feel up on goauth2?
>>
>> Ian
>>
>> > On Fri, Aug 10, 2012 at 1:28 PM, <gavaletz@google.com> wrote:
>> >>
>> >> Hello adg@google.com, adg@golang.org, jcgregorio@google.com (cc:
>> >> bradfitz@google.com, golang-dev@googlegroups.com, tiziana@google.com),
>> >>
>> >> Please take another look.
>> >>
>> >>
>> >> http://codereview.appspot.com/6452058/
>> >
>> >
>
>

[gavaletz, 2012-08-21 19:41:49]

I am getting back to work at my university and was wondering what further
feedback you have for this.  My personal needs are for the authentication to
work for Google services, and with that in mind you can "hide" a lot of the
details that remain constant for Google services.  This makes the code easier to
maintain, but we may want to think about the open issues that relate to other
services (Facebook and Microsoft for example) and how we may need to re-think
the API.  I think that this JWT implementation would be a good addition to the
existing library, but maybe we want to do a major upgrade in the future that
addresses the compatibility issues.

Having to go back and consider all the different OAuth2 mechanisms, use cases
and services may call for a design change that breaks the existing API.  I
personally don't use Facebook or Microsoft, and adding the ability to work with
those services would increase the size and complexity of the library.  There is
a growing list of open issues, but given the trouble that we have had with JWT
on Google servers I am not excited about the prospects of testing for Facebook,
Microsoft, and what ever comes next.

~Eric Gavaletz

[adg1, 2012-08-22 01:50:02]

On 22 August 2012 05:41,  <gavaletz@gmail.com> wrote:
> I am getting back to work at my university and was wondering what
> further feedback you have for this.  My personal needs are for the
> authentication to work for Google services, and with that in mind you
> can "hide" a lot of the details that remain constant for Google
> services.  This makes the code easier to maintain, but we may want to
> think about the open issues that relate to other services (Facebook and
> Microsoft for example) and how we may need to re-think the API.  I think
> that this JWT implementation would be a good addition to the existing
> library, but maybe we want to do a major upgrade in the future that
> addresses the compatibility issues.

It looks fine to me, too. Could you please re-create this CL from your
gmail account so we can polish it up for submission? Thanks.

> Having to go back and consider all the different OAuth2 mechanisms, use
> cases and services may call for a design change that breaks the existing
> API.  I personally don't use Facebook or Microsoft, and adding the
> ability to work with those services would increase the size and
> complexity of the library.  There is a growing list of open issues, but
> given the trouble that we have had with JWT on Google servers I am not
> excited about the prospects of testing for Facebook, Microsoft, and what
> ever comes next.

Both FB and MS's oauth implementations go against the spec, so I'm not
going to bend over to support them either. Other contributors have
stepped in to do so in the past, and I'm prepared to let them do it
again with JWT if necessary.

Andrew

[adg1, 2012-08-22 12:14:01]

You can't. You must start a new one.

The history is still there. Just cite the old review URL in the new CL
description.

Thanks!

On 11 August 2012 07:01, Eric Gavaletz <gavaletz@google.com> wrote:
> Since this CL has a fair amount of history I guess the better question would
> be how to continue working on this CL with my gmail account.  I am new to
> this review system and mercurial.  Would it be sufficient to tar the
> directory and login to the review system with my gmail address?
>
> ~Eric
>
>
> On Fri, Aug 10, 2012 at 1:58 PM, Ian Lance Taylor <iant@google.com> wrote:
>>
>> On Fri, Aug 10, 2012 at 1:32 PM, Eric Gavaletz <gavaletz@google.com>
>> wrote:
>> > Today is my last day at Google (at least for the next year).  I would
>> > like
>> > to get this submitted before I have to leave, but if there are issues
>> > that
>> > will prevent that how should I handle this using my external
>> > email/account
>> > (gavaletz@gmail.com).
>>
>> Unfortunately I think both adg and bradfitz are out today.
>>
>> Anybody else feel up on goauth2?
>>
>> Ian
>>
>> > On Fri, Aug 10, 2012 at 1:28 PM, <gavaletz@google.com> wrote:
>> >>
>> >> Hello adg@google.com, adg@golang.org, jcgregorio@google.com (cc:
>> >> bradfitz@google.com, golang-dev@googlegroups.com, tiziana@google.com),
>> >>
>> >> Please take another look.
>> >>
>> >>
>> >> http://codereview.appspot.com/6452058/
>> >
>> >
>
>

[shaan7, 2015-01-10 06:59:25]

Did anything happen after this? I'm in need of a way to auth my AppEngine Go app
to authenticate with BigQuery. This is the closest I've found to what would let
me use an AppEngine Servuce Account.

On 2012/08/22 12:14:01, adg1 wrote:
> You can't. You must start a new one.
> 
> The history is still there. Just cite the old review URL in the new CL
> description.
> 
> Thanks!
> 
> On 11 August 2012 07:01, Eric Gavaletz <mailto:gavaletz@google.com> wrote:
> > Since this CL has a fair amount of history I guess the better question would
> > be how to continue working on this CL with my gmail account.  I am new to
> > this review system and mercurial.  Would it be sufficient to tar the
> > directory and login to the review system with my gmail address?
> >
> > ~Eric
> >
> >
> > On Fri, Aug 10, 2012 at 1:58 PM, Ian Lance Taylor <mailto:iant@google.com>
wrote:
> >>
> >> On Fri, Aug 10, 2012 at 1:32 PM, Eric Gavaletz <mailto:gavaletz@google.com>
> >> wrote:
> >> > Today is my last day at Google (at least for the next year).  I would
> >> > like
> >> > to get this submitted before I have to leave, but if there are issues
> >> > that
> >> > will prevent that how should I handle this using my external
> >> > email/account
> >> > (mailto:gavaletz@gmail.com).
> >>
> >> Unfortunately I think both adg and bradfitz are out today.
> >>
> >> Anybody else feel up on goauth2?
> >>
> >> Ian
> >>
> >> > On Fri, Aug 10, 2012 at 1:28 PM, <mailto:gavaletz@google.com> wrote:
> >> >>
> >> >> Hello mailto:adg@google.com, mailto:adg@golang.org,
mailto:jcgregorio@google.com (cc:
> >> >> mailto:bradfitz@google.com, mailto:golang-dev@googlegroups.com,
mailto:tiziana@google.com),
> >> >>
> >> >> Please take another look.
> >> >>
> >> >>
> >> >> http://codereview.appspot.com/6452058/
> >> >
> >> >
> >
> >

[gobot, 2015-01-10 07:01:14]

Replacing golang-dev with golang-codereviews.

To the author of this CL: 

If you are using 'hg mail -r golang-dev' to mail the CL, use simply 'hg mail'
instead.

If you did not name golang-dev explicitly and it was still added to the CL,
it means your working copy of the repo has a stale codereview.cfg
(or lib/codereview/codereview.cfg).
Please run 'hg sync' to update your client to the most recent codereview.cfg.
If the most recent codereview.cfg has defaultcc set to golang-dev instead of
golang-codereviews, please send a CL correcting it.

Thanks very much.

[bradfitz, 2015-01-13 02:12:26]

Burcu,

Does this old CL add anything over the service account stuff we already
have?


On Fri, Jan 9, 2015 at 10:59 PM, <shaan7in@gmail.com> wrote:

> Did anything happen after this? I'm in need of a way to auth my
> AppEngine Go app to authenticate with BigQuery. This is the closest I've
> found to what would let me use an AppEngine Servuce Account.
>
> On 2012/08/22 12:14:01, adg1 wrote:
>
>> You can't. You must start a new one.
>>
>
>  The history is still there. Just cite the old review URL in the new CL
>> description.
>>
>
>  Thanks!
>>
>
>  On 11 August 2012 07:01, Eric Gavaletz <mailto:gavaletz@google.com>
>>
> wrote:
>
>> > Since this CL has a fair amount of history I guess the better
>>
> question would
>
>> > be how to continue working on this CL with my gmail account.  I am
>>
> new to
>
>> > this review system and mercurial.  Would it be sufficient to tar the
>> > directory and login to the review system with my gmail address?
>> >
>> > ~Eric
>> >
>> >
>> > On Fri, Aug 10, 2012 at 1:58 PM, Ian Lance Taylor
>>
> <mailto:iant@google.com> wrote:
>
>> >>
>> >> On Fri, Aug 10, 2012 at 1:32 PM, Eric Gavaletz
>>
> <mailto:gavaletz@google.com>
>
>> >> wrote:
>> >> > Today is my last day at Google (at least for the next year).  I
>>
> would
>
>> >> > like
>> >> > to get this submitted before I have to leave, but if there are
>>
> issues
>
>> >> > that
>> >> > will prevent that how should I handle this using my external
>> >> > email/account
>> >> > (mailto:gavaletz@gmail.com).
>> >>
>> >> Unfortunately I think both adg and bradfitz are out today.
>> >>
>> >> Anybody else feel up on goauth2?
>> >>
>> >> Ian
>> >>
>> >> > On Fri, Aug 10, 2012 at 1:28 PM, <mailto:gavaletz@google.com>
>>
> wrote:
>
>> >> >>
>> >> >> Hello mailto:adg@google.com, mailto:adg@golang.org,
>>
> mailto:jcgregorio@google.com (cc:
>
>> >> >> mailto:bradfitz@google.com, mailto:golang-dev@googlegroups.com,
>>
> mailto:tiziana@google.com),
>
>> >> >>
>> >> >> Please take another look.
>> >> >>
>> >> >>
>> >> >> http://codereview.appspot.com/6452058/
>> >> >
>> >> >
>> >
>> >
>>
>
>
>
> https://codereview.appspot.com/6452058/
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+unsubscribe@googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
>

[jbd, 2015-01-13 04:33:00]

No, it doesn't. You can close it.

On Mon, Jan 12, 2015 at 6:12 PM, Brad Fitzpatrick <bradfitz@golang.org> wrote:
> Burcu,
>
> Does this old CL add anything over the service account stuff we already
> have?
>
>
> On Fri, Jan 9, 2015 at 10:59 PM, <shaan7in@gmail.com> wrote:
>>
>> Did anything happen after this? I'm in need of a way to auth my
>> AppEngine Go app to authenticate with BigQuery. This is the closest I've
>> found to what would let me use an AppEngine Servuce Account.
>>
>> On 2012/08/22 12:14:01, adg1 wrote:
>>>
>>> You can't. You must start a new one.
>>
>>
>>> The history is still there. Just cite the old review URL in the new CL
>>> description.
>>
>>
>>> Thanks!
>>
>>
>>> On 11 August 2012 07:01, Eric Gavaletz <mailto:gavaletz@google.com>
>>
>> wrote:
>>>
>>> > Since this CL has a fair amount of history I guess the better
>>
>> question would
>>>
>>> > be how to continue working on this CL with my gmail account.  I am
>>
>> new to
>>>
>>> > this review system and mercurial.  Would it be sufficient to tar the
>>> > directory and login to the review system with my gmail address?
>>> >
>>> > ~Eric
>>> >
>>> >
>>> > On Fri, Aug 10, 2012 at 1:58 PM, Ian Lance Taylor
>>
>> <mailto:iant@google.com> wrote:
>>>
>>> >>
>>> >> On Fri, Aug 10, 2012 at 1:32 PM, Eric Gavaletz
>>
>> <mailto:gavaletz@google.com>
>>>
>>> >> wrote:
>>> >> > Today is my last day at Google (at least for the next year).  I
>>
>> would
>>>
>>> >> > like
>>> >> > to get this submitted before I have to leave, but if there are
>>
>> issues
>>>
>>> >> > that
>>> >> > will prevent that how should I handle this using my external
>>> >> > email/account
>>> >> > (mailto:gavaletz@gmail.com).
>>> >>
>>> >> Unfortunately I think both adg and bradfitz are out today.
>>> >>
>>> >> Anybody else feel up on goauth2?
>>> >>
>>> >> Ian
>>> >>
>>> >> > On Fri, Aug 10, 2012 at 1:28 PM, <mailto:gavaletz@google.com>
>>
>> wrote:
>>>
>>> >> >>
>>> >> >> Hello mailto:adg@google.com, mailto:adg@golang.org,
>>
>> mailto:jcgregorio@google.com (cc:
>>>
>>> >> >> mailto:bradfitz@google.com, mailto:golang-dev@googlegroups.com,
>>
>> mailto:tiziana@google.com),
>>>
>>> >> >>
>>> >> >> Please take another look.
>>> >> >>
>>> >> >>
>>> >> >> http://codereview.appspot.com/6452058/
>>> >> >
>>> >> >
>>> >
>>> >
>>
>>
>>
>>
>> https://codereview.appspot.com/6452058/
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-dev+unsubscribe@googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>

[幹你娘, 2020-11-21 03:29:55]

改三小

[幹你娘, 2020-11-21 03:36:26]

zhtw1234  baby546833都是我，我叫周訓毅專幹你娘，老雞歪也很愛

[幹你娘, 2020-11-21 03:36:51]

zhtw1234  baby546833都是我，我叫周訓毅專幹你娘，老雞歪也很愛

[幹你娘, 2021-01-01 03:49:11]

https://codereview.appspot.com/6452058/diff/1001/oauth/jwt/jwt.go
File oauth/jwt/jwt.go (right):

https://codereview.appspot.com/6452058/diff/1001/oauth/jwt/jwt.go#newcode8
oauth/jwt/jwt.go:8: "../../oauth"
On 2012/08/01 18:54:04, gavaletz_google wrote:
> <font style="vertical-align: inherit;"><font style="vertical-align:
inherit;">在2012/07/30 09：24：26，adg寫道：> code.google.com/p/goauth2/oauth
> 
> </font></font>
> <font style="vertical-align: inherit;"><font style="vertical-align:
inherit;">已經進行了更改；</font><font style="vertical-align:
inherit;">但是，我現在無法運行測試。</font><font style="vertical-align: inherit;">為了開始項目，我使用“
hg clone </font></font>https://code.google.com/p/goauth2/%22<font
style="vertical-align: inherit;"><font style="vertical-align: inherit;">簽出了代碼
幹
你
娘
老
雞
歪

https://codereview.appspot.com/6452058/diff/1001/oauth/jwt/jwt.go#newcode225
oauth/jwt/jwt.go:225: func (t *Token) BuildRequest() (*http.Request, error) {
不要臉，已婚的男人周訓毅剛好就好不要找難看

[幹你娘, 2021-08-11 06:42:12]

全家死光

[幹你娘, 2021-08-11 06:43:46]

https://codereview.appspot.com/6452058/diff/1001/oauth/jwt/jwt.go
File oauth/jwt/jwt.go (right):

https://codereview.appspot.com/6452058/diff/1001/oauth/jwt/jwt.go#newcode8
oauth/jwt/jwt.go:8: "../../oauth"
On 2012/07/30 09:24:26, adg .

[幹你娘, 2021-08-11 06:47:53]

幹你娘