My | Salesforce Trailblazer Community

Oct 14, 2022, 3:08 PM

Incognito Windows and cross domain cookies

In one of my brighter moments, I decided that The Thing To Do™ was clone a developer sandbox without enabling enhanced domains so that I could figure out the SSO implications.

As a bonus, now I have two more or less identical sandboxes so I can compare side by side. And initially I was trying to blame this behavior on Enhanced Domains because the message I got was

"We can't display this page because your browser blocks cross-domain cookies, but you can view this page in Salesforce Classic. Click here to open this page in Salesforce Classic."

But as it turns out, this happened in both sandboxes, so Enhanced Domains didn't cause the problem, but it also didn't fix it. Which I thought was the point of the exercise.

The steps to reproduce are:

Open a new Incognito Window (Chrome -- I haven't tested this in Firefox or Edge yet).
Navigate to Setup -> Users -> Users/Profiles/Permission Sets... take your pick*.

The URL is correct -- with or without the .sandbox. but you get this message. And it's correct, you can open it and do whatever you need to in Classic. But what I'm not getting is why this particular collection of circumstances always leads to this conclusion.

It's not so much a "problem" as "something I'm not quite understanding" and (might not even if it were explained). Specifically (a) what causes it, and (b) what prevents enhanced domains form resolving these use cases?#

*Permission Set Groups did not exhibit this behavior because a while back I had opt enable the agility to expire a permission set group, and part of that process was converting that page to Lightning UI, which doesn't have this conflict.

#My Domain #Enhanced Domains

4 answers

David Rossall
Jul 3, 2025, 10:45 AM
I've only just come across this when searching for a solution to the same issue in incognito mode, for the users list in setup. With the pointers here and elsewhere, it turns out that Chrome incognito does indeed block cross-domain cookies by default:
https://support.google.com/chrome/answer/9845881?hl=en#zippy=%2Chow-incognito-mode-works

And the fix of enabling them via the site settings sliders in the URL bar does resolve it:
Hope this helps (belatedly!) anyone else looking at this.

Add a comment

Write an answer...

0/9000

Apr 22, 2020, 12:53 PM

While deploying to Mule RTF I am setting few jvm arguments e.g. sslKeyStore location, password etc. I can set those values while doing manual deployment. But how to set those values automatically when I am deploying through maven (CI/CD).

There are parameters in deploymentSettings to set values to resources like cpu, memory, last mile security etc. but there is no way to set up JVM arguments. Please help.

4 answers

MuleSoft Community Forum Member (Inactive) (Salesforce)
Apr 24, 2020, 7:55 AM
Thanks for your reply. I have already gone through this link. I have a doubt actually. Suppose I am adding these attributes in the properties file (say config.properties) like below.

#my keystore file is inside resources of mule project
javax.net.ssl.keyStore=/opt/mule/apps/api-name/something.jks
javax.net.ssl.keyStorePassword=some_password
javax.net.ssl.trustStore=/opt/mule/apps/api-name/something.jks
javax.net.ssl.trustStorePassword=some_password

But it didn't work. I didn't expect also because I am not referring these values anywhere like ${javax.net.ssl.keyStore} etc. etc. So I am still not sure.

However, the application just works perfect if deploy manually to RTF and add the above parameters under the JVM tab (last tab in RTF console) with -D like below.

-Djavax.net.ssl.keyStore=/opt/mule/apps/api-name/something.jks
-Djavax.net.ssl.keyStorePassword=some_password
-Djavax.net.ssl.trustStore=/opt/mule/apps/api-name/something.jks
-Djavax.net.ssl.trustStorePassword=some_password

Hope I am able to explain. Please advise.

Add a comment

Write an answer...

0/9000

Apr 24, 2020, 7:05 PM

AutoDiscovery is not working for application deployed on RTF where key-store and trust-stores location and password are passed as JVM arguments on RTF

I am setting the below parameters as JVM argument while deploying to Mule RTF. I am adding the JVM arguments manually under the JVM tab (the last tab) in RTF console. Below are the parameters that I am setting

#my keystore file is inside resources of mule project

-Djavax.net.ssl.keyStore=/opt/mule/apps/api-name/something.jks

-Djavax.net.ssl.keyStorePassword=some_password

-Djavax.net.ssl.trustStore=/opt/mule/apps/api-name/something.jks

-Djavax.net.ssl.trustStorePassword=some_password

The application is working perfectly but when I am trying to implement Auto Discovery it is failing with the below error.

AutoDiscovery is not working for application deployed on RTF where key-store and trust-stores location and password are passed as JVM arguments on RTF

Other mule applications where such JVM arguments are not needed are working fine with Auto DIscovery. If somebody can please provide any suggestion that will be really helpful.

4 answers

MuleSoft Community Forum Member (Inactive) (Salesforce)
Apr 25, 2020, 6:15 PM
Hi Shekh,

Thanks for your reply. I think one important that you are missing here is I am deploying on Mule Runtime Fabric which is running eventually on pods (Kubernates). What you said is correct when we are deploying on any other mule runtime but when it is being deployed on RTF then we don't know where to get the Java_Home because the location is not fixed as they are pods. I am not a Kubernates expert though. Please advise how we can address this issue.

Add a comment

Write an answer...

0/9000

Jan 7, 2016, 2:55 PM

How do I do a URL rewrite of the Tableau server?

We have a requirement to customize the tableau server dashboard URL.

For example: Default URL of the tableau dashboard is "<servername>/#views/<dashaboardname>?:iid=1", We want to customize URL like this "<servername>/<dashboardname>".

I have found following code to do URL re-writing. Below is the code for the same.

# turn on the rewrite engine (module loaded above) #TABLEAU CODE

RewriteEngine on

...

⌗Rewrite the URL so that the server name does not appear #MY CODE

RewriteCond %{HTTP_HOST} !^(.*)[server name]\.[domain]\.com [NC]

RewriteCond %{HTTP_HOST} !^$

RewriteRule ^/(.*) name].[domain].com/$1 [R,L]

Can anyone please explain this ?

Thanks

Nutan Patel

10 answers

Jeff Strauss
Jan 8, 2016, 1:22 PM
yes, we created a .Net application as the best viable alternative. without it, I don't know that there's any other workaround, but if you find one, let us know.

Add a comment

Write an answer...

0/9000

Apr 6, 2014, 2:29 AM

How do I do a URL rewrite of the Tableau server?

Currently the Tableau server is being addressed by its machine name, and the environment team has told me that applying a CNAME to the server will only help map traffic initially, but the machine name will still appear in the browser window.

Instead I have been told to do a URL rewrite. I found this post in the forum that says to edit httpd.conf.templ file in path *\Tableau\Tableau Server\[version]\templates. I placed the following command in the file

# turn on the rewrite engine (module loaded above) #TABLEAU CODE

RewriteEngine on

...

⌗Rewrite the URL so that the server name does not appear #MY CODE

RewriteCond %{HTTP_HOST} !^(.*)[server name]\.[domain]\.com [NC]

RewriteCond %{HTTP_HOST} !^$

RewriteRule ^/(.*) name].[domain].com/$1 [R,L]

I did tabadmin stop, tabadmin config, tabadmin start and the url is not redirecting. Any thoughts on what I'm missing?

3 answers

Johan De Groot
Apr 13, 2014, 12:07 PM
I don't think URL rewrites will be the solution to your problem.

Adding a CNAME to the DNS which 'points' to the machine name should work, since Tableau only uses relative URLs inside Server as far as I can see. Same as using A records (= using IP adresses in the DNS server).
Just give it a try - it is much easier to test than fiddling with URL rewrites...

Add a comment

Write an answer...

0/9000

#My0 discussing

Related Learning

Leaderboard for #My

No active leaders.