2

I am following up the post here: REST API without Connected App

Although the answer was very helpful, I'm new to SF and need some clarity on some things:

1. How and why can a separate (free developers) environments client_id and secret provide a connection for an organization's environment?

My current thought is that this just provides the connection to Salesforce so that you can get a request_token (serving as the Authorization server role described here) that can then used by the application (in my case a WordPress plugin using the Username-Password flow), to request an access_token. This is all new and very theoretical though so I appreciate any details

2. How do I create the managed (or can it be unmanaged) application and namespace?

I created an application, and then I created an connected application in my org's sandbox, was that unnecessary? From the previous response it seems I need a managed package, is that as simple as firing up a developer edition specific to this Salesforce API connector application for WordPress I'm working on? Then do I just create a "connected application" within there?

3. How does deployment work?

*From there is just a matter of activating my WordPress plugin and authenticating with an API user credentials for any org I want? Nothing more required within the org itself? Adding remote site or approving some IP, anything?

NOTE If you needed more information or are interested in seeing the full scope of what I'm attempting with the Salesforce API Connector for WordPress you can keep up with its development status here

|improve this question
2

The client_id simply identifies your app uniquely. This allows your app to have a session that can be independent of a user's browser or generic API login. It also allows administrators to uniquely limit access to your app without disabling API access to users, and users can revoke access to your app without having to deactivate all other apps, too. The connected app identifies the purpose of the login request.

The app doesn't need to be installed in the other org, because it automatically installs the first time it is granted access. Admins can view app usage and revoke access or block the app entirely at any time. Also, blessed apps can use the API in orgs that don't normally have API access, such as professional edition orgs.

You only need a connected app to exist. It doesn't need to be managed unless you intend to have it blessed. A blessing occurs after a security review to make sure your app can't be easily compromised, such as for ISV partners that need API access for a mobile app.

All normal rules for authentication apply, except possibly IP restrictions. The login occurs as if from your app's IP address, so IP restricted users may need to have administrators configure your app's settings in their org before it will work for those users. Usually, relaxing IP requirements in the app settings is the only configuration admins may need in their org.

The network access list does not play a role in granting access to the app, although users may need to go through two factor authentication as a matter of logging in if their browser isn't recognized.

|improve this answer
  • Helpful information. What do you mean by connected application being "blessed", is that figure of speech for approval in appexchange? Can you include details or outline about how to properly setup a managed application. Also I added a link in my question that outlines specifically what I'm attempting. Thanks again @sfdcfox you've been very helpful since I've started SF development – Xtremefaith Nov 20 '14 at 20:58
  • I'm still not sure what you mean by an application being "blessed" can you please clarify? Also could use some guidance on beginning this process, do you know of any tutorial links? – Xtremefaith Nov 24 '14 at 22:15
  • 1
    @Xtremefaith To get started, you'll need to become an ISV partner. It's been a while since I've had to even look at the process, but it appears that you'll start here. You need to become a partner before you can gain access to all the features that partners get. Use your primary organization as your partner organization to get started. Everything else you need will be given to you at the appropriate times. The procedures change from time to time, so best to get it direct from the source. – sfdcfox Nov 25 '14 at 7:41
  • 1
    @Xtremefaith If you're releasing the source, you don't want your client ID floating around, because if someone does Something Bad with your client ID and gets it banned, all other users will be affected. On the other hand, this may be useful in case something is wrong with YOUR plugin and you need to identify everyone using your connected app. Personally, I'd recommend that you let each organization determine if they want to take the risk or be able to use their own settings. Also, I'd strongly recommend avoiding username-password flow, because that means you have... – sfdcfox Dec 2 '14 at 8:05
  • 1
    ...to store the password somewhere, and if it's not encrypted and secured, it could be a big risk to users of your software. Go with the Web Server flow, which is just as easy and can have perpetual access to an org via refresh tokens, even if the username or password for the org changes (but not if the user is deactivated entirely). You really wouldn't want to have to keep logging in every few hours with a password, and have to build additional modules to notify users when the password changes, etc. Just remember you need to keep the refresh token secure, as you would a password. – sfdcfox Dec 2 '14 at 8:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.