As part of salesforce.com's on going effort to ensure the highest level of security at Salesforce.com, we are discontinuing support for the Secure Socket Layer (SSL) protocols noted below on March 31, 2007. SSL is the protocol used to secure data in transit to and from Salesforce.com.

• SSLv2 - SSLv2 has known vulnerabilities which render it insecure for all purposes. It was superceded 10 years ago by SSLv3. Implementations of SSLv3 are widely and freely available for all common development platforms.
• SSLv3 and TLSv1 with key lengths less than 128 bits - For secure ciphers, the length of the key used by the cipher is proportional to the strength of the cipher. Due to advances in cryptography and computing power, key lengths lower than 128-bits are no longer considered sufficient for long term security.

This change may affect users accessing the system both via browsers and via an API client. We have analyzed our logs; we believe only a very small percentage of users will be affected. We have contacted all customers with integrations we believe may be impacted by this change.

For more information, please see our technical note on this change.  If you have any questions or need assistance planning your response to this change, please contact Salesforce.com Support.

Last weekend we deployed our Winter '07 release to production instances NA1 and NA0 (for a complete release schedule, see our blog).     We are currently tracking two issues:

1. XML/RPC API in Professional Edition -  Access is denied for Professional Edition Customers using partner applications that based on our XML/RPC interface.
2. getUpdated / getDeleted in pre-8.0 APIs - In our 8.0 API, we added a parameter (lastDateCovered) to the result for getUpdated / getDeleted.  This additional parameter is also appearing in results from older versions of our API when it shouldn't have.
   

We're planning to address both of these issues with an e-release tonight. 

As part of salesforce.com's on going effort to ensure the highest level of security at Salesforce.com, we are discontinuing support for the Secure Socket Layer (SSL) protocols noted below on March 31, 2007. SSL is the protocol used to secure data in transit to and from Salesforce.com.

• SSLv2 - SSLv2 has known vulnerabilities which render it insecure for all purposes. It was superceded 10 years ago by SSLv3. Implementations of SSLv3 are widely and freely available for all common development platforms.
• SSLv3 and TLSv1 with key lengths less than 128 bits - For secure ciphers, the length of the key used by the cipher is proportional to the strength of the cipher. Due to advances in cryptography and computing power, key lengths lower than 128-bits are no longer considered sufficient for long term security.

This change may affect users accessing the system both via browsers and via an API client. We have analyzed our logs; we believe only a very small percentage of users will be affected. We have contacted all customers with integrations we believe may be impacted by this change.

For more information, please see our technical note on this change.  If you have any questions or need assistance planning your response to this change, please contact Salesforce.com Support.

Last weekend we deployed our Winter '07 release to production instances NA1 and NA0 (for a complete release schedule, see our blog).     We are currently tracking two issues:

1. XML/RPC API in Professional Edition -  Access is denied for Professional Edition Customers using partner applications that based on our XML/RPC interface.
2. getUpdated / getDeleted in pre-8.0 APIs - In our 8.0 API, we added a parameter (lastDateCovered) to the result for getUpdated / getDeleted.  This additional parameter is also appearing in results from older versions of our API when it shouldn't have.
   

We're planning to address both of these issues with an e-release tonight. 

Lot's a great stuff came out of Dreamforce '09 about OAuth. In addition to vendors promoting OAuth on the expo floor, the Hackathon encouraged mash-ups using OAuth to integrate Salesforce with Facebook and Twitter.

 

But once a Facebook or Twitter identity is authenticated, how is the session to be maintained in Force.com Sites across page views?

 

A cookie seems like the obvious choice, but the AppExchange certification security review team has stringent guidance on use of cookies in apps.

 

Apex does not support cookies server-side, so is there a best practice for managing OAuth users in Sites that can be used in apps published to the AppExchange?

 

Thx!

 

-Mike

Has anybody succesfully used OAuth for obtaining a sessionId for use with the API in Winter '10?

 

I've been able to get so far as to generate a valid OAuth access token, but I haven't yet been able to use that access token to get an API session id and I suspect the documentation may not be accurate or complete.

 

A few observations I've made: 

 

• The documentation says the url is https://login.salesforce.com/services/OAuth/type/api-version.  Where type is "c" for the Partner WSDL and "u" for the enterprise WSDL.  This is the reverse of the normal SOAP API, and I assume it is a mistake, but can't verify since I can't get a session id.
• The documentation says that "authorization header must have the following parameters" when referring to the request to obtain the session.  I take this to mean that one must use the Authorization HTTP header and not POST parameters to obtain the session id.  However, I've not had success with either.
• If I do not use the authorization header and post the oauth parameters in the body, I get a response of LOGIN_OAUTH_INVALID_DSIG, indicating a bad signature.  Even though I'm using the same code to sign the request as I do for generating the request and access tokens.
• If I instead use the Authorization HTTP header I get the error LOGIN_OAUTH_METHOD_NOT_SUPPORTED indicating I must use http POST, even though I already am.  Note, in this case the post body is empty.

 

Thanks,

 

George

 

Hi,

 

Is there a library or implementation of OAuth protocol using Apex?

 

I'm writing OAuth Consumer using Apex and Visualforce pages but faced several issues:

 

  * HTTP Redirect function, message-passing using HTTP header etc.

  * Session management (Cookie, Session ID, Session Object etc.)

  * Nonce generation

 

I appreciate your help.

 

Thanks.

 

The whole purpose of using a web-based CRM is that it's available to use anywhere you can use the internet. Unfortunately SFDC changed the rules on us SEVERELY limiting it's utility while still charging the same.

I thought that I'd have to go through the Challenge process once to authorize my laptop.  Unfortunately, using  my Verizon wireless card  (or using any wifi service on the road, ie Starbucks, etc) you'll have to do this every time you want to log-on.  And, by the way, I have no way to access my corporate email on my laptop, so the Challenge email goes to my office computer, not my laptop. 

This is totally unacceptable

I would be willing to validate each new computer once.  There should be a way to authorize the machine (ie home computer, or laptop) once and only once.  A RSA keyfob, or Bloomberg fingerprint validator, or downloaded software application (I know, I know - "no software!")  would all be acceptable, but it seems like SFDC is trying do this on the cheap

Finky

Has anyone ever had problems generating correct java stub classes with WebLogic's 8.1 "clientgen" appliation and the Partner WSDL?

Here's the error message that we're encountering:

generate-client:

[clientgen] Generating client jar for d:\temp\salesforce\partner.wsdl ...

[clientgen] WARNING: Unable to fully map ['urn:sobject.partner.soap.sforce.com']:sObject using javax.xml.soap.SOAPElement
…<many more similar warnings> 

The sObject definition in the partner.wsdl has:
           <complexType name="sObject">
                <sequence>
                    <element name="type" type="xsd:string"/>
                    <element name="fieldsToNull" type="xsd:string" nillable="true" minOccurs="0" maxOccurs="unbounded"/>
                    <element name="Id" type="tns:ID" nillable="true"/>
                    <any namespace="##targetNamespace" minOccurs="0" maxOccurs="unbounded" processContents="lax"/>
                </sequence>
            </complexType> 

I think that “<any>” tag is only supported in JAX-RPC Spec 1.1 (at least that’s what this thread implies: http://forums.bea.com/bea/message.jspa?messageID=400007979&tstart=60 ). And to get support for JAX-RPC Spec 1.1, we’d have to upgrade to Weblogic 9.X, which is not currently an  option.

There is a new user showing up through the API, but not visible in the UI.

(This can be recreated via sforce explorer)

If I query the user list via the webservice, I get all my regular users, but now I am getting an additional on.  Its name is "Salesforce Administrator".  It says it was just created 8/3/07 (even though I have had my account for well over a year).  It has a license type of "BlackTab User". 

Can anyone help me out with what this user is?  And, is there an easy way to filter it out of my query?  (I want to be able to only get users that are available in the UI in my query).

Thanks

I start using Tibco BW 5.4 to integrate the SalesForce.  When I make the login and going to query the Account table.  I have got the following error about SSL:

BW-HTTP-100300 An IOException was thrown while trying to execute the Http method
caused by: java.io.IOException: Fatal SSL handshake error: java.lang.RuntimeException: Unable to create cipher AES/CBC/NoPadding: java.security.InvalidKeyException: Illegal key size

I have checked the previous post about "Ending Support for Weak Versions of SSL". Could anyone show me how to get it work, or have you experienced the similar problem on development?

Alex

Hi!

Any impact on PHP?

Support Ending for Weak Versions of SSL

PHP versions 4-5 with Salesforce API 5-8?

As part of salesforce.com's on going effort to ensure the highest level of security at Salesforce.com, we are discontinuing support for the Secure Socket Layer (SSL) protocols noted below on March 31, 2007. SSL is the protocol used to secure data in transit to and from Salesforce.com.

• SSLv2 - SSLv2 has known vulnerabilities which render it insecure for all purposes. It was superceded 10 years ago by SSLv3. Implementations of SSLv3 are widely and freely available for all common development platforms.
• SSLv3 and TLSv1 with key lengths less than 128 bits - For secure ciphers, the length of the key used by the cipher is proportional to the strength of the cipher. Due to advances in cryptography and computing power, key lengths lower than 128-bits are no longer considered sufficient for long term security.

This change may affect users accessing the system both via browsers and via an API client. We have analyzed our logs; we believe only a very small percentage of users will be affected. We have contacted all customers with integrations we believe may be impacted by this change.

For more information, please see our technical note on this change.  If you have any questions or need assistance planning your response to this change, please contact Salesforce.com Support.

My application is a hyprid application with parts running inside web tabs.  Those parts run on my servers and have a session associated.

What I would like to be able to do is to be notified when the user logs out of Salesforce so I can invalidate his session on my servers.

There was one post that mentionned a logoutURL, but I get the impression that its use is when using an SSO that logs into Salesforce, as opposed to my case where Salesforce servers as the SSO. 

Is this possible?

Thanks.

Hi,
         I know you can query the values from a picklist via API, and create new picklist values via API, but is it possible to update / delete values in a picklist via API? Thanks!

Hello,

I looking for some clarification the following requirement listed in the API 8.0 guide for utilizing Outbound Messaging:

• If you use SSL, you must use port 443, and you must have a real certificate. If you certificate expires, message delivery will fail.

I have the following environments:

Development:
Windows XP Professional with IIS 5.0.

Production:
Windows Server 2003, IIS 6.0

I am looking for guidance on how to set up the required certificate for both of the environments. Any advice or pointers to online resources in appreciated.

Hi there

I have added a custom autoincrementing field ({c__CustAccountNumber}) to our account object to continue the account numbering system established by our previous CRM product. We have a number of other applications that rely on this number to identify an account and don't want to redevelop them to use Salesforce internal IDs.

Can I construct a salesforce.com URL which will enable me to (assuming the user is logged into SF) locate a particular account through this custom field? I know I can find a record by SF ID:

    https://emea.salesforce.com/0012000000xxxxxx

but that's no good as our other apps don't know these numbers. Something like:

    https://emea.salesforce.com/search?c__CustAccountNumber=123456

would be great.

Using our own ID in the advanced search will find the record but depending on the data may match more than one. I'd be happy if I could restrict the search to {c__CustAccountNumber} but this doesn't seem possible in Professional edition.

Will API access allow me to search on custom fields? If so, I could write a widget to search based on this field and return a link to the object's SF ID.

Thanks,

Mark