Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Force.com API in Scribe-Java #194

Closed
wants to merge 1 commit into from
Closed

Conversation

tkral
Copy link

@tkral tkral commented Nov 21, 2011

Hi Pablo,

Here is an API implementation for the Force.com OAuth handshake. You'll notice that I extended the Token class because Force.com returns extra information in its token that needs to be extracted and provided to the developer. In order to not clutter up your code, I included everything in the same file.

Also, you'll probably notice that a salesforce.com copyright is included in the header. This is the result of a month long fight with lawyers (argh....). I'm hoping it's acceptable to you because it's only included in the one API file and not in any of your core infrastructure. If not, I completely understand. Please let me know if you have a problem with the copyright stuff because that would be good feedback.

Thanks.
-Tim


private final ForceInstanceType instanceType;

public enum ForceInstanceType
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Multiple Endpoints for one Api are allowed, but I'd like to maintain the style of other Apis, see for example Twitter:

https://github.com/fernandezpablo85/scribe-java/blob/master/src/main/java/org/scribe/builder/api/TwitterApi.java#L29

You can do TwitterApi.class or TwitterApi.SSL.class

Same would apply here, but you would have 3:

ForceApi.class

ForceApi.Sandbox.class

ForceApi.PreRelease.class

@tkral
Copy link
Author

tkral commented Dec 13, 2011

Is the ForceToken class ok to leave as an inner class in ForceApi?

@fernandezpablo85
Copy link
Collaborator

I thought about that, there's no natural home for it. Is it really
necessary?

On Mon, Dec 12, 2011 at 9:19 PM, Tim Kral <
reply@reply.github.com

wrote:

Is the ForceToken class ok to leave as an inner class in ForceApi?


Reply to this email directly or view it on GitHub:

#194 (comment)

@fernandezpablo85
Copy link
Collaborator

Actually it is not necessary. People can extract extra data from
rawResponse() on the Token class.

On Tue, Dec 13, 2011 at 12:10 AM, pablo fernandez <
fernandezpablo85@gmail.com> wrote:

I thought about that, there's no natural home for it. Is it really
necessary?

On Mon, Dec 12, 2011 at 9:19 PM, Tim Kral <
reply@reply.github.com

wrote:

Is the ForceToken class ok to leave as an inner class in ForceApi?


Reply to this email directly or view it on GitHub:

#194 (comment)

@tkral
Copy link
Author

tkral commented Dec 13, 2011

Actually, it would be nice to keep the ForceToken because it includes instance information that will be used in all subsequent API calls. For example:

ForceToken forceToken = (ForceToken) forceOauthService.getAccessToken(null, verifier);
...
OAuthRequest oauthRequest = new OAuthRequest(Verb.GET, forceToken.getInstanceUrl() + "/services/data" + uri);

Without this, each caller will always have to parse the raw response.

@fernandezpablo85
Copy link
Collaborator

I see your point. But also the reason why Token has a rawResponse is to
show that the responsibility of parsing extra parameters is on the client
side, not on Scribes.

You'll understand that this can get messy fast, if every provider includes
its own Token class. Sorry.

Pablo

On Tue, Dec 13, 2011 at 1:51 PM, Tim Kral <
reply@reply.github.com

wrote:

Actually, it would be nice to keep the ForceToken because it includes
instance information that will be used in all subsequent API calls. For
example:

ForceToken forceToken = (ForceToken)
forceOauthService.getAccessToken(null, verifier);
...
OAuthRequest oauthRequest = new OAuthRequest(Verb.GET,
forceToken.getInstanceUrl() + "/services/data" + uri);

Without this, each caller will always have to parse the raw response.


Reply to this email directly or view it on GitHub:

#194 (comment)

@kingsob-zz
Copy link

any chance of getting this api added? I am very interested in a salesforce api.

@KoenVM
Copy link

KoenVM commented Nov 20, 2012

It would indeed be nice if this was added.

@rsshilli
Copy link

+1, please add this in.

@fernandezpablo85
Copy link
Collaborator

the collaborator seems to be unresponsive to feedback.

On Fri, Jan 11, 2013 at 3:58 PM, rsshilli notifications@github.com wrote:

+1, please add this in.


Reply to this email directly or view it on GitHubhttps://github.com//pull/194#issuecomment-12158299.

@rsshilli
Copy link

I made the code changes you requested here: rsshilli@4f043e3

I agreed with all of your comments except perhaps creating a custom ForceTokenExtractor. That probably could have been just an inline class since it's not going to be used by other OAuth providers. I don't care that much though, so I followed what you asked for and made it separate.

@lcheng1982
Copy link

Hi, guys
I write one test case to get access token from salesforce with this impl, the result is that I can get the authorization code, but when I try to get access token, I always get following error
Exception in thread "main" org.scribe.exceptions.OAuthException: Cannot extract a Force.com acces token. Response was: {"error":"invalid_grant","error_description":"invalid authorization code"}
at org.scribe.builder.api.ForceDotComApi$ForceDotComTokenExtractor.extract(ForceDotComApi.java:209)
at org.scribe.oauth.OAuth20ServiceImpl.getAccessToken(OAuth20ServiceImpl.java:37)
at test.SalesforceExample.main(SalesforceExample.java:55)

What could be the cause of this issue? Thanks.

@fernandezpablo85
Copy link
Collaborator

"invalid authorization code" pretty much says it all. Also, please create a ticket for support instead of commenting on dead pull requests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants