jdholtz / auto-southwest-check-in

A Python script that automatically checks in to your Southwest flight 24 hours beforehand.
GNU General Public License v3.0
447 stars 85 forks source link

Check in failed #17

Closed schmeed closed 1 year ago

schmeed commented 1 year ago

Error when running the comment. Stacktrace below.

$ python3 southwest.py ** First Last

127.0.0.1:60764: Traceback (most recent call last):
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/server/server.py", line 113, in handle
    root_layer()
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/server/modes/http_proxy.py", line 9, in __call__
    layer()
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/server/protocol/tls.py", line 285, in __call__
    layer()
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/server/protocol/http1.py", line 100, in __call__
    layer()
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/server/protocol/http.py", line 206, in __call__
    if not self._process_flow(flow):
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/server/protocol/http.py", line 285, in _process_flow
    return self.handle_regular_connect(f)
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/server/protocol/http.py", line 224, in handle_regular_connect
    layer()
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/server/protocol/tls.py", line 278, in __call__
    self._establish_tls_with_client_and_server()
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/server/protocol/tls.py", line 358, in _establish_tls_with_client_and_server
    self._establish_tls_with_server()
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/server/protocol/tls.py", line 445, in _establish_tls_with_server
    self.server_conn.establish_tls(
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/connections.py", line 295, in establish_tls
    self.convert_to_tls(cert=client_cert, sni=sni, **kwargs)
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/net/tcp.py", line 382, in convert_to_tls
    context = tls.create_client_context(
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/net/tls.py", line 276, in create_client_context
    context = _create_ssl_context(
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/net/tls.py", line 179, in _create_ssl_context
    context.set_verify(verify, verify_callback)
  File "/home/schmeed/.local/lib/python3.8/site-packages/OpenSSL/SSL.py", line 1128, in set_verify
    self._verify_helper = _VerifyHelper(callback)
  File "/home/schmeed/.local/lib/python3.8/site-packages/OpenSSL/SSL.py", line 359, in __init__
    self.callback = _ffi.callback(
SystemError: ffi_prep_closure(): bad user_data (it seems that the version of the libffi library seen at runtime is different from the 'ffi.h' file seen at compile-time)

127.0.0.1:60776: Traceback (most recent call last):
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/server/server.py", line 113, in handle
    root_layer()
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/server/modes/http_proxy.py", line 9, in __call__
    layer()
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/server/protocol/tls.py", line 285, in __call__
    layer()
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/server/protocol/http1.py", line 100, in __call__
    layer()
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/server/protocol/http.py", line 206, in __call__
    if not self._process_flow(flow):
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/server/protocol/http.py", line 285, in _process_flow
    return self.handle_regular_connect(f)
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/server/protocol/http.py", line 224, in handle_regular_connect
    layer()
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/server/protocol/tls.py", line 278, in __call__
    self._establish_tls_with_client_and_server()
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/server/protocol/tls.py", line 358, in _establish_tls_with_client_and_server
    self._establish_tls_with_server()
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/server/protocol/tls.py", line 445, in _establish_tls_with_server
    self.server_conn.establish_tls(
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/connections.py", line 295, in establish_tls
    self.convert_to_tls(cert=client_cert, sni=sni, **kwargs)
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/net/tcp.py", line 382, in convert_to_tls
    context = tls.create_client_context(
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/net/tls.py", line 276, in create_client_context
    context = _create_ssl_context(
  File "/home/schmeed/.local/lib/python3.8/site-packages/seleniumwire/thirdparty/mitmproxy/net/tls.py", line 179, in _create_ssl_context
    context.set_verify(verify, verify_callback)
  File "/home/schmeed/.local/lib/python3.8/site-packages/OpenSSL/SSL.py", line 1128, in set_verify
    self._verify_helper = _VerifyHelper(callback)
  File "/home/schmeed/.local/lib/python3.8/site-packages/OpenSSL/SSL.py", line 359, in __init__
    self.callback = _ffi.callback(
SystemError: ffi_prep_closure(): bad user_data (it seems that the version of the libffi library seen at runtime is different from the 'ffi.h' file seen at compile-time)

Traceback (most recent call last):
  File "southwest.py", line 35, in <module>
    set_up(arguments)
  File "southwest.py", line 26, in set_up
    account.get_checkin_info(confirmation_number)
  File "/home/schmeed/auto-southwest-check-in/lib/account.py", line 44, in get_checkin_info
    self.refresh_headers()
  File "/home/schmeed/auto-southwest-check-in/lib/account.py", line 51, in refresh_headers
    self.headers = webdriver.get_info()
  File "/home/schmeed/auto-southwest-check-in/lib/webdriver.py", line 34, in get_info
    info = self._get_checkin_info(driver)
  File "/home/schmeed/auto-southwest-check-in/lib/webdriver.py", line 43, in _get_checkin_info
    driver.get(CHECKIN_URL)
  File "/home/schmeed/.local/lib/python3.8/site-packages/undetected_chromedriver/__init__.py", line 497, in get_wrapped
    return orig_get(*args, **kwargs)
  File "/home/schmeed/.local/lib/python3.8/site-packages/undetected_chromedriver/__init__.py", line 535, in get
    return super().get(url)
  File "/home/schmeed/.local/lib/python3.8/site-packages/selenium/webdriver/remote/webdriver.py", line 441, in get
    self.execute(Command.GET, {'url': url})
  File "/home/schmeed/.local/lib/python3.8/site-packages/selenium/webdriver/remote/webdriver.py", line 429, in execute
    self.error_handler.check_response(response)
  File "/home/schmeed/.local/lib/python3.8/site-packages/selenium/webdriver/remote/errorhandler.py", line 243, in check_response
    raise exception_class(message, screen, stacktrace)
selenium.common.exceptions.WebDriverException: Message: unknown error: net::ERR_CONNECTION_CLOSED
  (Session info: headless chrome=106.0.5249.119)
Stacktrace:
#0 0x55b605b252c3 <unknown>
#1 0x55b60592e83a <unknown>
#2 0x55b605928213 <unknown>
#3 0x55b60591b82a <unknown>
#4 0x55b60591cb3d <unknown>
#5 0x55b60591bb3a <unknown>
#6 0x55b60591aea5 <unknown>
#7 0x55b60591acc0 <unknown>
#8 0x55b6059199bb <unknown>
#9 0x55b605919d92 <unknown>
#10 0x55b60593052e <unknown>
#11 0x55b60599e24f <unknown>
#12 0x55b605985f42 <unknown>
#13 0x55b60599da50 <unknown>
#14 0x55b605985d63 <unknown>
#15 0x55b60595a7e3 <unknown>
#16 0x55b60595ba21 <unknown>
#17 0x55b605b7318e <unknown>
#18 0x55b605b76622 <unknown>
#19 0x55b605b59aae <unknown>
#20 0x55b605b772a3 <unknown>
#21 0x55b605b4decf <unknown>
#22 0x55b605b97588 <unknown>
#23 0x55b605b97706 <unknown>
#24 0x55b605bb18b2 <unknown>
#25 0x7f3698d9f609 <unknown>
jdholtz commented 1 year ago

This seems to be an issue with pyOpenSSL or its dependencies. Does this error happen when you initialize the check in? What version of pyOpenSSL are you running (You can get it from pip show pyOpenSSL)?

schmeed commented 1 year ago

Yes, received the error when executing: python3 southwest.py ** First Last

Version: Name: pyOpenSSL Version: 22.0.0 Summary: Python wrapper module around the OpenSSL library Home-page: https://pyopenssl.org/ Author: The pyOpenSSL developers Author-email: cryptography-dev@python.org License: Apache License, Version 2.0 Location: /home/schmeed/.local/lib/python3.8/site-packages Requires: cryptography Required-by: selenium-wire

jdholtz commented 1 year ago

Huh. This seems to be the error: SystemError: ffi_prep_closure(): bad user_data (it seems that the version of the libffi library seen at runtime is different from the 'ffi.h' file seen at compile-time)

Can you try upgrading the cffi package and see if it works? pip install —upgrade cffi

schmeed commented 1 year ago

Your command didn't work, so I assume --upgrade?

pip install cffi --upgrade Requirement already up-to-date: cffi in ./.local/lib/python3.8/site-packages (1.15.1) Requirement already satisfied, skipping upgrade: pycparser in ./.local/lib/python3.8/site-packages (from cffi) (2.21)

Do I need to rollback the version of cffi to the version you used to compile?

jdholtz commented 1 year ago

Yes, --upgrade (my phone combined the dash). I looked up the error and this was the first thing that popped up. Could you try these solutions?

I’m not really sure what else to try after that (as I can’t reproduce the error myself) besides just deleting and reinstalling all the dependencies for the script.

Thanks for being patient and let me know how the above troubleshooting steps work!

schmeed commented 1 year ago

I didn't have any luck with those solutions. I'll try again. The only change I made was apt update/upgrade.

Can you provide the steps to delete and reinstall everything? I'll try that.

If that's not possible, I'll fire up another vanilla Ubuntu instance in another VM and try again.

I appreciate your help!

jdholtz commented 1 year ago

You can try to just do pip uninstall -r requirements.txt to uninstall all of the script’s dependencies and reinstall with pip install -r requirements.txt. It probably won’t change anything, but it’s worth a shot.

petewill commented 1 year ago

Hello,

I'm getting the same error as @schmeed. I am using a freshlly built Ubuntu 20.04 VM. When I was installing the requirements I got this message: "ERROR: selenium 4.1.5. has a requirement urllib3[secure,socks]~=1.26, but you'll have urllib3 1.25.8 which is incompatible." I updated urllib3 with this command "pip install urllib3 -U" then reinstalled the requirements. This fixed the error but I'm still getting the same error that is in the first post of this thread. @jdholtz are you using a different OS? Could that have anything to do with it?

jdholtz commented 1 year ago

Hey @petewill. I did some digging and found this issue in selenium. I've updated the requirements.txt and the script works successfully for me (I installed a new virtual environment to make sure). Can you try the new dependency versions? It's in the branch fix_dependencies.

Also, what python and pip versions are you using?

petewill commented 1 year ago

Hi @jdholtz, Unfortunately, that didn't work for me. I tried updating first with pip install -r requirements.txt but that didn't work. I also tried uninstalling (pip uninstall -r requirements.txt) then reinstalling which didn't work either. When I was installing the requirements I got an error message that said "ERROR: selenium 4.5.0 has requirement certifi>=2021.10.8, but you'll have certifi 2019.11.28 which is incompatible." I updated certifi to version 2022.9.24 but that didn't help. I have Python 3.8.10 and PIP 20.0.2 running on an Ubuntu 20.04 VM.

jdholtz commented 1 year ago

Could you try updating pip to the latest version? And also, what do you mean by upgrading certifi didn’t help? Did it still show that the package was incompatible? Or was there another error?

Also, it might help to create a virtual environment using pipenv to isolate this script’s packages from everything else on your computer to ensure nothing else is messing with it.

petewill commented 1 year ago

@jdholtz I was able to get it working. I'm not exactly sure what the fix was (probably your updated requirements.txt file). Here are the steps I took in case anyone else runs into a similar issue:

  1. Built a new Ubuntu 22.04 VM
  2. Installed all OS updates
  3. Installed Chrome
  4. Rebooted for OS updates
  5. Installed Git (as sudo): sudo apt install git
  6. Cloned auto-southwest-check-in.git: sudo git clone https://github.com/jdholtz/audo-southwest-check-in.git
  7. Gave my user permissions to the auto-southwest directory: sudo chmod 777 auto-southwest-check-in/ -R
  8. Added my user account to sudo group: sudo usermod -aG USERNAME
  9. Installed pip: sudo apt install python3-pip
  10. Updated pip: pip install --upgrade pip
  11. Copied the requirements.txt contents from the fix_dependencies branch to the requirements.txt file in the auto-southwest directory.
  12. Installed requirements: sudo pip install -r requirements.txt
  13. Ran the normal command and it worked: python3 southwest.py CONFIRMATION FIRST LAST

I'm sure someone with more knowledge of Ubuntu and Git could have done this in far fewer steps. It worked for me though :)

Thanks for creating this and for your help fixing my issue!

jdholtz commented 1 year ago

Great to hear! @schmeed were you able to get it to work?

schmeed commented 1 year ago

Great to hear! @schmeed were you able to get it to work?

I haven't had time to take the "broken" VM and try to find a fix. It worked perfectly on a new vanilla build (Ubuntu 22.04.1 LTS). I'm going to follow @petewill steps above and see if that works for me.

jdholtz commented 1 year ago

Hey @schmeed and @petewill. I just merged a PR that added the ability to run the script using Docker (#19). If you guys are having any dependency trouble, hopefully Docker will allow you to navigate around that issue without messing up your current environment.

By the way @schmeed, I updated your original comment on this issue to use a code block for the StackTrace so it wouldn't reference all the issues in this repository.

schmeed commented 1 year ago

By the way @schmeed, I updated your original comment on this issue to use a code block for the StackTrace so it wouldn't reference all the issues in this repository.

Thank you! I will test this ASAP.

jdholtz commented 1 year ago

Hey @schmeed, have you gotten the chance to try this out? I’ll close this issue and merge the fix_dependencies branch soon because the Docker image provides this solution, but I want to make sure everything was working correctly for you.

schmeed commented 1 year ago

Sorry, been buried lately with work.

What is the expected output from running it via Docker? Does it still sit and wait for check-in? Using the "broken" Ubuntu build, I followed the instructions. I have to run the Docker commands with sudo to get it to work.

Here is the test output:

schmeed@ubuntu2:~/auto-southwest-check-in$ docker run -d auto-southwest-check-in AAABBB John Smith
docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/create": dial unix /var/run/docker.sock: connect: permission denied.
See 'docker run --help'.
schmeed@ubuntu2:~/auto-southwest-check-in$ sudo docker run -d auto-southwest-check-in AAABBB John Smith
40ce84c0de5a7d002ba7f6c64a66e7ce4f35789153071b6d87b852212c5ffb31
schmeed@ubuntu2:~/auto-southwest-check-in$
jdholtz commented 1 year ago

No worries. Here are directions on how to set up Docker so you don’t have to run it with superuser.

The -d flag runs the container in the background, so you can check script output by either running docker logs <container-name> or running the container without the -d flag.

If you are running the script with a fake confirmation number, you should see an error outputted that says something along the lines of Failed to retrieve flight information for xxxxxx which would indicate the script is working properly. If the flight is real, you should see a message that indicates it has scheduled the check in.

schmeed commented 1 year ago

When I run with the -d flag, I get the following and it returns IMMEDIATELY: schmeed@Ubuntu3:~$ docker run -d auto-southwest-check-in AAABBB John Smith cb758daf4d3185c742f44809b50cb7449ab1265ed2b9653918c6c37a569da6c1

When I run it without the -d flag, I get the expected result: schmeed@Ubuntu3:~$ docker run auto-southwest-check-in AAABBB John Smith Failed to retrieve reservation for John Smith with confirmation number AAABBB. Reason: Bad Request 400. Make sure the flight information is correct and try again.

Docker containers: schmeed@Ubuntu3:~$ docker container ls -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a9f610acfb72 auto-southwest-check-in "python3 southwest.p…" 5 minutes ago Exited (0) 5 minutes ago bold_buck cb758daf4d31 auto-southwest-check-in "python3 southwest.p…" 7 minutes ago Exited (0) 6 minutes ago interesting_carver

Does this look right?

jdholtz commented 1 year ago

That looks right. The -d flag makes the container run in the background, so it should return immediately. Then you can check the docker logs of that container to see the output.

Just to make sure, the flight info that you are providing when it errors is not an actual flight, right?

schmeed commented 1 year ago

Just to make sure, the flight info that you are providing when it errors is not an actual flight, right? Correct, fake one for now. I have a flight in March 2023. May have one coming up in December, but not sure yet.

jdholtz commented 1 year ago

Then that worked as expected!

jdholtz commented 1 year ago

I’ll close this as it seems to be fixed now. I’ll also update the dependencies as well by merging the fix_dependencies branch.

schmeed commented 1 year ago

I’ll close this as it seems to be fixed now. I’ll also update the dependencies as well by merging the fix_dependencies branch.

Excellent thank you for the help! FYI, I did check the docker logs when using -d and it worked as expected with a fake/test confirmation #.

schmeed@Ubuntu3:~/auto-southwest-check-in$ docker logs 2cc4c2f13191 Failed to retrieve reservation for John Smith with confirmation number AAABBB. Reason: Bad Request 400. Make sure the flight information is correct and try again.