0

Background of the issue:

We are upgrading from Sitecore 9.2 to Sitecore 10.2 without Sitecore identity server. We are using Ping ID as an Identity provider using Saml2.0 protocol. In application, while clicking on Login button (which will navigate to Ping ID login page on successful redirect), it shows the same-origin policy origin error for Horizon URL. Due to which redirect to Ping ID login page is failed.

Error details:

Login button in application:

enter image description here

Request and Response details from network tab: 1 -> Sitecore application URL 2 -> Sitecore Horizon URL enter image description here

Error response details: enter image description here

Solutions tried:

Solution1: Included below config changes in Web.config file of Sitecore application:

<configuration>
<system.webServer>
      <httpProtocol>
        <customHeaders>          
          <add name="Access-Control-Allow-Origin" value="https://<Horizon URL>" />
          <add name="Access-Control-Allow-Methods" value="*" />
          <add name="Access-Control-Allow-Headers" value="*" />
        </customHeaders>
      </httpProtocol>
</system.webServer>
</configuration>

Solution2: Enable Cors in Controller level where Login functionality handled:

namespace Feature.Login.Controllers
{
    [EnableCors(origins: "https://<Horizon URL>", headers: "*", methods: "*")]
    public class UserLoginController : Controller
    {
        // GET: User
        /// <summary>
        /// Logins to the application with the respective user
        /// </summary>
        /// <returns>LoginLinks.cshtml</returns>
        public ActionResult SSOLogin()
        {
}
}
}

Solution3: Enable CORS origin for Sitecore applicatioin URL in Web.Config file of Horizon web root:

<configuration>
 <system.webServer>
    <security>
      <requestFiltering>
        <requestLimits maxQueryString="32768" />
      </requestFiltering>
    </security>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="dotnet" arguments=".\Sitecore.AuthoringHost.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="OutOfProcess" />
    <httpProtocol>
    <customHeaders>
    <add name="Access-Control-Allow-Origin" value="*" />
            <add name="Access-Control-Allow-Methods" value="*" />
            <add name="Access-Control-Allow-Headers" value="*" />
    </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>

But, nothing was worked out. Please help us to fix this issue.

7
  • 1
    You highlighted two HTTP headers: Referrer-Policy and Content-Security-Policy. The Referrer-Policy header controls how much referrer information should be included in the Referer header. Content-Security-Policy instructs browsers to load resources and send requests generated from JavaScript only to allowed domains, i.e. prevent cross-site scripting. So none of them should be causing a server-side error in Sitecore. Please check your Sitecore logs, does it have any error details?
    – Anna Gevel
    Feb 8, 2023 at 8:57
  • @AnnaGavel : We found the error "ERROR Cannot find pipeline with name 'getRenderingRules'." in application logs. But this error even happen on page load not only on Login. Is this issue cause the error "An Error Occurred"?
    – Thamizh
    Feb 9, 2023 at 10:52
  • 1
    As far as I know it should not. Do you use Sitecore Federated Authentication and Owin identity provider for Saml2.0 integration? If yes, please try checking the Owin log file too, it may have login-specific errors.
    – Anna Gevel
    Feb 9, 2023 at 11:10
  • @AnnaGavel : No Errors in Owin logs. only these two INFO lines: INFO Sustainsys.Saml2.Owin.Saml2AuthenticationMiddleware - Initiating login to <Entity ID> INFO Sustainsys.Saml2.Owin.Saml2AuthenticationMiddleware - Loading metadata for idp <Entity ID>
    – Thamizh
    Feb 9, 2023 at 12:57
  • 1
    After comparing Config files between existing system (9.2) and new system (10.2), came to know meta data has been incorrectly configured. Now the issue got resolved. Thanks for your support @AnnaGevel
    – Thamizh
    Feb 10, 2023 at 11:00

1 Answer 1

0

The issue is due to incorrect Meta data configuration between current system (9.2) and new system (10.2). After compare the meta data configurations, found and corrected the meta data, issue got resolved. Thanks.

1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.