Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Salesforce compatibility for long-polling transport #869

Open
jaypatel512 opened this issue Jun 25, 2019 · 6 comments

Comments

Projects
None yet
2 participants
@jaypatel512
Copy link

commented Jun 25, 2019

The fix #724 created for this fails the sales force integration as outlined in this stack overflow comment. Reverting to 3.1.1 works with salesforce. Do we know if there is a workaround to keep the latest version and allow using salesforce ? We are currently on version 3.1.4 and are seeing this issue outlined here: https://salesforce.stackexchange.com/questions/197728/cannot-add-property-context-object-is-not-extensible-error-during-cometd-hand/197826#197826

Any help would be greatly appreciated. Hopefully this allows more salesforce users to use your awesome library :) Thank you so much as always ?

P.S. We are not able to upgrade above 3.1.4 for security reasons related to web workers. I am getting more information from our team to give more detailed explanation on security issue, but wanted to give some perspective on the issue.

@sbordet

This comment has been minimized.

Copy link
Member

commented Jul 8, 2019

I need more information about this.

The error "TypeError: Cannot add property context, object is not extensible" is strange as certainly browsers do not "seal" the XHR object as described here.

What client are you using, and why does it "seal" the XHR object?

@jaypatel512

This comment has been minimized.

Copy link
Author

commented Jul 9, 2019

Hey @sbordet !

We are trying to use this in our salesforce setup. We are using long-polling javascript client.

Salesforce had in their documentation somewhere (which I am trying to find as I am writing this), that mentions that salesforce would replace some javascript components with its secured version. E.g. context would be replaced with secureContext, which does not allow for updating the values.

The issue we are seeing is exactly what we saw in the stackoverflow question linked to the main issue.

@sbordet

This comment has been minimized.

Copy link
Member

commented Jul 9, 2019

@jaypatel512 so you are not using CometD's client, but SalesForce client.
I'm not sure there is something we can do here, you should ask SalesForce why they do that?

@jaypatel512

This comment has been minimized.

Copy link
Author

commented Jul 9, 2019

Hey @sbordet ! We are using cometD library version 3.1.4. We are manually adding it to salesforce website using lightning components.

The issue comment by Grekker outlines what is causing the error. CometD library version 3.1.1 worked properly. A change in #724 is the one that is causing the error, as it is trying to update the params "context" on xmlhttprequest. This is what Salesforce protect from allowing cometD or any external library to modify certain params to XmlHttpRequest.

Figured it out. The cometd library on GitHub since version 3.1.2 added a line of code that Salesforce doesn't like, 
my guess is because it changes XHR and LockerService is forcing XHR to not change. Here's the offending commit: github.com/cometd/cometd/commit/… 
To get around this use version 3.1.1, or reverse/comment out the additions in this commit. 

– Grekker Oct 24 '17 at 4:58
@sbordet

This comment has been minimized.

Copy link
Member

commented Jul 9, 2019

We are manually adding it to salesforce website using lightning components.

I don't know what that means.

This is what Salesforce protect from allowing cometD or any external library to modify certain params to XmlHttpRequest.

I understand the problem. It is a feature that has been added to CometD and cannot be removed.
Why SalesForce decided to "seal" XHR I don't know, but there is not much we can do. You should ask them to remove the sealing.
From the JavaScript point of view, I should be allowed to add any property to any object.

Best I can do is to do some sniffing to check if the object is sealed, and if so avoid adding the property, but I'm not sure how easy would that be.

@sbordet

This comment has been minimized.

Copy link
Member

commented Jul 9, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.