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

Handshake not setting BAYEUX_BROWSER cookie to browser #881

Open
ddouras opened this issue Oct 28, 2019 · 8 comments
Open

Handshake not setting BAYEUX_BROWSER cookie to browser #881

ddouras opened this issue Oct 28, 2019 · 8 comments

Comments

@ddouras
Copy link

@ddouras ddouras commented Oct 28, 2019

Hi, I am using CometD with Angular 6. After a successful handshake I get error in all subsequent connect requests -> 400::Client {myClientId} has established a session, but no BAYEUX_BROWSER cookie present

How can I resolve that. I see handshake uses a Set Cookie response header, but I am not able to get this header using response.headers. Shouldn't it automatically set cookie on browser?

@ddouras ddouras changed the title Handshake not setting BAYEUX_BROWSER to browser Handshake not setting BAYEUX_BROWSER cookie to browser Oct 28, 2019
@sbordet

This comment has been minimized.

Copy link
Member

@sbordet sbordet commented Oct 28, 2019

What CometD version?

CometD does not return the message you reported above, do you have some wrapper code around CometD?

The BAYEUX_BROWSER cookie is marked as HttpOnly, so it's not available via JavaScript.

If it's not set by the browser in the /meta/connect requests, it may be that your browser has cookies disabled?

@ddouras

This comment has been minimized.

Copy link
Author

@ddouras ddouras commented Oct 28, 2019

I am using cometd 4.0.3 to listen to Salesforce notifications. My code looks like :

    this.connection.handshake((response: any) => {
      if (response.successful) {
        this.connection.batch(() => {
          this.connection.subscribe(`/topic/Topic1=${id}`, onApplicationChange);
          this.connection.subscribe(`/topic/Topic2=${id}`, onResultChange);
        });
      }
    });

The handshake is successful and I see Set-Cookie: BAYEUX_BROWSER in the response headers. However all the subsequent meta/connect requests are failing due to above error. I have cookies enabled in my browsers, I have tried multiple browsers

@sbordet

This comment has been minimized.

Copy link
Member

@sbordet sbordet commented Oct 28, 2019

I don't know what SalesForce does exactly on the server side.

Your code looks good from the CometD point of view (assuming that connection is the CometD object).

If you see Cookie: BAYEUX_BROWSER=... in the request headers for requests after the handshake, then you should be good.

Can you really use a plain CometD JavaScript client with SalesForce?
Don't they require their own client?

@ddouras

This comment has been minimized.

Copy link
Author

@ddouras ddouras commented Oct 28, 2019

According to Salesforce https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/streaming_error_codes.htm

Client client_name has established a session, but no cookie_name cookie present -> No cookie was found after the client established a session. Ensure that the streaming client accepts cookies.

Also in https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/intro_client_specs.htm I see:
The client must accept and send back all appropriate cookies for the domain and URI path. Clients must obey the standard cookie protocol with the server.

The issue is that I don't see Cookie: BAYEUX_BROWSER=... on request header for requests after handshake

@sbordet

This comment has been minimized.

Copy link
Member

@sbordet sbordet commented Oct 28, 2019

Are you using some proxy that may strip the cookies?

If you don't see the browser sending Cookie: BAYEUX_BROWSER=..., is it possible that there is a https vs http issue? I.e. the server sent the cookie for https, but you are trying http or viceversa?
Is it possible that the domain for which the cookie is set is different?

@ddouras

This comment has been minimized.

Copy link
Author

@ddouras ddouras commented Oct 28, 2019

the handshake and subsequent requests are all using the same domain. If that was the case then handshake request would be stripped of cookies as well right?

@sbordet

This comment has been minimized.

Copy link
Member

@sbordet sbordet commented Oct 28, 2019

The handshake request, being the first, has no cookies.

@sbordet

This comment has been minimized.

Copy link
Member

@sbordet sbordet commented Oct 30, 2019

@ddouras can you be hitting #833?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.