-
Notifications
You must be signed in to change notification settings - Fork 5
No results even though 'success' #7
Comments
Hi @RayBB! It's entirely probable that SW has changed their private API, again. I'll take a look at some point but it's sadly hard to keep up. It might be easier to go back to a web-crawler interface instead of making raw HTTP requests... As an aside, your use case is one that I hadn't considered. I'm surprised that they wouldn't "make a route" for that kind of trip. |
Maybe that don't make a route for a trip like that because of complications with checked bags or some other logistical challenge. I even messaged them about it and they said they can't book things like that for us over the phone either it would have to be done manually. Maybe doing a js based thing in the browser will get more consistent results. Once I got this working it was still intermittent and will work one time but not the next. When it does work it is fantastic though! Here's what I found: Spoiler{
"details": [
{
"originationAirportCode": "LGA",
"destinationAirportCode": "TPA",
"departureTime": "14:30",
"arrivalTime": "22:10",
"nextDay": false,
"totalDuration": 460,
"flightNumbers": [
"431",
"653"
],
"filterTags": [
"NOON_TO_SIX",
"AVAILABLE",
"STOPS"
],
"departureDateTime": "2021-06-22T14:30:00.000-04:00",
"arrivalDateTime": "2021-06-22T22:10:00.000-04:00",
"segments": [
{
"originationAirportCode": "LGA",
"destinationAirportCode": "HOU",
"flightNumber": "431",
"duration": "03:55",
"numberOfStops": 0,
"departureTime": "14:30",
"arrivalTime": "17:25",
"departureDateTime": "2021-06-22T14:30:00.000-04:00",
"arrivalDateTime": "2021-06-22T17:25:00.000-05:00",
"operatingCarrierCode": "WN",
"marketingCarrierCode": "WN",
"aircraftEquipmentType": "73W",
"features": [
"WIFI"
],
"wifiOnBoard": true,
"stopsDetails": [
{
"originationAirportCode": "LGA",
"destinationAirportCode": "HOU",
"flightNumber": "431",
"legDuration": 235,
"stopDuration": 100,
"changePlanes": true,
"departureTime": "14:30",
"arrivalTime": "17:25",
"departureDateTime": "2021-06-22T14:30:00.000-04:00",
"arrivalDateTime": "2021-06-22T17:25:00.000-05:00"
}
]
},
{
"originationAirportCode": "HOU",
"destinationAirportCode": "TPA",
"flightNumber": "653",
"duration": "02:05",
"numberOfStops": 0,
"departureTime": "19:05",
"arrivalTime": "22:10",
"departureDateTime": "2021-06-22T19:05:00.000-05:00",
"arrivalDateTime": "2021-06-22T22:10:00.000-04:00",
"operatingCarrierCode": "WN",
"marketingCarrierCode": "WN",
"aircraftEquipmentType": "73H",
"features": [
"WIFI"
],
"wifiOnBoard": true,
"stopsDetails": [
{
"originationAirportCode": "HOU",
"destinationAirportCode": "TPA",
"flightNumber": "653",
"legDuration": 125,
"stopDuration": 0,
"departureTime": "19:05",
"arrivalTime": "22:10",
"departureDateTime": "2021-06-22T19:05:00.000-05:00",
"arrivalDateTime": "2021-06-22T22:10:00.000-04:00"
}
]
}
]
}
]
} Aside from that things seemed (idk still not consistent) to work when adding these headers: Also, 'ee30zvqlwf-d' and 'ee30zvqlwf-z' seem to have changed so I did update those in my code. I can make a PR for the segments change if you'd like. |
Sure, go ahead and open up the PR if you don't mind! |
Heh I noticed that at least on chrome (doesn't seem to happen on FF) the SW site starts giving search errors when you open the dev tools. I'll open a PR later. |
I've been playing around with this - it seems the headers are only valid for a short amount of time. I had to do what @RayBB did and update all the ee30* headers (I also seemed to have an additional one:
|
Has the request header been resolved? |
Hi folks - I'm mentally switching this project to abandoned, unless someone else is able to come up with a solution to the magic headers and PR it. I've tried a few different methods and from what I can tell Southwest is just too sensitive these days. They can always tell if you're scraping - requests will just get 403'd. Sorry! |
RIP. Thanks for keeping it going as long as you did 🙏 |
Hey, I don't have time to make a PR just yet, but some other projects have figured how to get the headers programmatically - see: https://github.com/byalextran/southwest-headers, you could likely have this script run, and grab the headers before each search. |
Huh... I spent a few hours yesterday trying to do exactly that (even down to using selenium-wire), but the headers I captured weren't working for future requests for some reason. I'll try this out and see if it helps! |
I spent quite a few hours attempting this, and could not accomplish much. The headers never worked out for me, so I played around with the chrome webdriver and seeing if I could actually get to the SW search page. This ended up working which gave me confidence to just use the webdriver code to actually fetch all the data, but the body of all the request looks like this below: I'm not sure what kind of encoding this is, and decided to stop here. SW likely killed this :(
|
Hi @redfern314 , Have you looked at https://github.com/jdholtz/auto-southwest-check-in/ to pull the header information? |
CMD line returns 'success' because the code is coded to catch HTTP request errors (403, 500, etc.). I believe the issue is with CORS, and unless you are on the website and on the debugging console running JS it won't work. |
Hey folks - appreciate all the input here. I'm going to archive this repository. Any of you are welcome to fork and revive it, using whatever method you think will work; it's MIT-licensed so go wild. However, the main complaints I had when I originally made this have been resolved:
Personally, I don't have much use for a tool that runs locally and breaks frequently, when I can just go on Google Flights instead :). |
Hey there, thanks for making this awesome tool. I really could use something like this for some places where Southwest has planes flying between two locations that require a layover they don't make routes for (like HNL to LGA).
Anyway, when I search I get empty results:
Any ideas? I updated the request headers as mentioned in readme.
The text was updated successfully, but these errors were encountered: