2

We have a community site where we allow guest users to log in using self registration.

In our controller we confirm the user, activate the user account and attempt to log them in using the 

PageReference pr = Site.login(email, password, url);
pr.setRedirect(true);
return pr;

We have a system.debug to see the redirect url. The issue is that unfortunately the user is not logged in, and is just redirected to the community login page.

In the debug of the pr variable, we copy the string provided and enter that in the browser which seems to successfully log us in and redirect us, so the url from the pagerefence is correct. However, as previously stated in the normal flow this process does not seem to take place and instead of being logged in and redirected the user is just redirected to the login page. Has anyone else ran into such issue? What could be the cause of this redirect, knowing that the redirect url is correct? Everything from what I can tell looks good and we aren't getting any exception errors.

Improve this question
2
  • If I'm not mistaken Salesforce Security measures no longer allow those types of redirects where you insecurely pass username & pw. Instead, it can only be done via oath using tokens. However, I could be mistaken on that. Also, I believe that logging into Sites is logging into a different "container" than your community. I suggest you check the security docs to confirm this if someone else doesn't pop in with a more definitive answer.
    – crmprogdev
    Commented May 16, 2018 at 13:59
  • I've looked through the docs and didn't find anything that explicitly mentioned this. Would you be able to provide a link or more information please, thank you.
    – Hect1c
    Commented May 17, 2018 at 12:14

1 Answer 1

Reset to default
0

To supplement my comments, see Cross-Site Request Forgery (CSRF) in the Salesforce Security Guide.

Within the Lightning platform, Salesforce has implemented an anti-CSRF token to prevent this attack. Every page includes a random string of characters as a hidden form field. Upon the next page load, the application checks the validity of this string of characters and does not execute the command unless the value matches the expected value. This feature protects you when using all of the standard controllers and methods.

Here again, the developer might bypass the built-in defenses without realizing the risk. For example, suppose you have a custom controller where you take the object ID as an input parameter, then use that input parameter in a SOQL call. Consider the following code snippet.

(example omitted) ...

Because of Salesforce’s built-in defense against CRSF, your users might encounter an error when they have multiple Salesforce login pages open. If the user logs in to Salesforce in one tab and then attempts to log in to the other, they see an error, "The page you submitted was invalid for your session". Users can successfully log in by refreshing the login page or attempting to log in a second time.

Improve this answer

You must log in to answer this question.

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