Chrome extension "Salesforce Navigator for Lightning" not working for some orgs 

[anshul-goyall]

When it works, it works like a charm, but the only problem I see is that for some of the orgs it does not work but for some it does. It really is behaving based on the org and I am not sure why. For example - this is working on the domain "https://bataustria--uat.sandbox.lightning.force.com/". But not on domain "https://ptorg--aotfpoc.sandbox.lightning.force.com/"

Could you please help if you are aware of this issue? Is this expected and what is the resolution to make it work on every org?

[dannysummerlin]

Hi there, I've just moved countries so I'm behind on things, but that is definitely not the intended behavior! Can you try opening up the developer console while in the instance that is throwing errors and see if there are any messages that stand out as being errors from Salesforce Navigator? We'll have to recreate the issue to get to the bottom of it I'm afraid.

[davidGravityLab]

When it's worked on some orgs and not others for me, it's been related to the "Require HttpOnly attribute" value being true in session settings.

This is the error that comes up:

related to this part of the code.

[JarrahN]

Hi @dannysummerlin

I have replicated the same issue as @davidGravityLab has defined. Here is my value for document.cookie (trimmed) with RequireHttpOnly checked

"BrowserId_sec=...; _ga=...; BrowserId=...; CookieConsentPolicy=0:1; LSKey-c$CookieConsentPolicy=0:1; sfdc-stream=...; sid_Client=...; clientSrc=...; inst=APP_F6"

vs RequireHttpOnly unchecked (after a logout/login)

"BrowserId_sec=...; _ga=...; BrowserId=...; CookieConsentPolicy=0:1; LSKey-c$CookieConsentPolicy=0:1; sfdc-stream=...; sid_Client=...; clientSrc=...; inst=APP_Hz; sid=..."

The sid attribue isn't available in the first instance

[dannysummerlin]

Thank you @davidGravityLab and @JarrahN, that was perfect, put me on the right track. The bad news is is that then that is just working as intended - the RequireHTTPOnly flag hides the session id from the Javascript environment, which I understand in theory but in practice that means I would need to write a full login and token handling apparatus for the extension, and I honestly do not have that kind of time.

If anyone knows of any other place to get the session id from (I went hunting in the JS objects SF creates for the page and couldn't find it) I'm more than happy to rewrite the check for that, but in the mean time I'm just going to have to add a warning that this extension is incompatible with that setting. Again I get the theoretical value of hiding the sid, but practically I see its benefits and in this particular case can't create the workaround. I'm always open to pull requests though for anyone who wants to take that on!

[dannysummerlin]

Actually, scratch some of that - the sid is used to do the queries to get custom objects, so I should actually be able to make it work for everything but that so it is at least still a little useful. I'm doing some testing now, more soon.

[dannysummerlin]

Okay, so I have that set up, if you activate RequireHTTPOnly you won't be able to get to Custom Objects, but most everything else should work (oh except Login As, that also requires the sid). Version 4.8.2 should be on the way, lemme know how that turns out!

[DavidSmithnz]

That looks a lot better, it's working in orgs that it's never worked in before. thanks!

…

On Mon, 16 Oct 2023 at 03:32, Danny Summerlin ***@***.***> wrote: Alright, version 4.8.2 should be on the way, lemme know how that turns out! — Reply to this email directly, view it on GitHub <#34 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABLS5M5YW4RKUAZKM3XBWALX7PXYBAVCNFSM6AAAAAAZHL3SVGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRTGQYDQMBRG4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[JarrahN]

Thanks @dannysummerlin can confirm its working me also!

[dannysummerlin]

Glad to hear it, thanks for the help in getting there!