53

Normally, you can put debug monitoring on a user by name to see the details on the error they're getting (especially for the non-descript Error Loading a Visualforce Page).

But when you are trying to debug a site page, how do you get a debug log for the guest user?

Update

As of Spring '18 Salesforce has dropped the requirement to include the debug_logs cookie to get debug logs for the force.com site requests.

In Winter ’17, we introduced a change that required guest users to set browser cookies to activate debug logging. We had the best of intentions: All your public site visitors share one guest user license. Thus, when you enable logging for the guest user, the visitors’ collective activities can fill your debug logs quickly, hitting the log-size limit and causing log truncation. Sadly, people didn’t like the Winter ’17 change. Setting cookies is complicated, and the change made collecting debug logs for public users’ asynchronous activity impossible. We’ve seen the error of our ways. Your public users no longer need a debug_logs browser cookie to trigger logging. This change applies to both Lightning Experience and Salesforce Classic.

https://releasenotes.docs.salesforce.com/en-us/spring18/release-notes/rn_forcecom_debugging_guest_user.htm

89

Go to Monitoring>Debug log.

Where you would normally put the username, put the name of the Site.

For example: If your site is called MySite, enter MySite as the user name. Shockingly undocumented, but this gives you the debug you're looking for.

ATTENTION:

Winter17 is making a change to this--you'll now need to ALSO set a specific cookie in the guest user's browser to enable this.

https://releasenotes.docs.salesforce.com/en-us/winter17/release-notes/rn_forcecom_debugging_guest_user.htm#rn_forcecom_debugging_guest_user

Related Idea Exchange Idea for Integrations

The requirement for such a cookie is incompatible when building web-hook services for 3rd parties, there is an Idea Exchange post here to provide an IP whitelist as an alternative.


Update from Spring '18 release notes:

In Winter ’17, we introduced a change that required guest users to set browser cookies to activate debug logging. We had the best of intentions: All your public site visitors share one guest user license. Thus, when you enable logging for the guest user, the visitors’ collective activities can fill your debug logs quickly, hitting the log-size limit and causing log truncation. Sadly, people didn’t like the Winter ’17 change. Setting cookies is complicated, and the change made collecting debug logs for public users’ asynchronous activity impossible. We’ve seen the error of our ways. Your public users no longer need a debug_logs browser cookie to trigger logging. This change applies to both Lightning Experience and Salesforce Classic.

13
  • Thats true, I was surprised about the same :) Sep 5 '12 at 5:04
  • 3
    Worth noting here that it's the Site Name field (which you mention name in the answer) and not the Site Label, so if your Site Label is "My Great Site" the value to put in the debug log would be the Site Name "My_Great_Site". Sep 5 '12 at 11:43
  • 6
    One other method to determine the name of the Username of the anonymous/guest user is through this path: Setup > Develop > Sites > [click on site label] > Public Access Settings (button) > Assigned Users (button)
    – Mark Pond
    Dec 11 '12 at 18:47
  • 1
    +1 For mentioning the Winter17 change Salesforce own docs did not mention it
    – Halfwarr
    Oct 17 '16 at 19:41
  • 2
    Sadly, I have tried this in 5 different orgs and have yet to be able to get a debug log using the methods described. Also, had not idea it was so difficult to create a cookie manually.....Can anyone confirm it is indeed working?
    – Eric
    Oct 19 '16 at 13:24
13

Adding to Shane's answer-

The release notes which were linked to above include specific instructions for setting the cookie in Chrome, but not in Firefox. Here's one way of doing it in Firefox:

  1. Install the Cookies Manager+ add-on
  2. Create a cookie that looks like this: enter image description here
3
  • @Martha - Where does it speak abut how to do it in Chrome? I did not see it anywhere
    – Eric
    Oct 21 '16 at 7:39
  • 1
    Its in the help article help.salesforce.com/apex/… Oct 21 '16 at 23:40
  • For me, it didn't work without including the debug_logs in the Content section.
    – Nick Cook
    Oct 26 '16 at 4:17
12

Chrome & Edge

The above answers are not so clear instructions for winter 17 release .For winter 17 release open the public site first by clicking on the links in the Develop | Sites | Site

And once you are in the site, use Chrome developer console or Edge developer console and key in below

document.cookie ="debug_logs=debug_logs;domain=.force.com";

The help article does a good job of explaining this.

3
  • thanks. i will try this out...this should have been in the release not one would think
    – Eric
    Oct 22 '16 at 5:24
  • The link you posted "help.salesforce.com/apex/…" is no longer working
    – compski
    Oct 17 '17 at 1:59
  • @compski Thank you ! SFDC broke it and I have fixed it !! Oct 17 '17 at 4:19
6

Update

This is no longer needed as of Spring '18

In Winter ’17, we introduced a change that required guest users to set browser cookies to activate debug logging. We had the best of intentions: All your public site visitors share one guest user license. Thus, when you enable logging for the guest user, the visitors’ collective activities can fill your debug logs quickly, hitting the log-size limit and causing log truncation. Sadly, people didn’t like the Winter ’17 change. Setting cookies is complicated, and the change made collecting debug logs for public users’ asynchronous activity impossible. We’ve seen the error of our ways. Your public users no longer need a debug_logs browser cookie to trigger logging. This change applies to both Lightning Experience and Salesforce Classic.

https://releasenotes.docs.salesforce.com/en-us/spring18/release-notes/rn_forcecom_debugging_guest_user.htm?edition=&impact=

Original

For API requests, i.e. webhooks, your only real option is a proxy to set this cookie.

I've got a node proxy working in our sandbox. I've made the repo public

var httpProxy = require('http-proxy');
var express = require('express');
var apiProxy = httpProxy.createProxyServer({target: process.env.TARGET, changeOrigin:true});
apiProxy.on('proxyReq', function(proxyReq, req, res, options) {
  proxyReq.setHeader('Cookie', 'debug_logs=debug_logs,domain=.force.com');
});
var addDebugCookie = function(req, res) {
  apiProxy.web(req, res);
};
var server = express();
server.all('/*', addDebugCookie);
var port = process.env.PORT || 5000;
server.listen(process.env.PORT || 5000)

Planning on setting this up on Heroku and then running all our webhook callbacks through this so we can turn on debug logs when something misbehaves.

UPDATE - we've started using this in production and everything is working fine so far, high level setup was:

  • create a heroku app (or any other node.js hosting provider)
  • deploy code to it
  • set TARGET environmental variable to your force.com site
  • update any callouts to use proxy url instead of force.com sites url
1

Another alternative to add cookies

Use Cookie Manager for chrome

Add like below screenshot

enter image description here

1
document.cookie = "debug_logs=debug_logs; path=/; domain=.force.com; value=debug_logs" ;

Add that to your page to set this cookie for the session.

3
  • This information is already contained in the above answers.
    – Adrian Larson
    Nov 14 '16 at 16:28
  • 1
    @AdrianLarson - A bit of a different approach though. This talks about adding the code to your site page. Which essentially negates the Winter 17 change. I really wish they made this a setting as the negative impact seems to outweigh the benefits for most.
    – Eric
    Nov 14 '16 at 16:32
  • Yeah we do only seem to hear about the drawbacks. I guess we can't get a good idea of the log volume or performance impact.
    – Adrian Larson
    Nov 14 '16 at 16:34
0

I was messing around with the same in 2021 and the user was not popping up for Traced Entity Name in debug logs.

Did some findings and found that Salesforce has taken up back the process to inject cookie in web-browser in order to do enable the debug logs in the release of spring 18.

To trace the guest user, now we need to follow these simple steps to find the exact name of the guest user and then only we can create the debug logs on it as follows:

enter image description here

Reference

Note: if you are adding debug logs and you can figure out the actual user from the list of Traced Entity Name directly then you can make use of: *guest* in the search field, it will list all the guest users.

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.