1

I'm looking into possible ways to control and monitor data leaving our Salesforce Org. Currently solutions appear to fall into two broad categories:

  1. Lock down features for users using profiles. E.g. Prevent certain kinds of users from having reporting, or exporting rights

  2. Have third party monitoring software installed on work machine which monitor and control interactions with salesforce.com

Neither of these suits our requirements. Our problem is with users who need to be able to run and extract reports but doing so from some internet cafe. We also can't restrict them to work machines as a lot of them are travelling salespeople.

Furthermore, salesforce have said they don't provide any kind of report on what reports have been run, or what data exported.

I'm investigating the third possibility which is bolt some sort of monitoring JS code onto salesforce.com itself. If possible, I'd like to embed JS on the salesforce Report tab (and any other page where data can be exported) and intercept clicks to the "Run Report" or "Export" buttons. I'd call a logging web service with the user's name, the report parameters, time etc.

Does anyone know if it's possible to embed custom JS on salesforce pages? Or any neater solution to the above?

Thanks for your help

Ray

Ray
  • 3,188
  • 8
  • 23
  • 27

3 Answers3

1

Salesforce is very protective of their code base, to that degree that even custom Apex code runs on a completely different domain so that they can use cross-domain scripting to prevent us from tweaking their pages :) So unless a man-in-the-midddle SSL attack is used there is no way to inject something in their code.

Maybe a grease monkey script? But users could remove them or just use another browser.

I do not think you have an ideal solution here other than security, either profile (object level) or sharing (row level). Think of it this way, someone keen on stealing data could just grab HTMLs of detail pages of rows participating in report, grabbing raw data from HTML and running reports externally. Maybe force traveling salespeople to use RDP to office located machines?

mmix
  • 5,458
  • 2
  • 34
  • 60
  • Thanks. I think grease monkey would be useful only if we could restrict the machines that users used. And if that was the case, we'd probably go for a more out-of-the-box monitoring solution, since we could install it on all local machines. Embeding JS would I think be the only way to add a feature regardless of where our users login from. I really can't fathom why Salesforce doesn't log reports and file exports so administrators can monitor them. – Ray Feb 13 '12 at 10:54
  • becuase it just gives you a false sense of security. If you have read access to the object and sharing is not restricting you can create a custom view for any object and just extract data from the received HTML. If you can use WSDL, it even more straightforward. I demonstrated that to my guys who were having the same ideas about auditing. And if you want to audit every time someone opens a list of accounts in salesforce the sheer amount of log data will make any security inquiry pointless. – mmix Feb 13 '12 at 12:53
  • yes true. I suppose the only air-tight way is to restrict users to certain machines which have appropriate data-loss software. We were aiming for a middle approach of just monitoring less technically savvy users and seeing what they were downloading through the standard features. – Ray Feb 13 '12 at 14:15
  • re your RDP suggestion. Do you have any experience of locking users to particular machines. Obviously trusted IP ranges aren't going to work for travelling users. I was thinking of some sort of SSO which would only work from our machines / laptops we give them. That should be more light-weight than a full RDP session while they browse? – Ray Feb 13 '12 at 14:18
  • thats exactly why rdp is used. one of my clients keeps their salesforce instance network restricted to IPs in their offices. Those who travel use RDP (rdp login to an office server whose IP is allowed on salesforce). That virtual machine in the office is where you can place any auditing you deem neccessary. – mmix Feb 13 '12 at 14:47
  • Thanks. Do you find the browsing experience doesn't degrade too much though? I'm thinking of salesmen with a ropey connection / mobile connection having to bounce their traffic through London before hitting the salesforce servers. Is there a way to authenticate the machine they're using with salesforce.com directly? Having just SSO basically does this I think as the only non-salesforce.com traffic required is the initial authentication - so I think it would be faster / smoother for them? – Ray Feb 14 '12 at 12:27
  • well, truth be told even with compression the rdp is not the same as local desktop, theres no avoiding that. However, web in its nature has lags and salesforce pages are far from "skinny" so a ropey connection would impact the HTML download just as much as a compressed pixels stream from rdp. No help there really, other then equipping sales guys with 3G dongles and paying for a decent bandwidth with MobCo. – mmix Feb 14 '12 at 12:37
  • btw, authenticating external machines is possible, security token is used for those. However that does not solve your initial problem of keeping a lid on data. – mmix Feb 14 '12 at 12:42
0

To embed javascript in a standard SFDC page go to "Your Name" => "Setup" => "Customize" => "Home" => "Home Page Components" => Click the edit link next to "Messages & Alerts". In the "Edit Messages and Alerts" page there is a text area that you can paste javascript code that will be excecuted on almost every salesforce page.

Here are a few notes when doing this

  • Do not put empty lines in your code because the system will add a p html tag in it.
  • Use absolute references to your Salesforce pages because managed packages have a different url structure.

I'm not sure how much longer salesforce will allow this but it currently works.

For more info see http://sfdc.arrowpointe.com/2011/11/18/email-autocomplete-using-jquery/

Slightly different way of doing it https://salesforce.stackexchange.com/questions/482/how-can-i-execute-javascript-on-a-sfdc-standard-detail-page

Community
  • 1
  • 1
cby016
  • 593
  • 1
  • 4
  • 8
0

Another option would be to make a subset of your reports info visualforce pages (write out the SOQL and apex needed to gather the data, then write VF markup to display it) and then log and/or restrict who can access those pages and when (including checking the source IP). There's clearly some serious effort involved in moving more complex reports over to this format, but it's the only way I can think of meeting your requirements.

This would also allow you to not include any sort of export options, although they could of course save the raw HTML of the page if they really wanted to.

ca_peterson
  • 224
  • 2
  • 10
  • Thanks for the input. We'll need the full ability of the current reports page unfortunately. Even if disabling the report / export button were possible with JS, it would need to be done on a location aware basis (ie disable if logging in from a non trusted IP) which I just don't think is going to be possible (how would we expose the user's IP to the JS? Use some webservice to check if they're at an ok location? It seems more and more like a maintenance nightmare). Having read mmix's reponse I'm convinced it's best to restrict users to work machines. – Ray Feb 14 '12 at 12:36