Whenever a node is saved that is mapped to an object in Salesforce, sometimes this error is thrown:
Message SalesforceException: </BR></BR></BR><font color="blue">Redirecting in just a second.</font></BR><a href="../apex/SFSSDupeCatcher__SFSSDupeCatcher?dId0=MDBRaTAwMDAwMEMxZzVpRUFC&scId=YTE3aTAwMDAwMDB6Z1FoQUFJ&userAction=NA%3D%3D&sourceFieldLabels=RW1haWw%3D&targetFieldLabels=RW1haWw%3D&oneTimeKey=MTM5NzEzODg5ODI2Nw%3D%3D">Click here for manual redirect.</a><br/><SCRIPT>window.location = "../apex/SFSSDupeCatcher__SFSSDupeCatcher?dId0=MDBRaTAwMDAwMEMxZzVpRUFC&scId=YTE3aTAwMDAwMDB6Z1FoQUFJ&userAction=NA%3D%3D&sourceFieldLabels=RW1haWw%3D&targetFieldLabels=RW1haWw%3D&oneTimeKey=MTM5NzEzODg5ODI2Nw%3D%3D";</SCRIPT> in Salesforce->apiCall() (line 104 of sites/all/modules/salesforce/includes/salesforce.inc).
This results in the User getting redirected to the following URL (404):
http://example.com/apex/SFSSDupeCatcher__SFSSDupeCatcher?dId0=MDBRaTAwMD...
How do we stop Salesforce from returning HTML in an error message that is then redirecting the user to a 404 page?
I cannot provide steps to reproduce this error as it seems to be specific to this content / object.
Thanks!
Comments
Comment #1
davidwbarratt commentedComment #2
davidwbarratt commentedIt appears this problem is result of using DupeCatcher with Drupal.
It looks like the Salesforce Module is throwing this Exception:
http://drupalcode.org/project/salesforce.git/blob/HEAD:/includes/salesfo...
Since DupeCatcher is returning html rather than a string, and Drupal is printing the string to the page (HTML is not sanitized since it's not expected). The user is unexpectedly redirected to a 404 page.
Should DupeCatcher return a plain-text string or is it acceptable to return HTML? If it's acceptable to return HTML, should the Salesforce Module sanitize what is returned with check_plain()?
Thanks!
Comment #3
gcbWell, I want to blame the Salesforce app, but checking for valid error messages is probably reasonable if this is a possibility.
Please try out the attached patch and let me know if it helps.
Comment #4
aaronbaumanThis patch is out of date now, but the point is still relevant.
However, I think you should strip HTML from these exceptions before showing them to the user, not when throwing the exception. The caller should not assume that the exception message is appropriate to show users.
e.g. sanitize in salesforce_set_message(), not salesforce.inc
Comment #5
mariacha1 commentedAttached patch takes care of check_plain at the display-message level.
Comment #6
mariacha1 commentedNope, that won't work. It's double-escaping already-translated errors. So, we can either never send items wrapped in t()s to that function, or we need to do something more tricky.
Comment #7
aaronbaumanYou're right - the issue is inconsistent use of salesforce_set_message().
Sometimes we're sending raw strings from exceptions or from SF, and sometimes we're sending already-translated strings.
I think, to match drupal_set_message(), the message sent to salesforce_set_message() should already be translated.
This implies a more extensive change, wherever salesforce_set_message is invoked.
Comment #8
aaronbaumanaforementioned patch.
- Make consistent use of salesforce_set_message: do not send un-translated strings.
- Update documentation for salesforce_set_message
Comment #10
mariacha1 commentedWorks great. Thanks aaronbauman!