chromedriver cannot connect to chrome about auto-southwest-check-in HOT 26 CLOSED

That’s strange. Unfortunately, I don’t have any upcoming flights to try, so I won’t be able to test this for a while. Hopefully it is just from Southwest’s side and they fix it soon.

from auto-southwest-check-in.

from auto-southwest-check-in.

Thanks for testing @zderick. I was also able to test with the same parameters on version 109 with success.

Here are my results from doing different tests:

• With Undetected ChromeDriver v3.4.5, the script doesn't log in successfully with any version of Chrome.
• With Undetected ChromeDriver v3.1.7 (the current version in the script), the script logs in successfully with Chrome v108 (@zderick's testing) and v109. However, it doesn't work with Chrome version 110.

I assume the current script works with any Chrome version <= 109. Instead of adding the ChromeDriver path to the configuration, I can allow users to specify the chrome version. Then, the script can limit Google Chrome versions to <= 109 until v110+ works with undetected_chromedriver.

Can anyone verify a check-in works using Chrome version <= 109? You can follow what @zderick did above to specify the version. If you can't figure that out, let me know and I will create a branch so you can specify the version in the configuration file.

flying tomorrow and didnt come here to check issue unfotunately. I got the too many request error even though i changed the chromedriver options to 109 . NOW i have downgraded UC to 3.1.7 and using chromev109. I fly back Sunday. Will test and report back

from auto-southwest-check-in.

I added the option to specify the chrome version in the config.json in the chrome_version branch. There isn't documentation on it yet, but you can view the config.example.json for an example on how to use it. Just input the main version (108, 109, etc.). The default is 109.

Note: It does not work in Docker yet

from auto-southwest-check-in.

I added the option to specify the chrome version in the config.json in the chrome_version branch. There isn't documentation on it yet, but you can view the config.example.json for an example on how to use it. Just input the main version (108, 109, etc.). The default is 109.

Note: It does not work in Docker yet

I made some local changes to the Dockerfile that may help (I replaced where it installs google-chrome-stable):

ARG CHROME_VERSION="109.0.5414.119-1"
RUN wget --no-verbose -O /tmp/chrome.deb https://dl.google.com/linux/chrome/deb/pool/main/g/google-chrome-stable/google-chrome-stable_${CHROME_VERSION}_amd64.deb \
  && apt install -y /tmp/chrome.deb \
  && rm /tmp/chrome.deb

Modified from here: https://unix.stackexchange.com/questions/233185/install-older-versions-of-google-chrome-stable-on-ubuntu-14-10

from auto-southwest-check-in.

Thanks @everettsouthwick! I will use that to make changes in the Dockerfile (or you can submit a PR), but I’ll wait for verification that a check-in works first.

from auto-southwest-check-in.

Hi. Thanks for reporting this. I can reproduce the issue. It seems like Google changed the way headless in Chrome works as of version 110. This was fixed in version 3.4.5 of undetected_chromedriver (see here). To update you can run pip install --upgrade undetected_chromedriver.

However, I am getting a 429 error when trying to set up my account. Does this error occur for you as well? It might be with the recent changes in undetected_chromedriver.

from auto-southwest-check-in.

Hey @thegunz, I provided a fix for this on the chrome_configuration branch. Can you downgrade Google Chrome to 109 and download Chromedriver version 109 (can be found here). Also, make sure undetected_chromedriver is the version in the requirements.txt because the new version seems to have some issues.

To get those changes, run git pull && git checkout chrome_configuration and make sure to specify chromedriver_path in the config.json (you can see the details in the Configuration Doc).

from auto-southwest-check-in.

It appears that upgrading undetected_chromedriver to 3.4.5 allows me to use the CONFIRMATION_NUMBER FIRST_NAME LAST_NAME method with Chrome 110.0.5481.78. I see the correct UTC time for my departing flight with a valid check-in timeframe about 8 hours from now. Am I risking a possible error that mean my flight won't check-in?

from auto-southwest-check-in.

I haven’t been able to test undetected chromedriver 3.4.5 (it wasn’t working for me), so I don’t know for sure if it will work. If you do decide to proceed, please let me know if it works.

Could you also test if it successfully works when providing a username and password, if possible?

from auto-southwest-check-in.

When using username and password I get the following: KeyError: 'customers.userInformation.firstName'

from auto-southwest-check-in.

Ya, I am getting 429 as well:
{'code': 429999999, 'message': 'Error.', 'messageKey': 'ERROR', 'httpStatusCode': 'BAD_REQUEST', 'requestId': '', 'infoList': []}

At this point I will chance the other method.

from auto-southwest-check-in.

Checking in to flight from 'Blah' to 'Meh' for JOHN DOE

Failed to check in to flight 1A2WXYZ for JOHN DOE Reason: Too Many Requests 429.
Check in at this url: https://mobile.southwest.com/check-in

And also when I logged into the .com site, and then did a manual check in, I got an error about "appendChild" that was thrown by Southwest.com, and I had to use a different Check-in button, so I wonder if this is partly on the SW's side?

Edit - This is what I clicked initially that threw the apendChild Pop Up Error Box (Note: the html below is after I checked in, so it may have been slightly different, but it still throws the same error):

<div class="landing-air-upcoming-trips-banner-details--item_right"><div class="landing-air-upcoming-trips-banner-call-to-action"><div class="landing-air-upcoming-trips-banner-call-to-action--container"><a href="/air/check-in/review.html?clk=HPTRIPSLINKHASBP&amp;searchToken=SNIP SNIP class="actionable actionable_link actionable_extra-small-link actionable_suffix link"

After the error was thrown, and I clicked OK to clear the pop up, I had to use the lower right Check-in button, below all the flight details. I wish I was awake enough to have done all this with Network trace on, but oh well.

Edit 2 - GOT IT!!!! This is the error I receive if I interact with the "banner" Check-in button

checkInPageFormEdit: An error has occurred: Cannot read properties of undefined (reading 'appendChild')

Screenshots for Pop-up and Check-in Button: screens

from auto-southwest-check-in.

Yeah, this is the current issue I get as well when trying to log in. undetected_chromedriver changed some of its anti-bot algorithms, so that could be the issue. I’ll keep up with the undetected_chromedriver repository and hopefully they will have a fix soon.

Edit: It appears that after Chrome version 110, many companies updated their anti-bot detection, so we will have to wait for an update from undetected_chromedriver. See the discussion here

from auto-southwest-check-in.

I was able to overcome this by downloading an older version of chrome. 108 in my case from here: http://mirror.cs.uchicago.edu/google-chrome/pool/main/g/google-chrome-stable/

And then adding a parameter when we initialize the driver here: https://github.com/jdholtz/auto-southwest-check-in/blob/master/lib/webdriver.py#L44

Chrome(options=self.options, ..., version_main=108)

from auto-southwest-check-in.

Thanks for testing @zderick. I was also able to test with the same parameters on version 109 with success.

Here are my results from doing different tests:

• With Undetected ChromeDriver v3.4.5, the script doesn't log in successfully with any version of Chrome.
• With Undetected ChromeDriver v3.1.7 (the current version in the script), the script logs in successfully with Chrome v108 (@zderick's testing) and v109. However, it doesn't work with Chrome version 110.

I assume the current script works with any Chrome version <= 109. Instead of adding the ChromeDriver path to the configuration, I can allow users to specify the chrome version. Then, the script can limit Google Chrome versions to <= 109 until v110+ works with undetected_chromedriver.

Can anyone verify a check-in works using Chrome version <= 109? You can follow what @zderick did above to specify the version. If you can't figure that out, let me know and I will create a branch so you can specify the version in the configuration file.

from auto-southwest-check-in.

If the status is the same by next Friday, I can try again with an older version of Chrome (v109). I actually prefer this since another site I regularly "watch" may have broken too. :)

from auto-southwest-check-in.

Thanks for testing @zderick. I was also able to test with the same parameters on version 109 with success.
Here are my results from doing different tests:

• With Undetected ChromeDriver v3.4.5, the script doesn't log in successfully with any version of Chrome.
• With Undetected ChromeDriver v3.1.7 (the current version in the script), the script logs in successfully with Chrome v108 (@zderick's testing) and v109. However, it doesn't work with Chrome version 110.

I assume the current script works with any Chrome version <= 109. Instead of adding the ChromeDriver path to the configuration, I can allow users to specify the chrome version. Then, the script can limit Google Chrome versions to <= 109 until v110+ works with undetected_chromedriver.
Can anyone verify a check-in works using Chrome version <= 109? You can follow what @zderick did above to specify the version. If you can't figure that out, let me know and I will create a branch so you can specify the version in the configuration file.

flying tomorrow and didnt come here to check issue unfotunately. I got the too many request error even though i changed the chromedriver options to 109 . NOW i have downgraded UC to 3.1.7 and using chromev109. I fly back Sunday. Will test and report back

Using config file with v109 and UC 3.1.7 worked like a charm!!! Was able to add multiple conf# which I forgot the script could do. B06&B07 not bad. Thanks everyone.

from auto-southwest-check-in.

For what its worth, I was getting the same WebDriverExceptions and only updated UC (undetected-chromedriver==3.4.6). I do not have issues reading the reservation page anymore so I assume the checkin should work as well.

The chrome I am running is - Google Chrome 110.0.5481.77

from auto-southwest-check-in.

@molmedo1 glad to hear it worked. I will merge the latest changes from the chrome_version branch, and then I can release version 2!

from auto-southwest-check-in.

@ryanjchan could you try to log in? You can see in this comment that it scheduled the check-in successfully but still failed to actually perform the check in. I am also trying with the latest version of Chrome and undetected_chromedriver and getting a 429 error when trying to log in.

from auto-southwest-check-in.

I get a 404 when attempting the checkin since it is too soon? (Not sure what the behavior is, should this url only work if its within the checkin window?)

When checking the .com the url returns {"code":400120102,"message":"","httpStatusCode":"BAD_REQUEST","requestId":"","infoList":[""]}

The initial GET for a checkin fails (mobile-air-operations/v1/mobile-air-operations/page/check-in/) so I never get to the POST to checkin.

I'll try to check the output when the flight comes around later this week.

from auto-southwest-check-in.

Yes, that 404 is expected. You can see that happen on the Southwest website as well.

from auto-southwest-check-in.

Just a quick comment (maybe this is already known): I was having the same issue, and I changed the headless mode in webdriver.py by adding the argument "--headless=new". Based on what I'm reading, it should be "--headless=chrome" for versions 96-108, and 109 and beyond should be set to "new". Just checked into two flights now on Chrome 110!

source: https://www.selenium.dev/blog/2023/headless-is-going-away/

from auto-southwest-check-in.

Thanks @vdude8 for finding this! This was implemented in the latest versions of undetected_chromedriver, but I'm still getting detected by Southwest so I just ported that feature to the chrome_version branch.

from auto-southwest-check-in.

Hey @everettsouthwick, I tried to implement the Docker version specification, but I couldn't figure out a way to simultaneously allow the user to download the latest version automatically or a specific version if specified. If anyone else figures it out, feel free to make a pull request.

from auto-southwest-check-in.