For sites, there's a standard visualforce exception page.

We use a header on the site that will present either Welcome, username



...based on login status. Whenever a user finds a new, clever way to get an unhandled exception, the error page ALWAYS appears in guest user mode.

Not only did they get an error page (bad enough) but they also think that we just logged them out. They try to log in and see another error page (because they tried to log in while they're already logged in).

How do I allow the exception page to present itself to authenticated users and stay on the secure domain? The page is available to both the guest and authenticated user profile.

For clarity (asked below) it's not the styling that is going bad. It's that the exception page always thinks rendered="{!ISPICKVAL($User.UserType,'Guest')}" is true.

For clarification, we're using authenticated sites with a custom domain.

  • Are you using the standard exception page or is this a custom vf page you created? Commented Aug 22, 2012 at 3:55
  • Is that page available for the user's profile? Commented Aug 22, 2012 at 5:35
  • I edited to explain the profile thing better. Commented Aug 22, 2012 at 14:03

5 Answers 5


If I understand you correctly, basically the issue is that the exception page is requested by the Guest user no matter what because the Exception page request is going to the non-secure (e.g., https://www.example.com URL and not https://example.secure.force.com. The rub is that there is no way to change that behavior because the Exception page request is made by the system.

Could you do a redirect from the Exception page to a different page using Javascript? You'd override the custom Exception page and add in a redirect on it. The redirect would be to an error page on the secure domain which would send the request as the logged in user. Not sure how this would play with exceptions generated by the non-secure portion, though. I guess as long as the page is accessible by the site it wouldn't be a problem to access the page, though.

Update to capture a workaround for the login. This part doesn't address the exception page portion but just the double login.

  1. This assumes that you have link called Login that displays instead of the Welcome, FirstName and not an actual small login form in the upper right hand corner of the page or something to that effect and that link goes to a dedicated login page.

  2. Store the full path to the secure login page (e.g., https://example.secure.force.com/thesite/login) in a custom setting. It's important to externalize the URL so that when you move to sandboxes you can update it.

  3. "Hardcode" the Link to the login to come from that custom setting, so that the link will never go to an unsecure page.

  4. In the Login VF page put JavaScript in the head to test if the URL is equal to that custom setting value and if it isn't redirect to it.

  5. In the Login Controller that handles the display of the login form detect if the user is already logged in. If they are then redirect them to their start/landing page.

  • I'm going to pick this one based on creativity. Haven't tried it yet....what I'm actually going to do is hide the login status area on the exception page, as in rendered="{!$currentPage.name!='Exception'}" Commented Sep 26, 2012 at 2:22

Although this doesn't specifically address your issue, namely to properly route unhandled exceptions from within sites based on the site visitor, it does effectively do what you are looking for. The solution?

Handle all exceptions, period.

And in those rare situations where you are prevented from handling an exception, use preventative coding practices to avoid ever running into an unhandleable exception. An example would be using System.Limits methods:

if(System.Limits.getDMLStatements() < 75)
   //... perform DML

This is the approach I take to developing sites - in part because of the exception issue you mention. Then when you try/catch every handleable exception, you can route them to the appropriate pages based on the site visitor.

  • 1
    Yeah, what he said: Handle all exceptions, period. If you are seeing specific exceptions coming through, just update your code to handle them. Trying to patch the error message seems like a cop-out instead of an impetus to do better coding. Commented Sep 9, 2012 at 21:11
  • 2
    That's lovely. How about the exception where a page deploys while someone's on it? Can't shut the site down for deployments. Commented Sep 26, 2012 at 2:19
  • True. But you can have a nice landing page for your site while it's inactive (during your deployment). I think having a "down for maintenance" page is pretty standard these days, even for Salesforce. Then when you set your site to active again after your deployment is finished, you can handle all your errors :)
    – Adam
    Commented Sep 26, 2012 at 6:19

When setting up a Force.com site, there's a related list on the detail page of 'Error Pages'. If you set these up to use your custom pages rather than the default you should be able to retain your styling. We use this for our web site and I've found it to work well.

  • Thanks, but it's not the styling...see the rendered statement in my edited question. Commented Aug 22, 2012 at 14:06

Faced a similar issue a while back, users think they get logged out, added a custom page telling the user an error has occurred and links to navigate to 'Back' and 'Home'. This was a quick fix so the users could atleast find their way back.

You can have a custom controller for your error page and behave like any other page within your app, correct me if I am wrong. This way the custom controller for an error page should execute in authenticated mode, but seems like it does not? (based on the visualforce tag you posted), if so you could make use of Apex cookies to store the authenticated user when they login in and access them from your custom error page (and destroy them when they logout).


As Bob says you can use your own custom VF Page and have a controller bound to it which gets the value in a property and based on that property you show the username. Did you try that? Or why cant you use an encrypted cookie or something to Identify the username whenever a user is logged in? and you can blank out the cookie when you logout. that would definitely work if the 1st option didnt work. We are using the same and we didnt get any problem

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .