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

Setting cookie on headless Chrome not working #56

Open
Edvard-D opened this issue Feb 5, 2019 · 7 comments
Open

Setting cookie on headless Chrome not working #56

Edvard-D opened this issue Feb 5, 2019 · 7 comments

Comments

@Edvard-D
Copy link

Edvard-D commented Feb 5, 2019

For my application I'm having the user authenticate themselves in a visible Chrome browser session and saving the authentication cookie. I need to add that cookie to a different headless session that will be used to do the actual work. I have a manager script that's checking if the authentication is still valid on a regular basis (by trying to get a specific element that only exists when logged in), with it relaunching a visible browser session if the user logs out.

Unfortunately, my application is in a loop of launching a visible session A, getting the cookie, setting the cookie on the headless session B, checking that authentication is still valid, and relaunching the visible session A to re request authentication. This seems to mean that the cookie isn't getting set properly or the headless session isn't able to find the element using get_element.

What's strange is that when I try switching the headless session to a visible session everything's working properly. In this scenario the application is requesting user authentication in visible session A, then taking the cookie from that and adding it to visible session B. Visible session A closes (as it should) and B continues to check that the authentication is still valid. Session A is no longer getting relaunched since session B is able to find the element.

I've looked through the logs to see if there are any sorts of exceptions being thrown, but there aren't (except 'no such element', but that's being handled). One thing I noticed is the following:

Starting ChromeDriver 2.40.565498 (ea082db3280dd6843ebfb08a625e3eb905c4f5ab) on port 57194 Only local connections are allowed. 2019-02-05 15:07.41 request body={"desiredCapabilities": {"browserName": "chrome", "chromeOptions": {"args": ["--headless", "--disable-gpu"]}}} method=POST url=http://localhost:57194/session [0205/150741.616:ERROR:gpu_process_transport_factory.cc(967)] Lost UI shared context.

At the end you can see ERROR:gpu_process_transport_factory.cc(967) Lost UI shared context. No idea if that's related, but I thought it's worth mentioning. Is it possible I'm doing something wrong? If there's anything I need to clarify please let me know.

@atom-smasher
Copy link

Similar problem here. This can be confirmed by using headless mode to take a screenshot of a site, such as this one, that you're logged in to. Instead of seeing that you're logged in, the screenshot will show a "Sign in" button.

@ojii
Copy link
Contributor

ojii commented Feb 13, 2020

could this just be the website you're trying to access detecting headless browsers and rejecting them?

@atom-smasher
Copy link

Happening on multiple sites, and the user-agent is set to reflect a "normal" browser.

@liuhuac
Copy link

liuhuac commented Feb 21, 2020

Any update? I am hitting the same situation. I am using headless chrome to take a screenshot. It working for visible chrome, but not headless.

@dimaqq
Copy link
Contributor

dimaqq commented Feb 21, 2020

+label help-wanted

@dbaldacchino
Copy link

Running into the same issue. I am trying to automate printing to pdf but the pages are behind a login page. Without a session cookie, it just displays the login page.

@loyogoy-g
Copy link

Any solutions ? I think the site detects headless browser

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

No branches or pull requests

7 participants