Closed jtesser closed 11 years ago
Dean Jose would be the guy to help us doc and get this ready for QA
This plugin can set connections to a Salesforce Server, retrieve roles keys stored on a field and sync the roles for the logged-in user. This is made by using OAuth 2.0 User-Password flow as authorization method, where Salesforce assigns an access token to the current user session. This access token is required for getting information from Salesforce server.
Please see for more info https://help.salesforce.com/help/doc/en/remoteaccess_oauth_username_password_flow.htm
This plugin works for frontend and backend login. Also, it overrides /html/portal/login.jsp file with a custom one that hides the "Forgot Password" link.
Notes:
1) Frontend/Backend login must be set to email address.
2) SSL for Tomcat must be enabled. OAuth 2.0 works only with https connections.
Please see for more info http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html
3) Salesforce integration works the same way than CAS/LDAP integration. A dummy password is saved in our database, since auth is handled directly in Salesforce. There is no way to pull the Salesforce password for any user. Also our "Forgot Password" feature is disabled so in case an user can't login, it's up to Salesforce admins to handle this tipe of issue. Additionaly, a Salesforce user must be created for binding dotCMS with Salesforce. To make a successfull binding, we require from this user:
a) Email. b) Password. c) API Security Token.
Please see this wiki for more info about how it works
https://help.salesforce.com/help/doc/en/remoteaccess_oauth_username_password_flow.htm
4) Salesforce REST API works with Callback URLs. In order to set a redirect after login in Salesforce, we need to add at least two (2) Remote Access in Salesforce, that will handle both frontend (/dotCMS/login) and backend (/admin or /c) login.
For creating a Remote Access in Salesforce, please take a look at this wiki http://wiki.developerforce.com/page/Getting_Started_with_the_Force.com_REST_API
Each Remote Access will generate a Client Id and Client Secret codes. These codes are required and it must be set in src-conf/dotmarketing-ext.properties file (please see item 4 of this doc). Also, the Callback URLs are set as redirect urls for frontend and backend in the same properties file.
5) Data retrieved from Salesforce is in JSON format. Although the output can be sent from Salesforce in XML, the default format is JSON and the code is built to handle only JSON objects sent from Salesforce.
6) In src-conf/dotmarketing-ext.properties file, this variable must be set to true:
SALESFORCE_LOGIN_FILTER_ON=true
The Dynamic content path variable must be set to the actual dotsecure folder.
DYNAMIC_CONTENT_PATH=dotCMS/dotsecure
Also these variables are required
7) This filter and its filter mappings are required in dotCMS/WEB-INF/web.xml file
8) Salesforce roles must be created by a dotCMS Admin on the Roles, Tabs & Tools Portlet. Both role name and key should match the Custom Field values on Salesforce. Also, for avoiding issues after login, we recommend to assign at least one tab/permission to these Salesforce Roles.
9) All Salesforce auth activity is stored in tomcat/logs/userActivity.log file.
A couple of things -
1) we should not use config variables for things that won't change, for example:
#salesforce_search_object_fields=FirstName,LastName,Email,ContactId
or
#salesforce_return_format=json
If we are not going to change it or the code will not work with a different config, do not make it configurable. If you feel strongly that it should be configurable see #2 below.
2) Intelligent Defaults Whenever calling the Config.java to get a config variable, make sure to set the correct default value so configs that do not have that variable will still work - or we can just exclude it from the standard config.
Every Config.get can take a second parameter that will be returned as the default if the property is not found. We do not want to fill up our dotmarketing-config.properties with config variables that only apply to a tiny percentage of our users.
So, for example, in the login.jsp, we do a:
Boolean.valueOf(Config.getStringProperty("SALESFORCE_LOGIN_FILTER_ON"));
We should do a :
Config.getBooleanProperty("SALESFORCE_LOGIN_FILTER_ON", false);
I will fix this on master.
Thanks, Jason S. Tesser Director, Support Services dotCMS, Inc. T: 305.858.1422 x7003 http://twitter.com/dotCMS www.dotcms.com
On Fri, Feb 1, 2013 at 3:08 PM, Will Ezell notifications@github.com wrote:
A couple of things -
1) we should not use config variables for things that won't change, for example:
or
``` #salesforce_return_format=json
If we are not going to change it or the code will not work with a different config, do not make it configurable. If you feel strongly that it should be configurable see #2 below.2) Intelligent Defaults Whenever calling the Config.java to get a config variable, make sure to set the correct default value so configs that do not have that variable will still work - or we can just exclude it from the standard config.
Every Config.get can take a second parameter that will be returned as the default if the property is not found. We do not want to fill up our dotmarketing-config.properties with config variables that only apply to a tiny percentage of our users.
So, for example, in the login.jsp, we do a:
Boolean.valueOf(Config.getStringProperty("SALESFORCE_LOGIN_FILTER_ON"));
We should do a :
Config.getBooleanProperty("SALESFORCE_LOGIN_FILTER_ON", false);
— Reply to this email directly or view it on GitHubhttps://github.com/dotCMS/dotCMS/issues/1644#issuecomment-13011680.
I had a question about this plugin. At some point, our group will be integrating with Salesforce, but only in that we will be retrieving content from salesforce using web services. We have already built 'proof-of-concept' that pulls content using the services they have made available.
We will not need to use their users/passwords/etc to log in, which sounds like what this plugin does (similar to dotCMS ability to integrate with LDAP). Am I correct in assuming that this plugin might be overkill? Could we reuse pieces of this plugin?
primarily this is for authentication and authorization. There are examples in this plugin to connect to sales for but it is not for what you are intending to do
Great. Thanks for the clarification!