Disney World wait times

[zpocbob]

Disney World wait times are showing closed with 0 wait time.

[DougSisk]

Seems like there's an issue regarding Couchbase.

[evanlanglais]

Any update on this? What is meant by its an issue with "Couchbase", how are Disney times utilizing that db and what needs to happen to get it working again?

[evanlanglais]

I utilize this library to track Disney park wait times so I am very interested in getting this fixed.

In stepping through the runtime of the couchbaseChannel.js file in the Disney folder, I found that GetInitialState() never resolves. I added a response_timeout to the request options of the POST request at 431 and found that even setting long timeouts such as several minutes wasn't enough time to finish the post request.

I am confused as to why this request never resolves, as manually sending the request via postman seems to get a valid response without delay.

[cubehouse]

I'll look into this more closely when I can.

Try adding these two headers to "get HTTPHeaders()" so you get

 get HTTPHeaders() {
    return {
      Authorization: this[sAuthHeader] || null,
      'User-Agent': CouchbaseLiteUserAgent,
      'Accept-Encoding': 'gzip, deflate, br',
      Connection: 'keep-alive',
    };
  }

[evanlanglais]

Funny enough I was about to write a response, I seemed to have fixed the issue (at least locally) by changing 'User-Agent' to user_agent, which is the expected value in the HTTPHeader object passed to the needle call (as per its documentation here https://github.com/tomas/needle/tree/master#http-header-options). By reverting back to 'User-Agent' it continues to fail again so I believe this is the culprit.

I had tried adding the Accept-Encoding and Connection keep-alive headers and neither of them seemed to make a difference, so not sure if there is value in adding them.

I will open a PR.

[cubehouse]

The "user_agent" is a shortcut field if you don't pass in a "User-Agent" field directly into the headers object. Because this is being passed in as the actual "headers" field, then "user_agent" won't do anything, but will add an additional header to the request.

If you take this change and enable needle debugging "env.DEBUG=needle" you can see the user-agent is no longer being passed in (it will now pass in a generic "needle" user-agent, which we do not want). It may work, which suggests that the User-Agent we're using is being blocked or rate-limited.

[evanlanglais]

Ah thats a much better theory than for some reason the 'User-Agent' was getting cobbled in the request, but using the same User-Agent value in postman responds without issue.

Weirdly enough although I tested adding the Connection and Accept-Encoding headers and they had not fixed the issue, I tried them independently and not together. When adding both of them, and restoring the 'User-Agent' string, connection seems to be accepted.

[cubehouse]

Oop, my commit auto-closed this.

I'll push an update to npm in a sec, let me know if that all works.

[evanlanglais]

Yep seems to have fixed it in my application. Thanks for taking a look at this.

[DougSisk]

Still broken for me on Linode. Cloned the server to swap out IP addresses and no luck.

[mfwit]

All fixed on my end as well. Thanks.

[evanlanglais]

Actually reporting back that although on my local machine everything was fixed, the server that runs data gathering is still having issues. This may be a case of attempting to block out third parties from connecting, which would explain the silent packet drops as opposed to an error response.

[evanlanglais]

Still broken for me on Linode. Cloned the server to swap out IP addresses and no luck.

I think this may indicate that there is a subnet blacklist for cloud providers

[DougSisk]

I’ll test trying a proxy with my VPN when I have some free time.

On Sat, Aug 15, 2020 at 1:49 PM Evan Langlais notifications@github.com wrote:

Still broken for me on Linode. Cloned the server to swap out IP addresses and no luck.

I think this may indicate that there is a subnet blacklist for cloud providers

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/cubehouse/themeparks/issues/314#issuecomment-674440540, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAARG4GPA5LISNK2UEBOQULSA3RFBANCNFSM4P7V4CUA .

[golex]

Hi all - just to chime in with my experience. I spent a few hours last night working on this and ended up with a similar fix (turning compression on and keep-alive), however as others have mentioned that only fixed the hanging connection on my local machine and not on my server (also Linode). Running my worker locally for now but obviously not a real fix. Will experiment with IPs and user-agents tonight although maybe naively I doubt this is active blocking and maybe just a couchbase / infrastructure upgrade. I also noticed my Disney Experience app failing to retrieve opening times occasionally yesterday.

I also noticed when experimenting with the call in Postman that once you do get a successful call, if you include the cookies returned in future calls then they work fine without compression / keep-alive.

[DougSisk]

Curious to all on Linode - what datacenter are you using? I’m at Dallas. Tried Atlanta but the sever failed to properly clone.

On Sat, Aug 15, 2020 at 2:46 PM Ryan Austin notifications@github.com wrote:

Hi all - just to chime in with my experience. I spent a few hours last night working on this and ended up with a similar fix (turning compression on and keep-alive), however as others have mentioned that only fixed the hanging connection on my local machine and not on my server (also Linode). Running my worker locally for now but obviously not a real fix. Will experiment with IPs and used-agents tonight although maybe naively I doubt this is active blocking and maybe just a couchbase / infrastructure upgrade. I also noticed my Disney Experience app failing to retrieve opening times occasionally yesterday.

I also noticed when experimenting with the call in Postman that once you do get a successful call, if you include the cookies returned in future calls then they work fine without compression / keep-alive.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/cubehouse/themeparks/issues/314#issuecomment-674445581, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAARG4BINZ2RTMMQ67VVPATSA3X2XANCNFSM4P7V4CUA .

[golex]

Also Dallas here.

[DougSisk]

No dice with the proxy. @cubehouse does the Couchbase channel not support proxy?

[AndrewRook]

To add another datapoint, my API calls on an AWS Lambda started timing out a couple days ago (local still works fine). It's not apples to apples — I'm not using this library directly but rather making the API calls through Python — but this library is what I used to figure out what those calls actually should be, so I would be surprised if it's not related.

[golex]

To update a few items:

• If you include any cookie whatsoever in the header you can drop the keep-alive
• It does look like Linode (Dallas at least) is being explicitly blocked - if I VPN into my server from my working local machine and try to get data it hangs just as before any fixes, works fine if running from my Comcast IP.

[evanlanglais]

Although it looks like this is not explicitly an issue with the library, it may be advantageous to re-open this issue for visibility

[zacharyedwardbull]

Unfortunately the fix isn't working for me on DigitalOcean either, tested on both the LON1 and NYC1 regions. As with others, I have no problems running it locally through my home IP.

[golex]

Toronto Linode was also blocked, Azure VM (US-Central) works fine, as does a VPS from a small local provider.

Looking at the cookies returned on a successful request, it appears they are using Akamai's Bot Detection service. I am not sure if this is a new addition, but if so could be why well known VPS providers are now blocked.

[cubehouse]

If you are having issues, you can try using the "6prev" branch, which replaces the wdw parks with a mode that fetches from a hosted solution I've been setting up for the eventual 6.x release.

npm i cubehouse/themeparks#6prev

This is a preview setup, so may stop working at any time (will keep people up-to-date in the Discord).

[dunkmann00]

Like another commenter, I'm not using this library directly, but I did use it to help me get my own Python version up and running and I too was having a problem running on Heroku.

After some trial and error I discovered that if you just leave the User-Agent header alone, and let it be set by the http client that is being used (in my case using Python it was requests, in the case of this library it is needle), you will get a response. I tested putting in several different User-Agents from different libraries/languages and some work, some don’t. It seems like there is a whitelist and the more common libraries are on it.

So while it might seem unusual, for now anyway, I think the solution is don’t pretend to be the Couchbase User-Agent.

Also, as others have mentioned, you don’t need to do this if running locally. Locally it doesn’t seem to care, you can send no User-Agent locally and it works. So it must be the combination of I.P. Address and User-Agent that is getting filtered.

Hope this helps!

[golex]

Verified - using 'Needle/2.5.0 (Node.js v12.18.1; linux x64)' as a user-agent allows the requests to complete on my Linode. Tried a few other common user-agents with no luck. After more testing any User-agent with the exact text 'Node.js' in it will work.

[rorpage]

We are seeing similar behavior in Heroku.

Is the user agent configurable as an environment variable?

[evanlanglais]

I can confirm that letting needle set the User-Agent or using the User-Agent provided by @golex does not seem to fix the issue on AWS.

If this is the case of Akamai Bot detection then we are up against a constantly moving target, not sure if any of the provided fixes will continue to work.

That being said utilizing the new 6prev branch does seem to give good data even on AWS

[golex]

Confirmed as of this morning my Linode can no longer connect with the User-Agent changes so seems we are in some sort of arms race unfortunately.

[AndrewRook]

FWIW using Python's requests with no user-agent has been working for me on AWS through this morning, not sure what the difference is between that and needle but that's probably something you could look up. I agree that it's probably only a matter of time before even this stops working though, so it may not be worth your time to explore 😞.

[cubehouse]

If you are having issues, I strongly suggest moving to the 6prev branch like so:

npm i cubehouse/themeparks#6prev

[rorpage]

@cubehouse how does one specify that in a package.json?

[cubehouse]

The above command has "i", which is shorthand for automatically saving that into your package.json file, so you don't have to write it manually.

If you are on a very old version of npm that won't do that for you, the npm docs explain how to specify a git repo and branch: https://docs.npmjs.com/files/package.json#github-urls

"themeparks": "cubehouse/themeparks#6prev"

[rorpage]

Upgrading to 6prev fixed my issues on Heroku! I hope others can try and post their results.

[ImAnAutie]

If you are having issues, I strongly suggest moving to the 6prev branch like so:

npm i cubehouse/themeparks#6prev

If that's using the hosted solution your building do you have some fancy thing in place to work around the blocks?

[cubehouse]

Nothing fancy at all. The NodeJS instance is kept alive 24/7, so the cache is kept healthy making barely any network requests.

I suspect people have been manually deleting caches, or using serverless-type instantiations of the library, which is making way too many requests and getting certain ranges blocked. This is one of the key reasons I want to move away from the current setup.

[DougSisk]

Seems like Disney has already caught on to the new version 😞

[cubehouse]

Sorry, I did a stupid. Will get it back up in a second.

[cubehouse]

Ah no, I did a stupid at the same time as something else going on. Investigating!

[cubehouse]

All resolved.

[gberg927]

@cubehouse

Are the California Disneyland parks planning on being switched over as well? I'm getting errors for those as well using 6prev.

Thanks in advance

[cubehouse]

I checked in an update to 6prev branch yesterday that should switch all the Disney parks to use the new servers.

I'll be rolling this out to the main branch and npm this week.

[golex]

Hi cube,

I'd prefer to keep retrieving my data from Disney directly - will that be an option after this is rolled out to the main branch?

[cubehouse]

I'm afraid I'm not going to be supporting that in future with this library. The codebase driving these new updates will still be on GitHub if you want to do it yourself (see https://github.com/ThemeParks/parksapi), but I won't be actively supporting it for other use cases.

[gberg927]

I checked in an update to 6prev branch yesterday that should switch all the Disney parks to use the new servers.

I'll be rolling this out to the main branch and npm this week.

I see in the 6prev branch that disneylandresortcaliforniaadventure and disneylandresortmagickingdom are still extending disneyworldapibase but I noticed all the WDW and global parks extend hostedPark.

[golex]

I'm afraid I'm not going to be supporting that in future with this library. The codebase driving these new updates will still be on GitHub if you want to do it yourself (see https://github.com/ThemeParks/parksapi), but I won't be actively supporting it for other use cases.

Understood - I'll stick with the current version for now and look to update to a parksapi derived version in the future (much prefer the PouchDB replication you implemented there).

One thing this issue taught me is to build some redundancy into my system - I have multiple workers on multiple providers now, but transitioning them all to your hosted API would introduce another single point of failure. I do appreciate all your hard work and will definitely be incorporating your API as another fallback. Thanks!

[cubehouse]

This is now generally rolled out for Disney parks in 5.1.42