Forbidden 403 #230
Comments
|
Btw, from the same household and thus the same source IP, I can hit southwest.com and do a test "CHANGE" flight w/ the flight details and it shows the flight itinerary. I am not sure which method your code is using to retrieve the flight details, though. |
|
Oh, and the record locator in question is currently within the 24 hour checkin period for the departure flight.. and was checked in manually yesterday afternoon. The return flight is on this Wednesday afternoon on the same record locator. |
|
This is the new issue that has been come across in #226 and #201. I will consolidate those issues into this one. I can also reproduce this issue in Docker too (both using Chromium and Chrome). I believe this is just a change from #201 that Southwest did that now returns the forbidden error instead of a 429 (which makes more sense). |
|
You probably have already seen this; but in case not, see the Outro section on this post regarding methods of bypassing reCaptcha. The reason I bring this up is we may be dealing with an invisible reCaptcha style algorithm. |
|
@hildebrau Hey. If you dont mind sharing, how did you get the webdriver to work in a Synology NAS? I am getting the following error I am guessing it can't find a web browser anywhere on the NAS. How did you get around that? Thanks |
@Agiang42, I never saw such an issue. Are you running this code as a docker container? If not, that's probably the issue. I have not tried running the python directly on the Synology because I don't believe all the prerequisites could be installed. |
|
I'm seeing this same issue outside of docker, as well. I have two flights booked for the end of March, so if there are any logs that would be helpful or anything I can try with my account between now and then, I'll be happy to do so. |
|
I am also having the same issue running outside docker with develop branch. Ubuntu 22.04 python 3.10.12 Chrome 122.0.6261.69 |
|
Same issue for me as well. Any ideas on a fix? Is there any sense on the logic behind how southwest is determining when to issue the 403? |
I believe this is the same error as #201, just returning a different status code due to Southwest’s improvements they did. That issue’s thread has many details on what I and others have tried, but there is no known fix to this as of yet. Most people are only getting the error in Docker, so you can try to run it with Python instead for now. |
|
Just wanted to give a heads up that I'm running into the |
|
Within Docker, I can still reproduce this issue. However, the requests seem to go through successfully in some parts and fail in others (although they fail at different requests). I've been analyzing the requests that have gone through, used headed mode for the browser within Docker (using Xvfb in SeleniumBase), and messing around with the initialization flags that are being used to start the browser. However, nothing has been working as of yet. Very strange how most people are only seeing it within Docker, but a select few are also seeing it outside of Docker. If this issue starts occurring for me outside of Docker, it will be easier to find out what is wrong but I don't currently have anymore ideas to see what the issue is/how to fix it. |
|
I can repro this 403 issue using a linux server running the python command script directly, and also using docker on the same box. However, everything works on a Mac that is my daily driver. Southwest could possibly be doing some fingerprinting and blocking the connection from untrusted or unseen clients that it assumes to be bots? |
|
This makes sense, as I running raw linux and python and seeing the error. Can we spoof the user-agent maybe? |
|
I just tried this from a Ubuntu 22.04 desktop with Python 3.10.12 and Google Chrome 122.0.6261.111 and the master branch, and it seems to work fine along with the fare check... The system that fails to work is Ubuntu 22.04 server with Python 3.10.12 and Google Chrome 122.0.6261.111 running in an LXC virtual machine same internal network as the machine that works.. If you want logs let me know. |
SeleniumBase already changes the user agent to line up with what headed Chrome has. The user agent can also be changed by adding It seems like a lot of people are running into issues specifically with a server, so I will try on an Ubuntu server VM to see if I can reproduce the issue. |
|
I seem to be encountering a combination of this and #96 on my Unraid box. Running without |
Hey sir! Funny thing, I just setup a droplet/vm (Digital Ocean) to do this, Ubuntu Server 22.04 LTS, getting same error 403, if you are interested I can DM you details how to get into it if you need a setup to troubleshoot that is already built? |
I can reproduce the issue with an Ubuntu headless server too so that definitely widens the scope of the issue and will make it easier for me to debug (and hopefully fix).
@drippyer If this is still an issue after the 403 issue is fixed, feel free to make a separate issue for it.
@j0nsgh I appreciate the offer. I was able to reproduce it on an Ubuntu server, so now I can troubleshoot this further. |
|
@jdholtz Is there a fix for this? Getting 403s on every reservation I put into the config.json. Same error when just using the command line. Same result in docker and not. |
Currently not. It has been working only on my laptop, which has graphics (desktop, window manager, etc.) so if you aren't already running the script on a device that has graphics you can try that--although it isn't the most convenient. You can also try changing line 118 in I'll have more time to work on figuring out this issue after the middle of next week. |
|
FWIW, I was hitting these issues as well. Pulled the latest as of today and ran this through a Docker and it's working. |
|
I've also been monitoring this issue for a fix, but noticed yesterday (without updating versions) that the 403 is gone and was able to retrieve reservations. Perhaps a change was made on Southwest's side. |
|
@dmytrokoren thank you for your incredibly quick response! Alas, even the Logs: |
|
@MicahBird, no problem here to help. I noticed in your headers: |
|
My apologies, it's indeed a typo when I was trying to copy/paste all the logs and correct all the new lines 😅 |
|
I haven't tired dmytrokoren's build. However, I've been running jdholtz's 7.5 in a Windows 10 VM and it's working perfect. Just another datapoint of what works and doesn't work. I accidentally had jdholtz's 7.4 running in a Docker container (running on Debian OS) and jdholtz's's 7.5 running in a Windows 10 VM simultaneously. It both started throwing 403s until I stopped the Docker container. And since then, jdholtz's 7.4 (now 7.5) has been happy in the Windows VM. It has two accounts configured. |
|
@jdholtz @edshaw42 @MicahBird @babehboi - try this image: dmytrokoren/auto-southwest-check-in:develop6 |
|
I also experienced this issue inside Docker on Linux. @dmytrokoren I tried the |
That is good to hear. Thanks for the update. |
|
|
@dmytrokoren Thanks for creating new images for us to test! Sadly, even when trying the |
|
Can anyone test the image I've tested on my Pi, an Ubuntu server VM, and my laptop and all three don't hit 403s or 429s when run using an account and reservation at the same time. |
I just fired it up and my config had a login and 2 other reservations in it.. I received a 403.. but for the most part it seems to be working. 2024-06-21 14:46:24 DEBUG Process-1[reservation_monitor:211]: Successfully retrieved 7 reservations |
|
@hildebrau only happened to 1 out 7? What OS you running docker in? @jdholtz is this the same issue you ran into in checkin_scheduler? |
Yes, adding the random sleep in the checkin scheduler fixed the issue for me. The only place random sleep should not happen is during the actual check-in process. |
Okay I'll add this change and update. |
Synology DSM 7.x, and yes just happened to 1 out of 7. |
Same here. I'm monitoring 4 accounts (6 reservations), I did not run into this issue. I will make the change suggested by Joey. |
|
Just another datapoint - I'm also getting Failed to retrieve reservation for FIRSTNAME LASTNAME with confirmation number XXXXXX. Reason: Forbidden 403. No VPN, and following the same documented procedure I always have, via Qnap ContainerStation pulling latest image. |
|
I think I updated my docker image yesterday afternoon (22 hours ago). I am running the @dmytrokoren develop tag.. I had two check-in's this morning.. they both actually worked; even though the log output seemed to indicate that one failed.. perhaps it failed when trying to retrieve the result?? I have it set to check every 6 hours in the config file.. sometimes it fails, sometimes it works fine. I tried to upgrade the image again, but I must have the latest develop image already.. so that's what ran this morning, near as I can tell. Logs from this morning's check-ins below. I'll have "return" check in's on Sunday evening. |
Saw nearly the exact same thing today. Log shows repeated fails until the Too Many Requests error, yet it still seems to have worked on my two checkins today. Updated to the image above this morning. |
So the check-in was successful you got the seats, curious what was the position? I'm not understanding why the error comes... |
The companion that checked in properly according to the log was an A46, as an example. The non-companion that failed to check in according to the logs got an A45. I assumed it failed on the retrieval of the boarding position step, versus the actual check in step. I remember when I wrote this in bash years ago, those two steps were independent of each other. |
I forgot to mention that that non-companion was checked in "successfully" by the script late last night (2:23am UTC). I wish it would have automatically tossed all it's headers/cookies and started over once the check-in (had allegedly) failed yesterday morning. I mentioned this before; but just to reiterate... every 6 hours it will randomly fail with a 403 or it'll be successful. This may give you an idea of the frequency.. |
|
Because 403s and 429s basically stem from the same issue (being detected as a bot by Southwest), I have consolidated these issues into #277. Please put any further comments, questions, etc. in that thread. |
Happened again yesterday. The position on frist flights were high A group, yesterday's was B1/B2. Curiously, for yesterday's, one reported successful, the other reported failed. Both seemed successful based on the positions. For additional context. My flights included a companion pass as well. |
and others
Version
develop tag Auto-Southwest Check-In v7.2
Browser Version
Using browser version: 121.0.6167.184
Description
I'm getting consistent 403 errors when Retrieving reservation information. I purposely limited my config down to a single record locator.. removing the account login stuff and setting check_fares to false. I updated to the latest develop tag just now as well. I ran it 4-5 times in a row and got the same result each time.
To Reproduce
Running it via docker-compose w/ config.json w/ a single record locator.
Expected Behavior
I'd expect it to schedule a checkin at minimum, and ideally successfully check in at that scheduled time.
Relevant logs and program output
my config.json { "check_fares": false, "notification_urls": "gchat://XXXXXXX", "notification_level": 1, "retrieval_interval": 6, "reservations": [ {"confirmationNumber": "XXXXXX", "firstName": "XXXXXX", "lastName": "XXXXXXXXXX"} ] } docker logs output: 2024-02-26 15:23:21 DEBUG MainProcess[log:23]: Initialized the application 2024-02-26 15:23:21 DEBUG MainProcess[main:112]: Auto-Southwest Check-In v7.2 2024-02-26 15:23:21 DEBUG MainProcess[main:113]: Called with 0 arguments 2024-02-26 15:23:21 DEBUG MainProcess[config:120]: Initializing configuration file 2024-02-26 15:23:21 DEBUG MainProcess[config:149]: Reading the configuration file 2024-02-26 15:23:21 DEBUG MainProcess[config:163]: Reading configuration from environment variables 2024-02-26 15:23:21 DEBUG MainProcess[config:58]: Setting check fares to False 2024-02-26 15:23:21 DEBUG MainProcess[config:80]: Setting notification level to <NotificationLevel.INFO: 1> 2024-02-26 15:23:21 DEBUG MainProcess[config:93]: Using 1 notification services 2024-02-26 15:23:21 DEBUG MainProcess[config:97]: Setting retrieval interval to 6 hours 2024-02-26 15:23:21 DEBUG MainProcess[config:139]: Creating configurations for 1 reservations 2024-02-26 15:23:21 DEBUG MainProcess[main:142]: Monitoring 0 accounts and 1 reservations 2024-02-26 15:23:21 DEBUG Process-1[reservation_monitor:60]: Acquiring lock... 2024-02-26 15:23:21 DEBUG Process-1[reservation_monitor:62]: Lock acquired 2024-02-26 15:23:21 DEBUG Process-1[checkin_scheduler:50]: Refreshing headers for current session 2024-02-26 15:23:21 DEBUG Process-1[webdriver:106]: Starting webdriver for current session 2024-02-26 15:23:23 DEBUG Process-1[webdriver:122]: Using browser version: 121.0.6167.184 2024-02-26 15:23:23 DEBUG Process-1[webdriver:126]: Loading Southwest Check-In page 2024-02-26 15:23:27 DEBUG Process-1[webdriver:64]: Waiting for valid headers 2024-02-26 15:23:27 DEBUG Process-1[webdriver:155]: Waiting for headers_set to be set 2024-02-26 15:23:27 DEBUG Process-1[webdriver:159]: headers_set set successfully 2024-02-26 15:23:27 DEBUG Process-1[reservation_monitor:84]: Scheduling flight check-ins for 1 reservations 2024-02-26 15:23:27 DEBUG Process-1[checkin_scheduler:76]: Retrieving reservation information 2024-02-26 15:23:41 DEBUG Process-1[utils:39]: Failed to make request after 20 attempts: Forbidden 403 2024-02-26 15:23:41 DEBUG Process-1[utils:42]: Response body: { "code": 403050700 } 2024-02-26 15:23:41 DEBUG Process-1[checkin_scheduler:82]: Failed to retrieve reservation info. Error: Forbidden 403. Exiting 2024-02-26 15:23:41 DEBUG Process-1[notification_handler:76]: Sending failed reservation retrieval notification... Failed to retrieve reservation for XXXXXXX XXXXXXXXXXX with confirmation number XXXXXX. Reason: Forbidden 403. Make sure the reservation information is correct and try again. 2024-02-26 15:23:41 DEBUG Process-1[checkin_scheduler:57]: 0 flights found under current reservation 2024-02-26 15:23:41 DEBUG Process-1[checkin_scheduler:43]: 0 total flights were found 2024-02-26 15:23:41 DEBUG Process-1[checkin_scheduler:100]: 0 new flights found 2024-02-26 15:23:41 DEBUG Process-1[checkin_scheduler:104]: Scheduling 0 flights for check-in 2024-02-26 15:23:41 DEBUG Process-1[checkin_scheduler:116]: 0 flights are currently scheduled. Removing old flights 2024-02-26 15:23:41 DEBUG Process-1[checkin_scheduler:132]: Successfully removed old flights. 0 flights are now scheduled 2024-02-26 15:23:41 DEBUG Process-1[reservation_monitor:71]: No more flights are scheduled for check-in. Exiting...Additional context
Synology DSM 7.x
Docker version 20.10.3, build 55f0773
The text was updated successfully, but these errors were encountered: