From [email protected] on March 23, 2012 08:27:30

From yanivi:

• rename LICENSE to LICENSE.txt
• update readme.html to specify jars needed for Android in base libs like we did in codegen libs
• Please explicitly exclude commons-codec from the download zip, we do not need it anymore.
• Change all deprecation messages to say "scheduled to be removed in the future" (or something like that) instead of specifying "scheduled to be removed in 1.X".

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=29

From [email protected] on August 12, 2011 10:12:36

External references, such as a standards document, or specification? http://google-web-toolkit.googlecode.com/svn/javadoc/1.5/com/google/gwt/user/server/rpc/RemoteServiceServlet.html Java environments (e.g. Java 6, Android 2.3, App Engine 1.4.2, or All)? App Engine. Please describe the feature requested. Currently to use the OAuth 2 servlet flow I need to extend AbstractFlowUserServlet. But for GWT RPC I must extend RemoteServiceServlet. More generally, it seems conceivable that there be other cases where servlet developers may need to extend a specific servlet class other than AbstractFlowUserServlet, and so would be unable to leverage our OAuth 2 flow. It would be great to find a solution that was general-purpose enough to support all of these use cases. That said, we won't change the usage of AbstractFlowUserServlet, but only its implementation to use the general-purpose utilities.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=9

From [email protected] on June 08, 2011 14:45:33

Version of google-api-java-client (e.g. 1.3.1-alpha)? 1.4.1-beta Java environment (e.g. Java 6, Android 2.3, App Engine 1.4.2)? ALL Describe the problem. The AssertionGrant constructor currently asks for a client secret. The assertion grant flow does not require or support the notion of a client secret. Relevant portion of the spec: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.1.3 How would you expect it to be fixed? Remove the client secret parameter.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=6

From [email protected] on April 26, 2012 07:16:05

http://javadoc.google-oauth-java-client.googlecode.com/hg/1.8.0-beta/deprecated-list.html Change target release for deprecations we do not currently want to remove.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=35

From [email protected] on August 06, 2012 21:32:12

google-oauth-java-client : 1.10.1-beta
Java 6.33 32bit, Linux

GoogleAuthorizationCodeFlow flow = gBuilder.setAccessType("offline").setApprovalPrompt("force").setCredentialStore(new JdoCredentialStore(persistenceFactory)).build();

when i am trying to delete stored credential :

Credential credential = getStoredCredential(userId);
getFlow().getCredentialStore().delete(userId, credential);

I got message :

javax.jdo.JDOUserException: Transient instances cant be deleted.

Caused by :

javax.jdo.JDOUserException: Transient instances cant be deleted.
at org.datanucleus.jdo.NucleusJDOHelper.getJDOExceptionForNucleusException(NucleusJDOHelper.java:375)
at org.datanucleus.jdo.JDOPersistenceManager.jdoDeletePersistent(JDOPersistenceManager.java:759)
at org.datanucleus.jdo.JDOPersistenceManager.deletePersistent(JDOPersistenceManager.java:772)
at com.google.api.client.extensions.jdo.auth.oauth2.JdoCredentialStore.delete(JdoCredentialStore.java:57)
at com.fronde.google.mailmerge.utils.UserUtils.deleteStoredCredential(UserUtils.java:227)

New (users) credentials are created, but is not possible to remove tokens.

Any ideas ? In previous version (1.6.0) Credentials were stored directly not through JDOCredentialStore, maybe that`s the problem.
Thank you

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=48

From [email protected] on June 02, 2011 12:02:21

Version of google-api-java-client? 1.5+

Describe the problem:
Discovery has auth endpoints. We can make those available in the generated surfaces, named with a short identifier. Using the identifier is less error prone than copying a URL from the documentation. Beyond that, it should be possible to mix endpoints from two different services and pass the set to an auth helper class. How would you expect it to be fixed? A common base interface for all generated oauth endpoints. Generators would emit to that, auth helpers would expect it. The only method we need now is the ability to get a string from the name, so we can make enums by short identifier but be able to extract the full value which is the endpoint url.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=4

From [email protected] on August 25, 2011 05:14:56

Reported by [email protected], Today (97 minutes ago)

Version 1.5.0 Describe the problem. Many GAE/J applications make use of other persistence frameworks or use the low-level API, making both the Enhancement step and the JDO library extraneous. How would you expect it to be fixed? Use the low level API for your persistence calls.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=10

From [email protected] on February 09, 2012 13:11:10

External references, such as a standards document, or specification? http://tools.ietf.org/html/draft-jones-json-web-token-07 http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-00 Java environments (e.g. Java 6, Android 2.3, App Engine, or All)? All Please describe the feature requested. Add support for JSON Web Token (JWT) and JSON Web Signature (JWS).

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=23

From [email protected] on April 23, 2012 15:01:40

External references, such as a standards document, or specification? http://docs.oracle.com/javase/7/docs/api/java/lang/System.html#currentTimeMillis() Java environments (e.g. Java 6, Android 2.3, App Engine, or All)? All Please describe the feature requested. We have several places where we call System.currentTimeMillis(): e.g. JsonWebToken and Credential. This makes it not ideal for testing. For example, if I want to test JsonWebToken.Payload.isValidTime(), it is better to control the result of System.currentTimeMillis() to test the border cases in an exact way.

We first need to define an appropriate interface. We can either use Supplier (Supplier comes from com.google.common.base in google guava), or we can define a custom interface like:

interface Clock {
long now();
}

in com.google.api.client.util. We would additionally provide an implementation based on System.currentTimeMillis() that would always be the default implementation. Something roughly like:

private static final Supplier SYSTEM_TIME = new Supplier(){
public Long get() {
return System.currentTimeMillis();
}};
}

public static Supplier systemTimeProvider() {
return SYSTEM_TIME;
}

then we can add an additional method that also accepts Supplier that would only be used in tests, e.g.

public boolean isValidTime(long acceptableTimSkewSeconds, Supplier timeProvider)

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=34

From [email protected] on February 28, 2012 17:18:35

External references, such as a standards document, or specification? N/A Java environments (e.g. Java 6, Android 2.3, App Engine, or All)? All Please describe the feature requested. We should implement OAuth 1.0 credential and flows just like the ones for OAuth 2.0.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=26

From [email protected] on June 08, 2012 09:23:28

http://javadoc.google-oauth-java-client.googlecode.com/hg/1.9.0-beta/deprecated-list.html

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=43

From [email protected] on May 11, 2011 10:18:15

External references, such as a standards document, or specification? N/A Java environments (e.g. Java 6, Android 2.3, App Engine 1.4.2, or All)? All. Please describe the feature requested. Same as our helpers for OAuth 2, we should extend them to also support OAuth 1.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=2

From [email protected] on January 10, 2012 09:59:45

Version of google-oauth-java-client? 1.6.0-beta

Java environment? App Engine Describe the problem. The problem is that the Dropbox API uses OAuth 1.0, but it expects all http requests to format URL's according to the following encoding (notice the forward-slash, which is needed, because we are creating URL's which point to Dropbox resources),

new PercentEscaper("-_.*/", false);

com.google.api.client.auth.oauth.OAuthParameters creates an instance of com.google.api.client.http.GenericUrl in the computeSignature method. This is a problem for me, because GenericUrl performs path encoding effectively using,

new PercentEscaper("-_.!~*'()@:$&,;=", false);

The problems occur when something like a parentheses is in the URL, and Dropbox will immediately reject the request. I can not use the Dropbox Java API, because I'm using App Engine and hence URLFetch. How would you expect it to be fixed? My short term solution has been to completely copy OAuthParameters and change one line of code to use a subclass of GenericUrl in the computeSignature function.

Instead of creating an instance of GenericUrl using the default constructor GenericUrl(), would it work to instead call GenericUrl.clone() on the requestUrl argument and then remove the parts of the URL needed for "normalization" as it is currently being done? Subclasses of GenericUrl could override clone() and that should suffice. I have created a related case for google-http-java-client, https://code.google.com/p/google-http-java-client/issues/detail?id=58 Also, why not remove the final keyword from OAuthParameters? If all else fails, we can then override some of its functions.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=22

From [email protected] on May 20, 2011 08:18:03

External references, such as a standards document, or specification? http://javadoc.google-api-java-client.googlecode.com/hg/1.4.1-beta/deprecated-list.html Java environments (e.g. Java 6, Android 2.3, App Engine 1.4.2, or All)? All Please describe the feature requested. See link above for advice on how to upgrade.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=3

From [email protected] on September 22, 2011 12:49:09

Version of google-oauth-java-client (e.g. 1.5.0-beta)? 1.5.0-beta Java environment (e.g. Java 6, Android 2.3, App Engine)? All Describe the problem. For example, look at this JavaDoc: http://javadoc.google-oauth-java-client.googlecode.com/hg/1.5.0-beta/com/google/api/client/auth/oauth2/draft10/AccessTokenResponse.html There is no link to GenericData. How would you expect it to be fixed? Ideally link to the HTTP library's JavaDoc. For the case above, it should link to: http://javadoc.google-http-java-client.googlecode.com/hg/1.5.0-beta/com/google/api/client/util/GenericData.html

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=13

From [email protected] on April 13, 2012 19:43:25

google-oauth-java-client is causing junit to be deployed as part of my production server, which is silly.

This is wrong:

junit
junit

It should be:

junit
junit
test

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=32

From [email protected] on October 07, 2011 08:47:15

Version of google-oauth-java-client (e.g. 1.5.0-beta)? Java environment (e.g. Java 6, Android 2.3, App Engine)? All. Describe the problem. If I call the AccessProtectedResource constructor that takes a refreshToken parameter as input with a null refreshToken, it will throw a NullPointerException. Technically, this is not a bug because the JavaDoc documentation doesn't allow null, and by convention for this library we assume null is not allowed unless otherwise specified. However, in this case, it has the potential to cause a NullPointerException in many clients' code if the OAuth 2.0 service doesn't guarantee whether or not a refresh token would be returned. Clients may not realize this, and just always call the AccessProtectedResource constructor that takes a refresh token, and will be broken later.

In particular this bites us in OAuth2ThreeLeggedFlow. We assume AccessTokenResponse.refreshToken is not null, pass it to the constructor of OAuth2Credential, and throw a NullPointerException. So this is clearly a bug. How would you expect it to be fixed? The simplest thing is to just allow refreshToken to be null in the constructors for OAuth2Credential and AccessProtectedResource.

Some JavaDoc references: http://javadoc.google-oauth-java-client.googlecode.com/hg/1.5.0-beta/com/google/api/client/auth/oauth2/draft10/AccessProtectedResource.html#AccessProtectedResource(java.lang.String , com.google.api.client.auth.oauth2.draft10.AccessProtectedResource.Method, com.google.api.client.http.HttpTransport, com.google.api.client.json.JsonFactory, java.lang.String, java.lang.String, java.lang.String, java.lang.String) http://javadoc.google-oauth-java-client.googlecode.com/hg/1.5.0-beta/com/google/api/client/extensions/auth/helpers/oauth2/draft10/OAuth2Credential.html#OAuth2Credential(java.lang.String , java.lang.String, java.lang.String)

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=14

From [email protected] on May 16, 2012 22:53:54

Version of google-oauth-java-client (e.g. 1.5.0-beta)? trunk Java environment (e.g. Java 6, Android 2.3, App Engine)? java 6 Describe the problem. package: com.google.api.services.samples.dailymotion.cmd
file: lineDailyMotionSample.java
private static void launchInBrowser(
String browser, String redirectUrl, String clientId, String scope) throws IOException {
String authorizationUrl = new AuthorizationCodeRequestUrl(
AUTHORIZATION_SERVER_URL, clientId).setRedirectUri(redirectUrl).build();
if (Desktop.isDesktopSupported()) {
Desktop desktop = Desktop.getDesktop();
if (desktop.isSupported(Action.BROWSE)) {
desktop.browse(URI.create(authorizationUrl));
return;
}
}
if (browser != null) {
Runtime.getRuntime().exec(new String[] {browser, authorizationUrl});
} else {
System.out.println("Open the following address in your favorite browser:");
System.out.println(" " + authorizationUrl);
}
}

Scope is not passed to redirect url. How would you expect it to be fixed? String authorizationUrl = new AuthorizationCodeRequestUrl(
AUTHORIZATION_SERVER_URL, clientId).setRedirectUri(redirectUrl).setScopes(scope).build();

Or, please remove this param.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=39

From [email protected] on February 16, 2012 08:30:06

Split extensions into servlet and appengine.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=25

From [email protected] on December 06, 2011 04:31:44

Referenced documentation: https://code.google.com/p/google-oauth-java-client/wiki/Setup Please describe in detail the wiki documentation request: Need to add directions for setting up a project in Eclipse with the library.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=19

From [email protected] on March 05, 2012 12:52:22

External references, such as a standards document, or specification? https://code.google.com/p/google-oauth-java-client/source/browse/google-oauth-client/src/main/java/com/google/api/client/auth/oauth2/CredentialStore.java Java environments (e.g. Java 6, Android 2.3, App Engine, or All)? All, but primarily for desktop installed Java applications Please describe the feature requested. FileCredentialStore implementation of CredentialStore interface that persists credentials into a File. We need to be careful about the security of those credentials since credentials information is sensitive data.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=27

From [email protected] on March 31, 2012 06:48:57

With datastore writes costing a premium on Google App Engine, property fields not needing indexes (accessToken, refreshToken, and maybe expirationTimeMillis) should be set with entity.setUnindexedProperty().

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=31

From [email protected] on November 17, 2011 07:19:55

External references, such as a standards document, or specification? http://javadoc.google-oauth-java-client.googlecode.com/hg/1.6.0-beta/deprecated-list.html Java environments (e.g. Java 6, Android 2.3, App Engine, or All)? All Please describe the feature requested. Remove deprecated classes/methods/fields from version 1.6. See the reference above.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=17

From [email protected] on June 29, 2011 05:59:55

External references, such as a standards document, or specification? http://javadoc.google-oauth-java-client.googlecode.com/hg/1.5.0-beta/deprecated-list.html Java environments (e.g. Java 6, Android 2.3, App Engine 1.4.2, or All)? All Please describe the feature requested. See link above for advice on how to upgrade.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=7

From [email protected] on May 14, 2012 08:00:18

Similar to https://code.google.com/p/google-http-java-client/issues/detail?id=109 .

Summary by yanivi:

Currently the google-http-client jars are at the root of the zip file, and the dependency jars are in the dependencies folder.

Instead, I propose a new structure which puts all of the binary jars in a "libs" folder and all of the source jars are in the "libs-sources" folder. No distinction between http base lib or the dependencies. This follows exactly the structure of the jars in tasks-android-sample.

One motivation is that for Android applications, the package manager requires the directory with all binary jars to be called "libs". Similarly, for HTTP servlets to jars must go in the war/WEB-INF/lib folder. Normally source jars aren't placed in this directory, so that's why I recommend also doing the same for libs-sources.

Additionally, we should provide the classpath entries to use for the .classpath file for Eclipse for the various platforms. It's just too much of a pain to craft them manually, and often people forget the sourcepath which makes it more difficult for debugging.

We should make the same changes in the projects that we own that depend on this project (api, oauth, etc).

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=38

From [email protected] on May 11, 2011 10:11:50

Copied from: https://code.google.com/p/google-api-java-client/issues/detail?id=95 Describe the problem.

Form encoded POST parameters are part of the signature base string and must be signed. Looking at OAuthAuthorizationHeaderIntercepter it is clear that the interceptor does not do this: it simply passes request method and URL to the OAuthParameters object. Consequently, the computed signature is wrong and the POST request fails.
This comes up when, e.g. tweeting using the Twitter API: their API expects a form encoded "status" parameter. GET requests using the OAuthAuthorizationHeaderIntercepter work fine.

How would you expect it to be fixed?

One possible fix would be to provide a second OAuthParameters#computeSignature that accepts a collection of additional parameters that form part of the signature base string. The OAuthAuthorizationHeaderIntercepter could then check the HttpRequest's method and in the case of a form encoded POST request pass the additional parameters to the #computeSignature method.

Comment 1 by project member [email protected], Jan 8, 2011

Thanks for reporting this issue. This is actually a known limitation: http://javadoc.google-api-java-client.googlecode.com/hg/1.2.2-alpha/com/google/api/client/auth/oauth/package-summary.html But thanks for bringing it to my attention. We do want this OAuth library to work properly with the Twitter API.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=1

From [email protected] on April 26, 2012 07:34:00

Version of google-oauth-java-client (e.g. 1.5.0-beta)? 1.8.0-beta, 1.9.0-beta-SNAPSHOT Java environment (e.g. Java 6, Android 2.3, App Engine)? All? Describe the problem. OAuth 1.0 OAuthParameters class overwrites repeated query parameters instead of sorting by value, as required by the OAuth 1.0 spec ( http://tools.ietf.org/html/rfc5849#section-3.4.1.3.2 , second part of point 2). How would you expect it to be fixed? The overwriting happens in lines 154-156 of com.google.api.client.auth.oauth.OAuthParameters. One way to fix would be to change parameters (declared on line 139) from TreeMap<String, String> to TreeMap<String, Object>, where the value could be a String or a TreeSet. This would be analogous to the handling of repeated query parameters in GenericUrl. Corresponding adjustment to the putParameter() method and the building of the normalizedParameters String should complete the fix.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=36

From [email protected] on August 21, 2012 11:06:24

Java environments (e.g. Java 6, Android 2.3, App Engine, or All)? All. Please describe the feature requested. Please allow a way to add the state parameter when using the AbstractAuthorizationCodeServlet, similar to GoogleAuthorizationCodeFlow.newAuthorizationUrl().setState("foo")

Thanks!
--brendan

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=49

From [email protected] on October 22, 2011 13:21:36

Now that google-http-java-client 1.5.3-beta has been released we should update pom.xml in the 1.5 branch and release google-oauth-java-client 1.5.2-beta

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=15

From [email protected] on July 26, 2011 14:54:26

Currently the helpers use only the user ID as a key to find the associated credential in the data store. A developer was confused when they changed their scope in their code, but the original credential was still seen as valid. There are two proposed solutions:

1. Add the scope as a key component for looking up credential objects.
2. Discard tokens which have a different scope than the one in code.

We have to figure out which behavior would surprise users the least. I am leaning toward using the scope as a key component because they may have implementations that user different scopes for different requests for the same user. The current recommended usage would just request one token with all scopes.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=8

From [email protected] on June 06, 2012 09:51:19

External references, such as a standards document, or specification? http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-4.4 Java environments (e.g. Java 6, Android 2.3, App Engine, or All)? Java 5+ Please describe the feature requested. It would be great if out of the box the client worked with oAuth2 Client Credentials Flow.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=41

From [email protected] on February 10, 2012 10:47:43

Version of google-oauth-java-client (e.g. 1.5.0-beta)? 1.6.0-beta Java environment (e.g. Java 6, Android 2.3, App Engine)? Android Describe the problem. When using ResourceOwnerCredentialsAccessTokenRequest, the password is not sent in the request. How would you expect it to be fixed? I believe this derives from a missing "@key" in line 172 of https://code.google.com/p/google-oauth-java-client/source/browse/google-oauth-client/src/main/java/com/google/api/client/auth/oauth2/draft10/AccessTokenRequest.java

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=24

From [email protected] on June 08, 2012 11:17:15

http://javadoc.google-api-java-client.googlecode.com/hg/1.10.0-beta/deprecated-list.html

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=44

From [email protected] on July 11, 2012 14:48:07

Version of google-oauth-java-client: 1.10.1-beta?

Java environment Java 6, JEE

JDOCredentialStore causes "Duplicate entry exception" when refreshing access token with the "GoogleAuthorizationCodeFlow" and using DataNucleus Access Plattform 3.0.

Caused by: javax.jdo.JDODataStoreException: Duplicate entry 'XXXXIDXXXX' for key 'PRIMARY'
NestedThrowables:
java.sql.BatchUpdateException: Duplicate entry 'XXXXIDXXXX' for key 'PRIMARY'
at org.datanucleus.api.jdo.NucleusJDOHelper.getJDOExceptionForNucleusException(NucleusJDOHelper.java:421)
at org.datanucleus.api.jdo.JDOPersistenceManager.jdoMakePersistent(JDOPersistenceManager.java:735)
at org.datanucleus.api.jdo.JDOPersistenceManager.makePersistent(JDOPersistenceManager.java:755)
at com.google.api.client.extensions.jdo.auth.oauth2.JdoCredentialStore.store(JdoCredentialStore.java:47)
at com.google.api.client.auth.oauth2.CredentialStoreRefreshListener.makePersistent(CredentialStoreRefreshListener.java:73)
at com.google.api.client.auth.oauth2.CredentialStoreRefreshListener.onTokenResponse(CredentialStoreRefreshListener.java:51)
at com.google.api.client.auth.oauth2.Credential.refreshToken(Credential.java:512)
...
Caused by: java.sql.BatchUpdateException: Duplicate entry 'XXXXIDXXXX' for key 'PRIMARY'
at com.mysql.jdbc.PreparedStatement.executeBatchSerially(PreparedStatement.java:2035)
at com.mysql.jdbc.PreparedStatement.executeBatch(PreparedStatement.java:1458)
at org.apache.commons.dbcp.DelegatingStatement.executeBatch(DelegatingStatement.java:297)
at org.apache.commons.dbcp.DelegatingStatement.executeBatch(DelegatingStatement.java:297)
at org.datanucleus.store.rdbms.SQLController.processConnectionStatement(SQLController.java:607)
at org.datanucleus.store.rdbms.ConnectionFactoryImpl$ManagedConnectionImpl.release(ConnectionFactoryImpl.java:290)
at org.datanucleus.store.rdbms.request.InsertRequest.execute(InsertRequest.java:493)
at org.datanucleus.store.rdbms.RDBMSPersistenceHandler.insertTable(RDBMSPersistenceHandler.java:166)
at org.datanucleus.store.rdbms.RDBMSPersistenceHandler.insertObject(RDBMSPersistenceHandler.java:142) http://stackoverflow.com/questions/11420727/duplicate-entry-exception-using-googleauthorizationcodeflow-with-jdocredentialst How would you expect it to be fixed? Could this be the problem: "Modifying a persisted Object

To modify a previously persisted object you need to retrieve it (getObjectById, query, getExtent) and then modify it and its changes will be propagated to the datastore at commit of the transaction." ( http://www.datanucleus.org/products/datanucleus/jdo/pm.html )

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=46

From [email protected] on June 06, 2012 09:57:46

Reported by ryanboyd:

Using a bad scope in assertion profile code will result in an invalid_scope error (and 4xx response) from the OAuth token endpoint. The Java client library currently seems to ignore this error, and instead proceeds to make the call to the actual API service with an empty OAuth access token.

If there is an error in obtaining an access token using the assertion profile, I'd expect this to be thrown to the top level to enable easier debugging of issues using service accounts.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=42

From [email protected] on September 15, 2011 08:29:13

Which API and version (e.g. Google Calendar Data API version 2)? Dailymotion API What format (e.g. JSON, Atom)? JSON What Authentation (i.e. OAuth 1.0a or OAuth 2.0 draft 10)? OAuth 2.0 Java environment (e.g. Java 6, Android 2.3, App Engine)? Java 6 command-line External references, such as API reference guide? http://www.dailymotion.com/doc/api/rest-api-reference.html#get-videos-favorites Please provide any additional information below.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=12

From [email protected] on October 28, 2011 11:32:05

External references, such as a standards document, or specification? http://javadoc.google-oauth-java-client.googlecode.com/hg/1.5.0-beta/com/google/api/client/extensions/auth/helpers/appengine/package-summary.html Java environments (e.g. Java 6, Android 2.3, App Engine, or All)? App Engine Please describe the feature requested. By convention, all platform-specific packages should start with com.google.api.client.extensions.. Thus, all App Engine specific packages should start with com.google.api.client.extensions.appengine. We need to rename com.google.api.client.extensions.auth.helpers.appengine to com.google.api.client.extensions.appengine.auth.helpers

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=16

From [email protected] on July 05, 2012 08:06:21

version 1.11.0-beta-SNAPSHOT

Java v7

When I build I get test errors...

vi ./TEST-com.google.api.client.auth.oauth2.TokenErrorResponseTest.xml

java.lang.NoClassDefFoundError: org/codehaus/jackson/JsonFactory

I would assume we just need to include jackson in the classpath somewhere.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=45

From [email protected] on November 17, 2011 07:45:22

External references, such as a standards document, or specification? http://tools.ietf.org/html/draft-ietf-oauth-v2 http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer Java environments (e.g. Java 6, Android 2.3, App Engine, or All)? All Please describe the feature requested. Update to the latest draft of OAuth 2.0 and OAuth 2.0 Bearer specifications, and deprecate the existing Java package.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=18

From [email protected] on August 30, 2011 07:34:51

External references, such as a standards document, or specification? Windows: http://jdpapi.sourceforge.net/ Mac: http://developer.apple.com/library/mac/#documentation/Java/Conceptual/Java14Development/04-JavaUIToolkits/JavaUIToolkits.html#//apple_ref/doc/uid/TP40001901-210260 Java environments (e.g. Java 6, Android 2.3, App Engine, or All)? Java 5 Please describe the feature requested. Write a utility for storing secretes like OAuth refresh and access tokens on Windows, Mac, and UNIX. That would allow a native application to retrieve them when the application has been close and restarted, avoiding going through the UI flow every time an application is started.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=11

From [email protected] on August 22, 2012 08:11:38

External references, such as a standards document, or specification? http://javadoc.google-oauth-java-client.googlecode.com/hg/1.10.1-beta/com/google/api/client/auth/oauth2/AuthorizationCodeFlow.Builder.html#AuthorizationCodeFlow.Builder(com.google.api.client.auth.oauth2.Credential.AccessMethod , com.google.api.client.http.HttpTransport, com.google.api.client.json.JsonFactory, com.google.api.client.http.GenericUrl, com.google.api.client.http.HttpExecuteInterceptor, java.lang.String, java.lang.String) http://javadoc.google-oauth-java-client.googlecode.com/hg/1.10.1-beta/com/google/api/client/auth/oauth2/AuthorizationCodeFlow.Builder.html#getAuthorizationServerEncodedUrl() Java environments (e.g. Java 6, Android 2.3, App Engine, or All)? All Please describe the feature requested. Currently the authorizationServerEncodedUrl can only be specified in the builder. However, it is convenient to be able to extend AuthorizationCodeFlow and provide a default value, while still allowing users of that class to specify a different value, e.g. for testing. Similarly for clientId and clientAuthentication.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=50

From [email protected] on December 09, 2011 12:34:53

External references, such as a standards document, or specification? http://tools.ietf.org/html/draft-lodderstedt-oauth-revocation Java environments (e.g. Java 6, Android 2.3, App Engine, or All)? All Please describe the feature requested. Implement the specification for OAuth 2.0 Token Revocation. Example HTTP request:

    POST /revoke HTTP/1.1
    Host: server.example.com
    Content-Type: application/x-www-form-urlencoded
    Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

    token=45ghiukldjahdnhzdauz&

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=20

From [email protected] on March 25, 2012 04:39:08

Version of google-oauth-java-client (e.g. 1.5.0-beta)? 1.7 Java environment (e.g. Java 6, Android 2.3, App Engine)? Java 6, AppEngine,

Exception when trying to get a new AccessToken with a RefreshToken:

RefreshTokenRequest req = new RefreshTokenRequest(...);
TokenResponse response = req.execute(); throws the following Exception:
java.lang.NoSuchMethodError: org.apache.commons.codec.binary.Base64.encodeBase64String([B)Ljava/lang/String;
at com.google.api.client.http.HttpHeaders.setBasicAuthentication(HttpHeaders.java:590) How would you expect it to be fixed? Refactor the HttpHeaders class, include commons-codec.1.6.jar(this library has the encodeBase64String Method).
I have included this jar to my project, but with no effect!

Please fix this, its a major blocker for my project.

Cheers,
Arthur

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=30

From [email protected] on April 19, 2012 08:03:35

External references, such as a standards document, or specification? https://code.google.com/p/google-http-java-client/issues/detail?id=90 https://code.google.com/p/google-oauth-java-client/wiki/Setup https://code.google.com/p/google-oauth-java-client/source/browse/google-oauth-client-assembly/readme.html Java environments (e.g. Java 6, Android 2.3, App Engine, or All)? All Please describe the feature requested. The details are mostly the same as the google-http-java-client issue linked above. The only additional bit of info here is that we also have a J2EE servlet project, so that project is the one difference between J2SE and J2EE.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=33

From [email protected] on December 14, 2011 12:54:22

External references, such as a standards document, or specification? http://google-oauth-java-client.googlecode.com/files/google-oauth-java-client-1.6.0-beta.zip Java environments (e.g. Java 6, Android 2.3, App Engine, or All)? All Please describe the feature requested. Note that we are including a lot of dependencies in the "dependencies" folder in our zip file packaging. We need to review each dependency and ensure that:

1. We are legally allowed to redistribute it.
2. We are following the terms for redistributing it, especially with respect to including its license terms.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=21

From [email protected] on May 07, 2012 04:33:57

Reported by yanivi in https://code.google.com/p/google-http-java-client/issues/detail?id=101 :

readme.html says you need xpp3 for Android. That is incorrect and causes problems. In fact, XmlPullParser is already part of android.jar.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=37

From [email protected] on June 07, 2011 06:40:18

Version of google-api-java-client (e.g. 1.3.1-alpha)? 1.4.1-beta Java environment (e.g. Java 6, Android 2.3, App Engine 1.4.2)? ALL Describe the problem. The AssertionGrant constructor currently asks for a client id. The assertion grant flow does not require or support the notion of a client id. Relevant portion of the spec: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.1.3 How would you expect it to be fixed? Remove support for the client id.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=5

From [email protected] on May 30, 2012 09:23:01

External references, such as a standards document, or specification? http://javadoc.google-oauth-java-client.googlecode.com/hg/1.9.0-beta/com/google/api/client/auth/oauth2/CredentialStore.html Java environments (e.g. Java 6, Android 2.3, App Engine, or All)? All Please describe the feature requested. Unfortunately, it's going to be hard to implement FileCredentialStore because each of the methods require I/O access. We should really declare throws IOException on this for general use. That also means updating all of the callers.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=40

From [email protected] on July 12, 2012 13:40:49

External references, such as a standards document, or specification? http://javadoc.google-oauth-java-client.googlecode.com/hg/1.10.1-beta/com/google/api/client/extensions/appengine/auth/oauth2/AppEngineCredentialStore.html https://developers.google.com/appengine/docs/java/javadoc/com/google/appengine/api/memcache/MemcacheService Java environments (e.g. Java 6, Android 2.3, App Engine, or All)? App Engine Please describe the feature requested. Implement CachedAppEngineCredentialStore that extends AppEngineCredentialStore and uses com.google.appengine.api.memcache.MemcacheService to store credential information in the memcache.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=47

From [email protected] on March 21, 2012 07:48:34

External references, such as a standards document, or specification? http://javadoc.google-oauth-java-client.googlecode.com/hg/1.7.0-beta/deprecated-list.html Java environments (e.g. Java 6, Android 2.3, App Engine, or All)? All Please describe the feature requested. Remove some of the deprecated classes/methods/fields from version 1.7. See the reference above.

We will likely keep some of the deprecated methods, especially "com.google.api.client.auth.oauth2.draft10" to ease the transition to the new package "com.google.api.client.auth.oauth2". But others like "com.google.api.client.auth" probably have little usage (if any), and we would benefit from removing them.

Original issue: http://code.google.com/p/google-oauth-java-client/issues/detail?id=28