Open jasonwbarnett opened 3 years ago
Can confirm this exact behavior as well - happening from both AWS and residential IP addresses. (Thought it might've been blocking AWS IP, tried residential). This was not happening earlier in the week. Looks like something just changed very recently.
On latest master commit (6738effcc56aa70f008b25af645327431d808079)
Yeah I used the bot successfully on Tuesday (August 3rd, 2021). It failed to work yesterday (August 7th, 2021).
hmm. i wrote a ruby gem that's similar to this. also ran into a 429 error today when things were working a couple months ago. i tried sleeping 30 seconds between calls but still get the error. i think there's something more going on than just rate limiting.
unfortunately, i'm traveling this week and don't have much time to troubleshoot. but hopefully the hive mind will uncover something so we can all fix our code.
I have a .Net checkin program that has stopped working as well that is getting the same 429 error described above. I think it may be related to the issue discussed here
Same problem here
Sorry! This reservation is not eligible for check in. This flight is currently not ready for check-in. Please try again momentarily. Attempting check-in... Error. Error. Error.
I had the same issue where it just showed about 20 'errors' in a row. I manually checked in and noticed a Covid 19 health acknowledgement screen you need to accept first. I wonder if that is what is screwing up the script?
Yeah, noticed it isn't working now... :(
web.1 | 18-Aug 20:39:51-INFO: Attempting check-in...
web.1 | 18-Aug 20:39:51-INFO: Error.
web.1 | 18-Aug 20:39:52-INFO: Error.
web.1 | 18-Aug 20:39:52-INFO: Error.
web.1 | 18-Aug 20:39:53-INFO: Error.
web.1 | 18-Aug 20:39:54-INFO: Error.
web.1 | 18-Aug 20:39:54-INFO: Error.
web.1 | 18-Aug 20:39:55-INFO: Error.
I had the same issue where it just showed about 20 'errors' in a row. I manually checked in and noticed a Covid 19 health acknowledgement screen you need to accept first. I wonder if that is what is screwing up the script?
it was definitely working this past year when there was a COVID acknowledgement already, I'm inclined to think that is irrelevant.
I was able to track down the problem, but haven't found a good solution. I'm hoping that others can look at it also and try to find a permanent fix.
The problem is that some headers are missing that weren't previously required. One of them is the user-agent
header, which can be hard-coded so it's not a huge deal. But there are several others that are required, and I can't figure out where the values are coming from. The headers all start with ee30zvqlwf
, and once I figured out that was the problem, a quick Google search led me to this project: https://github.com/redfern314/southwest-search. There are notes on a temporary fix in the readme file in the project, but it says the workaround might work for a number of days and it only worked for an hour or so for me. It looks like that project was updated with those headers over two years ago, so it looks like it's been a problem for a while (just not with the mobile service until recently).
I'm going to keep looking at it when I have time, but it would be nice if others could try to figure out where those header values are coming from as well.
This also might be useful reference: https://github.com/Fffrank/southwest-alerts, they're just capturing the headers and using it again. It might be a valid strategy here too.
I have a .Net checkin program that has stopped working as well that is getting the same 429 error described above. I think it may be related to the issue discussed here
Hello, do you have your .Net code on GH? Willing to share?
This also might be useful reference: https://github.com/Fffrank/southwest-alerts, they're just capturing the headers and using it again. It might be a valid strategy here too.
I hate the idea of relying on "browser" clicks to get the header values. Ideally somebody will be able to reverse engineer the API and be able to generate the necessary headers each time, but until somebody has time to try to figure that out then this can be used in the mean time. I don't know when I'll have time to do that (might be a couple weeks), but I'll look into it when I can.
@jaredhughes2 I've been thinking about this and I was wondering what if we used the Selenium WebDriver to do the browser part automatically with a headless browser? It could be cool, but the additional dependency is annoying.
In the past when the script worked you didn’t have to ‘check in’ but the option to retrieve your boarding pass was there. If you had to ‘check in’ I suspect the script didn’t work.
Southwest has a very interesting way of doing boarding positions. Many times I have gotten low A’s even ahead of people that paid for early bird. SW has an antiquated system and based on cancellations and other factors it’s a bit of a crap shoot.
On Fri, Sep 3, 2021 at 12:09 PM mkitchingh @.***> wrote:
I just had a failed checkin too, but something odd happened, I think. I didn't note for about 15 minutes, and I went to do a manual checkin for my son and I. We got A16 and a17. It made me wonder if the checkin was actually successful, but it the program was unable to detect that. I can't really believe we got 16 and 17 15 minutes after checkin opened.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/pyro2927/SouthwestCheckin/issues/70#issuecomment-912684881, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJREYKM27DSVJA4MAO6JPXLUAD6LJANCNFSM5BXU6U5A .
I made a temporary workaround, until we figure out something better: https://github.com/rschoen/SouthwestCheckin
Grab the headers from the browser / burp proxy / whatever, and paste them into headers.txt. Then you can run the script as normal. No promises on how often you have to refresh the headers.txt file though. Other sources indicate it's valid for some number of days.
@rschoen I only get a response of access denied. Can you provide more instructions in your fork?
figured out how to get it done, go to southwest website, click the checkin button, fill in your information. Right click in the web browser and say inspect, go to the network tab. Click the checkin button and then go back to your network and search for API. Select southwest which is the correct request and it gets you what you need to paste in @rschoen's workaround.
Can confirm @rschoen script worked this morning
@rschoen updates worked correctly. The next step is have it automatically get and update the response headers.
I think this could easily be done using a selenium web driver, i.e. https://stackoverflow.com/questions/62262261/how-to-get-request-headers-in-selenium
This is some untested code I whipped up that shows the concept.
from seleniumwire import webdriver
from selenium.webdriver.chrome.options import Options
REQUEST_URL_WITH_HEADERS = "https://www.southwest.com/api/air-checkin/v1/air-checkin/page/air/check-in/review"
chrome_options = Options()
chrome_options.headless = True
driver = webdriver.Chrome(options=chrome_options)
driver.get("https://www.southwest.com/air/check-in/index.html")
# At this point, fill in check-in form and click submit.
# Search through requests and find the one with the headers
request_with_headers = next((x for x in driver.requests if x.url == REQUEST_URL_WITH_HEADERS), None)
if request_with_headers != None:
for header in request_with_headers.headers:
# Pull headers from the first request here.
print("%s: header", header)
else:
print("Raise error here")
driver.quit()
I've done some testing with a very similar script to this. From my testing, it appears that only the X-Dublriiu-E
header needs to be passed (along with the X-Api-Key
and X-Channel-Id
) to POST the data. The header resets every 5-6 successful tries, but it doesn't seem like it resets after a certain amount of time (although more testing is definitely needed). If we can somehow figure out how that header is generated, we only need to use that one and not all of the headers.
*Note: This is all from proxying the Southwest IOS App
Thanks to this branch it works as long as you manually pull the headers. I tried letting them rerun for my return flight (3 days later) and the headers were no longer valid, so the time window must be a day or two. I wrote something leveraging what Jason posted above & using browsermob proxy to copy header data. SWA site would not respond well to any selenium driven browser. I had zero luck with firefox. Chrome worked after hex editing the webdriver.exe file https://stackoverflow.com/questions/33225947/can-a-website-detect-when-you-are-using-selenium-with-chromedriver/41220267 The request looks valid. I can copy it as powershell code with the headers & get a valid "Wait till 24hrs" response. However with those automated headers its back to the original error at the time of check-in. Reviewing the headers, the only thing I see missing is "ee30zvqlwf-a0". For some reason with selenium that header doesn't appear. I have tried without the proxy & leaving the automate chrome window open to inspect the headers & still no a0.
@djre4orm nice find on the hex replacement to prevent sites from detecting the use of selenium web driver. I'm going to test this with vim on Linux and see if I can get positive results.
I will look into this soon, but if the headers can't be easily reversed I could see the possibility of just making this a multi-docker app and using a dockerized Android Emulator (https://android-developers.googleblog.com/2019/10/continuous-testing-with-new-android.html) to open the app, then steal the headers from that. Or I guess at that point it could just become some automation around all the app functionality, but I'm having trouble imagining anything done that way that won't get broken by a UI change. Potentially we could use adb to broadcast intents to the app. I'm just throwing out some ideas I have as an android developer, if I get some time over Thanksgiving I'll see if I can't experiment with some of those ideas.
Failed to work today, I had updated the file from the network around noon and checkin was at 4pm. It had worked previously.
Failed to work today, I had updated the file from the network around noon and checkin was at 4pm. It had worked previously.
Might want to double check your headers, I just had it work this morning with an 11hr setup gap. If you have done anything funny with selenium or browser automation pulling headers can get messed up. My recommendation is use incognito window in that case.
Here are my headers from a working run :authority: :method: :path: :scheme: accept: accept-encoding: accept-language: authorization: content-length: content-type: cookie: ee30zvqlwf-a: ee30zvqlwf-a0: ee30zvqlwf-b: ee30zvqlwf-c: ee30zvqlwf-d: ee30zvqlwf-f: ee30zvqlwf-z: origin: referer: sec-ch-ua: sec-ch-ua-mobile: sec-ch-ua-platform: sec-fetch-dest: sec-fetch-mode: sec-fetch-site: user-agent: x-api-idtoken: x-api-key: x-app-id: x-channel-id: x-kl-ajax-request: x-user-experience-id:
i appreciate all the eyes on this.
if i understand the problem, southwest added some new request headers that need to be used when checking in. since we don't know how those headers are created, they have to be scraped. but they seem to change regularly (under four hours?) so that new request headers are needed after a certain period.
if all of that is true, i think we can take @jasonwbarnett's code and programmatically get the request headers before each auto check-in attempt.
here's an extension of his code. if you pass in the confirmation number, first name, and last name, the code will output the necessary headers into a JSON file (request_headers.json
) which could then be read later when needed.
https://gist.github.com/byalextran/e38cf6321eb78a3a1f79cd282ab69314
i don't have an active confirmation number to test the solution (i will wednesday) but throwing the idea out now for dialogue in the mean time.
if someone has a confirmation number they'd be willing to let me test with beforehand, let me know via my contact form. https://www.alextran.org/contact/
You can always book a flight, try to check in, and then cancel for a refund. They are required by law to give you a full refund within 24 hours of buying the ticket.
You can always book a flight, try to check in, and then cancel for a refund. They are required by law to give you a full refund within 24 hours of buying the ticket.
This does not apply to flights booked less than a week before the flight date.
I've never had a problem doing it with Southwest in the past. If you think it might be a problem, you can always book the more expensive, fully refundable fare. Not like price matters when you know you're going to cancel anyway.
got a confirmation number to play around with this evening. unfortunately, something's still not working.
i can dump the headers programmatically but can't check in with them (429 error). however, if i manually save the headers from chrome, i can check in.
based on my testing, it seems like these are the minimum required headers (on the POST call):
{
"x-channel-id": "MWEB",
"x-user-experience-id": "2e947457-6e15-4505-b230-b91c4668b071",
"content-type": "application/json",
"x-api-key": "l7xx44e0282659f14664b831eeba67b38a6e",
"ee30zvqlwf-a": "0jcTP8QWfLUAcSWNY1SUECc9nS1N_yAOtKd32pWHrJ839B1YX0zkJFJVAKQ=i9MlqKsyigspmzjM1MpTPRIXQ7LSTMa0ffTHlcZmrCt0DRKiFf_16ASCHoCpgeXCAqZB6AIaZ_YtfEslleiCaKY7l9Ym1_9YT1jM8nmwieSIV=uovrv_LPYD5awg2eZ-9Is91V5cpQ2oP4SePcQ-ez31TIOt9FmTRZ3vQ61HEPNzoPVWSH601g5WEuKyEVNqphVjMzm=m0f8n3CfIigsrZhpCsV5mKq4EKQPWJqnzkUU2IPT3m8llwXbMPEBonDVD1glZkpuTc4K0AYByy=bqCMOwFKVR8IFdFkbmnVwUk-WXJHHMOVAfO_AQkQRaX4sj96_ukR78R6hdQLWrr8UbRgjtuctCBfLQj3XgLtwWIcyw_=K5IqX4i8Csr=YJC9NKtVmqKbFB69LX5ZmIRhnwt=cD0OB9-TA8rSbeBYAQT=uV2ZWt7nEV5DHQPPLRnu2uz4_bS53DLZXmykF209Eisq2Rdm-COr3ndpKHyFdVJsdRY4uy4uZpipX9kiQoQ=V-=nBHDOkKeBnjZ1KRJd7b6poLEFnT-ZtzdMtaS71VaCr_Vo4UkmUuQz30ZN4sN9AiKSPyvDCW8v2qVXhWzsMWpGD9tOXvruTPNW=_aFGbrWCmtJbfIKb8wuilEV8sGBKKBH=T1MQoWCsvgnS4A5dNtWLl=Y==2Pnk86I8dF4Yg7QAghRvsQEJsClJJQkDoMBjFHmM_PvJr=SIjD106bOIlF7KeI2lT7Q72DQE_n=2gp0r-efU2hJ0Fv=3psBOiFb5b2FDDgQtkkNpHgLPCc2LIJCrrmGqPGMYjYbjc=ciqJuqj3yMuQaFrgmFE8nmlXWaIS1_70tbZD3FbG0CfO2c1KeXvZqX9VwoLXo=fa7VzA3TyZS32z30XZ_MAKMAmIfH8c3gCrmCoB_RgdCNR=WngbheeFqL7DHZjaWqXyBqQn3dSf_P7zUvDNVNW671TAJKKsQmOF0kE7sP1e9-wb7C-WvGAgEz8HONrvk7TNLM4VlstgNb2VWz0KZvKmrOycuZs5j50a9_YhnY1HeMcIZHucdl18=va=D-OrEmZzR6IfEtAAiK7cWIRUu57m0f3F6uSAmZc0AGeZ-Dd=V5=YIcdwFhCH-QWeBMIYVmSI8hsSUJQ07sB3Yn5_Nh1PWYOTLcLQ6Gs8Uv11hwI0oFz1jzepPUXq5a0OB-qch4KWey=JD41EPW5fT9RRpIPw3kzzCDTMXHNjVEKAbT4lVicKrCWr1BLfaVB0sR9kKaITluYc_Ft4ej6KZfrHd0K034tYTNuZh6AmLId6CfWdtF3qPR7FB8MAzA=J1T3YUVAHX07sTAR6Y62W_-=DpStBLqmXByB7Ztl68JLCk6repiBGby6VmP2f5sIobEsWRYVWJh=N66EGDBW04Sm1BoEkXyV8re7fYQ=FIWUauIDHXeipUpzy8YW6fE9Tj5Zt8gjAwWgUPbm533oNa8AtMXaCPqr=e=UgnEyP8nwdBaSgAOB68GbQG2l5SzE_vjs3v0pY0fcHKTVwuU7KlIXkjDNj3hm7PY0sINlFnELc1fw7uG=HYDcZqSErphKdLpPlNMEyoLYRN-_ZVZq_r2MlUNXo6-NAa6v-j898hzhN2yorLXNNFjn6mEO5tt-GK45AiDJVL-dSXACt5hkBIA_0Gg2A-fhg-rTl6rP1mADbrOYP-JeDvqKCWQvRlkTYQ5_imaru1DOQXYOaXDbGUHeJZj1j1fma75yVbvGGqQBq9fVagiWvdgDXl8DpD==_ybNvGMp193JCI0097INpumjmcmdJuAYu6HNtj2D2T1NEiliNJt5gdcKHSmKCbUh7gIGpJ-MY6bbRKzpfjAQ52Kd2N72UJ7ksAWfyGQlsC6s7gRrJvkQUpmCXfm145djXehaXlAtZOAu8lHHSiQke6UslchMcL2_QO3J-ksBbsKDM_jter_KrLEe8spE8QOnTMLqTeQJjkaruLRZ7RABedzM5la_ajbzi3sOFUsCoDXfUY9Tyz2YJzfHrXryU=7HduXfYK=pOOOSI-a4mZL-A5lTPPRSuK8Pu_np0oH9hiL4bN6r-F46cuQ9VtB6yYiIOWR9SaE0Q1cFScKg4klMvXePY9VvllSl6RWUhp4r9urVZeS0wkjhjj7C2fsKK_mHH5SJvGO5PgvQUoJwQpQugAcnXmR0ivc-77uMhoC5krvMEzcH96vQ3pXtDSPRq3XLIeYngnA_lLUeMcj_8froUDJjO9D0klPIkYjN6W-ZwfYy1NtQgF4_lzRDTVsJXI3bBSXt1am9GvAVhUzo=5FWRn9SEvVsjvdMfVv2bFb7vv4NPcCnlZQZ4o3H0Z4HU5Q1lFwEGEy6tJPd=gYoT8-mLje4go1o9VU4j60YlyN5B3d=0=DnJvBzBwfM_nYoRT-Bs0OD4TE7iSXN8FdLOIDjTnt_0v1SFA7kDE3IZhMjI4DVMPztA-4Vz4vVZy4a_da3=0HkqEK=hU-BMhBovju_KC7O3wfuEcVGY4QdBIzYnfsw-WSpr9YqQl0BIc_sziYmJ2BeqoI8L3zgVshlUOQdU1Y39pgkZFkrQriISyV5BTmadzgeC=1W0YuTS8Eq55-mhKUK4RzA2PZEqyD5y3a_GtL6o4iUQnfcri5gcpsysMHZQGjZ8-bMGUGCDePHe8JQ44WRM5VRJJ8cal7OOjXe8NlwlQzuDNjI1yhQIgIW2l6P061_4G234jotZ7nJMa_DOy2rTsI5FsB0sJWU=g_jZmO1516NMi41ZCd7Sngy-OdNAwYUeKCnUEGS4cOee70lB3CGzcJI8wgL9geKDG=1ChqEdiAGrjbiW39R5iQNS8irQvncLdnEkERnBgy4RZUzN7L54vHhzo06ICX6SCNup9GkrvamE0kSqeJsuVs7dfff_lfEymlOQpZzvyXSIX0qaWt1ImtZrJFl_HUzS-vl_cPvugz2rCCQnSndR55vINJRMHdBHZKgRBHwTXq2qn32UyfgCMzqjpynwOeL3MpZQPDWDzcY-KuEhLKqXzDp1wv4qkuOtc1SMPL3KliljGQDzKmf8PHavh9ZsL4-NJlbkZCBmTSYdk168o3kgksK2PLQ0sDdI=IQgwoAW1S3rcXQjfnWUH6bOf=YLKn07kE1qIZtrM81BJmbnbyVm-tFr48fAogd3RgBpED1w4W0KORebMhR8wM6uTErd7HawySVsnDYfsz=8G3INPl2Adom3P3irSdz8SSLRJ6geU50f63sajeyoRGKcjlMth7htm8auR124-nsv7ndrNPSreOC==ey9liWhOE0s=bDP_ORp3DJh62PHQdRLj_3wYMImtZKhsbfGmzhg-qsQjTC=zMVDyRgdbDNGdcVksC_8_eLudmWB6qj0F2V-0YPCqTt5q9wF8WetUGkqbgLLOyZag-78Ap8YtwfhdCI3K9tUsGCeWs48Bd2s5JoOZmatfsiIqP5wr4y9jXC8qKqt-GTDsqlOEwk1aquig0z3R6kY6nSJerj7bWGlXIBtR-XEbej2GcnevftohL7IliU0ZPg4Yl63FCrDsa-8GORnOsyAkf7HvwG2fd-QuOVEmaiG9qcIyjDlszCEDYGdj-Xa8mSm4bSBmp053pBeANZCa_s-k77I-3CKN29wd7ldoWnP3I9=fnWDv5Mqf_KymjiC-3D8-OfrMn9_V4kw9fHLXd1JtB3DumYlEq9VEBS=1CoHSBS0LjUtWA581KXqVv3ysB6XECpb=Df8yDn6gMI_329Df3mwX4gcyypV01vXMrG=BeDuzCaovFWvYrbYEr5PFFyvwP7Hh_2J509ymOB6Pz7DRtQwhX-w5lCjRJlpg5nG6yt-m33m-Vw9XUT2Cey2tqwLG0prsPAW_QwAbpIk21rGraB3_vB_TDJnaPqwHfjwCnZiFLZ=3iLQtCfTKrQkXT6o6L5BgstrMSuXmQidOrhfkqr1YB05_9uks8lo-ufSVfDNuqpolOEW6Gb_XM1N5mlEL5kJUSB2YmV3IL2Z7O3A_rPz5bVulGYg4qNS=ZiISPSvIWUDFKMa9lMzDmqVy-z46kjW=5ustsm2Takmrd4i05JE=C4dEb3BfYFMJtwMzBdaBgAwaiABAig-KDyp3CCN73nHjApC_1Pq33kw8B17Ldz_3y1qccz_5yhM5L5hJDlfLqRst-5ToT0UCW9ja8er_WD4CbFMAU1zmC7gt0sM6K_mW48K6sg7SdFnyNq=T7EGyoBz9OyKfEd9cz8n6FXRwc=00l-0vFXPOHenamuEX06TRd5__bd2uNuZQynNwXCgqP0a9AymT=yBPoPFY_Vwcpe3Pd-r5hU2q7s42SLDyR9RfBgEaAgt6m4_7-o_bqjsKnfEaEKNw7bZnD7qiy22rJF=uiJPA4clezbn=TAi_7RZnbkCC5yISLgPFAIMZzZAZs9ig9wIPyW3IGmmVcA=EFWklbZEzN3v=Z7bB2bRjz607vCWS-HtjpBBCWeROkRLRc_5veJFoIQX=WEPNWZK=jy73vv6uY_N5qqU5pWVMpUBlRyRs1roEjdUw216=BE-neCB1gB1f-22Mn=9XqvWsHaK9C0a6SHCFwQvi=C3o_GIIMw9sGu==DP3b4jmN-bnESQHIA5-efphnTwWWTsDqiW-J=nc6VOh5cv3M2Bs23syylLgWj0EAv_lt-E-WlT41WREuzgTzTrlXwBzArOHanR3PXroiK2vQiSpL=0gp8UQUl91NXQORbUiEpSDPs0hI_XOz0Ye6ezs-HHNCV9jJvemwNfqsMUpIrE7LHTt5Vn4BwAqH18EJuKzZVfHGXZnBHhBtysajs2kGJOTQybbzGqF_-PdRFGJhlR5GXF5zow26QdCjOfg94g9qYEln4IcyYArnbd_b_OWK-YZUyB6CIV5nO1ssE3k8zQ=eAWbkzGR0CTtFNdBUIIZJ9CrUHG_W6oR=yUMwAFwHf-gWgAcnTGz0WL5zutsH-UNeU0UMk_K_HGfckwmtGhOhtDhCD4y-3j-KC5A-PmjVtAe2i9PSk0dzpWfsDGgJWvfMnJJvwdS0PUlfqMcnaE21AYhd3Dqh9aBSOJmIl_hrvpgNdZH0yfrMrHO-XOfCRPhIuUL1c0oHPUT--180n3nsefy5GqW8cfMaJiBaedW-IRPkWZg0q64vG_CHYdW_ckrO=RdVIB2Tk9vXyAqG1wyvrYbw=O90IGlJpptEN0biIdTh5jaBX-hjBtWVpRj1-zAZypl9YqSSIgM2a3s0dPyMGPcZAvE=Il8OY0RwXehtIl5CJ1EWQHU1JFCrC_pRBN4UQpGf-qLj=ZZGe0NlwuFVKGyfLDABqX8VoANE97dGIjle=qzXHj03V-5ZhIOV3b3iGMHccrOLh15blR_8iE=Pfusph47VrdtDdVDoW02lu3H7vAi5lUEIoGT7Kd12QEPM0IqNPutPjXm7nCoUCLe6NF_MvAhS0FiVr_eL2r_=utPeWphAEzQV1u00KYhNJ5KUMYjsBb=JW2_GwFYr_5-7ikrk7Iz9ymUI4Yr_zJ3=T2nWG-rQ8QZf0Z_bp-N83WbBiJ9wEW__2YEuAzguleGDLt0IZd1sA23ykdzv-081i7aWjmUpfRgRPddKXwCYRiaSbJtzuNhtZbFqFm9zILrjU8AoXTeqomECb06FRlgDXvReb0FJMhBrB7J71Vw1YmQdkTndKQ2Tbg6M6RG=BSDOGpVquvnR3IuKbGiD2rYcHv=0Xo2yu_FVLkE3hE4T-lSKW_vaYusNHy1REa7qHwofCq-Hh1QOdfUZS9SEN3I1=D-y5upb_aC5kLB_1RAkcfXteTqfMFvL-09l=Hd2FVQfFj5JHo4G6Lg8sSt-j-Gc53rMP1WS8NW=pJqJuJ0q8QbjlQhuawBj0aEdcPhXhs9ZWXgl5hl9UMYin_GVm3HjsTDNPQbujAF1lV3t7=Qmo1NqNCZ2ky8gn1Ob3LAyj97aBKWnytB8tRYXX7PaLKiuIodIMlJWO5IThKDp-6tsIZo-PDHLm80FCpyL3s=LVA0UkENMUVSIpA1cjcwDbO48tU_cJrSOjBsbTseeDDh58Pek2jWSmkNCjkRL6ha6rZB8zAZKdisqj5r2QokX37u1l-1eoYP1SKJRl1gN1MhPDOZd9-XkjT66wXisaZd3MpeHiTv1LI-h9b=ztJtrk=9LZ5Ir6QXjki2BILpwDhHoUpFIaw-R1npK09DU9FD-io_oLU0Gama6srMkmEV8P11QtQt9vtVBjDckOYu8mN=J18dGoF2YAv07PIe5SI2MSwTyo9m0gz5dnI00SMDMOkfIOgjC65Il_SElgudF9O1XncJ-LHqKk58UYMj7GBTU",
"ee30zvqlwf-z": "q",
"ee30zvqlwf-b": "mnk054",
"ee30zvqlwf-d": "ABaChIjBDKGNgUGAQZIQhISi0eIApJmBDgDQiciH205akf____-jCnTyACJzXjHjw3jQzDCeQcbIIuw",
"ee30zvqlwf-c": "AOAugJd9AQAAyWpQ4p1MgPIjRX-9FZic2VdmlR0kJ6TaQRU7QNCJyIfbTlqR",
"ee30zvqlwf-f": "AwKagpd9AQAAOyeNxr2iG9LVC3nztxjqTGu9kBXyhiGzD8_v8ctAF9mDiMpSAQgGcPWuctP0wH8AAOfvAAAAAA=="
}
i've tried checking in with those exact headers pulled programmatically and manually (same keys, different values). but the manual one is the only one that works. so something about the values is different that's causing the check-in to fail.
right now just at a loss for what's different.
has anyone gotten the check in to work using headers pulled from @jasonwbarnett's code?
i'm wondering if all the reported successful tries in this thread are done from manually header pulls?
EDIT 1: actually, re-reading this thread more closely, i see https://github.com/pyro2927/SouthwestCheckin/issues/70#issuecomment-944648950 already came to this same conclusion. 🤦🏻♂️
EDIT 2: the programmatic headers work after hex editing chromedriver! will now see if i can integrate this into my gem https://github.com/byalextran/southwest-checkin. it'll be a frankenstein job though since my code is in ruby, the programmatic header dump is in python, and you'll have to manually hex edit chromedriver. 😅
EDIT 3: programmatic headers don't work if selenium is run in headless mode. not sure how this will affect integrating everything into a command line tool. 🤔
EDIT 4: headless mode works if you set a user agent that doesn't have the word "Headless" in it. (apparently when you set headless mode, the user agent then includes "HeadlessChrome."
alright, headed to bed but hopeful that a solution is on the horizon.
making some progress. i created a new repo for code that will output the proper headers needed for any check-in scripts.
https://github.com/byalextran/southwest-headers
will try to update my project later this weekend to support it and get a fully automated solution working again.
kinda what i'm thinking is have that script run in a cronjob every day (doesn't appear to need a valid confirmation number to generate working headers) and then update my project to grab the header file before checking in.
it would be helpful if we could collectively figure out how long a set of headers is valid before needing to get new ones.
Happy to report my auto check-in script is working again!
https://github.com/byalextran/southwest-checkin
Thanks to everyone in this thread for contributing to the solution.
@byalextran your headers work is awesome! I've implemented it into my AWS Lambda solution here: https://github.com/sw-tools/checkin-service
@byalextran great job figuring out how to get the headers! One optimization you can do is using an undetected-chromedriver. This takes away the need to manually install the chromedriver and hex edit it.
@jdholtz oh nice, thanks for that tip. i'll incorporate it on the next update!
@byalextran I made a PR for the move to undetected-chromedriver. I tested it and it seems to work great.
@byalextran do you have or could you wrap a docker container around your sweet solutions? I'm impressed by your header work!
@byalextran do you have or could you wrap a docker container around your sweet solutions? I'm impressed by your header work!
I do want to explore a docker solution eventually. Just not a priority right now since I have a working solution and all my free time lately has been dedicated to a new pickleball addiction. 😅😜
But see if this could work for you.
But see if this could work for you.
Brilliant! Thanks for pointing that out!
Happy to report my auto check-in script is working again!
https://github.com/byalextran/southwest-checkin
Thanks to everyone in this thread for contributing to the solution.
Set this up and pretty sure I had success this AM. Thank you for your work! I had to add the autoluv dir to my environment variables before the command would run, maybe it's just how I installed my ruby.
Side question: is there any way to setup a shell output for the result instead of email? I tried looking in the log dir you mentioned autoluv-0.3.1/logs/ but no such directory
has anyone tried this python version recently and had success? I've been running it today and am getting a BAD_REQUEST.
{ "code": 429999999, "message": "Error.", "messageKey": "ERROR", "httpStatusCode": "BAD_REQUEST", "requestId": "", "infoList": [] }
I'm generating headers using
https://github.com/byalextran/southwest-headers, but it appears that something changed again because when I manually go through the process using https://mobile.southwest.com/check-in I see that a ee30zvqlwf-a0
header now exists on the POST
when I print out all the headers that https://github.com/byalextran/southwest-headers processes, ee30zvqlwf-a0
is not one of them, so wondering if it could be a Selenium issue. As expected, just copying and pasting a previous value does not work as I believe all the ee30zvqlwf
header values are generated together.
Did you modify the chromedriver?
On Sat, Nov 12, 2022, 14:37 Kyle Zimmermann @.***> wrote:
has anyone tried this python version recently and had success? I've been running it today and am getting a BAD_REQUEST. { "code": 429999999, "message": "Error.", "messageKey": "ERROR", "httpStatusCode": "BAD_REQUEST", "requestId": "", "infoList": [] }
I'm generating headers using https://github.com/byalextran/southwest-headers, but it appears that something changed again because when I manually go through the process using https://mobile.southwest.com/check-in I see that a ee30zvqlwf-a0 header now exists on the POST [image: image] https://user-images.githubusercontent.com/5014469/201495368-d2747842-fd5c-4371-8b2b-45520f9f3297.png
when I print out all the headers that https://github.com/byalextran/southwest-headers processes, ee30zvqlwf-a0 is not one of them, so wondering if it could be a Selenium issue. As expected, just copying and pasting a previous value does not work as I believe all the ee30zvqlwf header values are generated together.
— Reply to this email directly, view it on GitHub https://github.com/pyro2927/SouthwestCheckin/issues/70#issuecomment-1312577819, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEWMPXX4VQCANKKOQQU3DV3WIAEYDANCNFSM5BXU6U5A . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Yes, I did the below chromedriver modification
these are the request headers I'm currently getting
If no one else is having problems anymore, then it must be something local to my machine.
@BigSammich southwest did something to detect my southwest-headers script. i finally got around to troubleshooting and just pushed a fix.
follow the instructions here:
https://github.com/byalextran/southwest-checkin/issues/13#issuecomment-1354171138
@3052 Can you share more details about apiguard3? I'm not able to find much information on the internet on it.
@FrankGasparovic I think its actually called ShapeSecurity
Shape got bought by F5 networks in 2020.
On Fri, Mar 22, 2024, 11:58 3052 @.***> wrote:
@FrankGasparovic https://github.com/FrankGasparovic I think its actually called ShapeSecurity
— Reply to this email directly, view it on GitHub https://github.com/pyro2927/SouthwestCheckin/issues/70#issuecomment-2015513942, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACA5DGU7MSTAYKCVABPCP4LYZRPKRAVCNFSM5BXU6U5KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBRGU2TCMZZGQZA . You are receiving this because you commented.Message ID: @.***>
How is this response any more helpful?On Mar 22, 2024, at 14:21, 3052 @.***> wrote: @dwightmulcahy who gives a shit? how does that help solve the problem?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
This may not be directly applicable since I only ran into the error condition after I changed the code in a fork (lowered retry sleep), but it still may make sense to add exception handling for the situation where Southwest rate limits requests and returns a 429. Thinking that adding an additional sleep (i.e. 5 seconds) may make sense.
Response
Body
For reference: https://datatracker.ietf.org/doc/html/rfc6585#section-4