Resolved is a resy bot that assists in obtaining difficult or high-end reservations. Although it only works with resy, there is an opentable api in the tree.
License: BSD 3-Clause "New" or "Revised" License
When performing a rats or rais command, if the restaurant does not offer reservations on that day(i.e. not open or not available yet), the app crashes
A step by step of this would be pathological and more complex than a simple explanation:
Take any restaurant, and find a day on resy for which they do not have enabled(i.e. a greyed out day). Run a rats or rais command which requests this disabled day from that restaurant.
Not needed, this will occur on any system using the app
I believe the issue is that the reserve api function for resy does not check if it received a list of times and immediately begins trying to reserve them. This can be solved with a simple if statement in api/resy/api.go in the reserve function.
We would like to implement a method for reducing the overhead of reservation-making http transcations by authenticating before the request date. This should reduce the RTT of the reservation operation by 1/4. Since this issue deals with manipulating dates, we find that a replacement of the api.Time abstraction with the go Time pkg.
The first steps have already been implemented. These involved adding a method to the api interface that allows a consumer of the interface to extract a minimum auth time variable, which details the minimum amount of time a login token is viable for after a call to login. Then from here we analyzed the resy cookies and found that, accounting for a maximum time-zone diff of 24 hours, the resy auth token is viable for a minimum of 6 days. Now, we seek to utilize this abstraction + the specific value for resy to implement early authentication via the following pseudocode restructuring of the reserveAtTime operation function:
REQUESTDATE - MINAUTHDATE = AUTHDATE
if (AUTHDATE < NOW) {
authenticate
sleep till REQUESTDATE
} else {
sleep till AUTHDATE
authenticate
sleep till REQUESTDATE
}
send request
Implementing a function that substracts api.times in a logical manner v.s. replacing api.time. Figured this function would be very complex
See planned solution
In consideration with how long the last PR took to update documentation, I am now enacting a rule for future PRs that documentation is always expected and if not present a good reason must be submitted along with the PR.
General rules for documentation are as follows:
pkg should have a doc.go with at least one section titled General Purpose that outlines what the pkg is trying to accomplish. If the pkg has sub-pkgs, then these should also do this, and their doc.go should reference the parent's.With the increasing prevalence of bot solutions, resy has started using captcha on higher-demand reservations. If this pattern continues, the critical factor in making reservations will most certainly be the ability to complete a captcha. This is a fantastic blessing in disguise. For one, there are well-documented machine learning algorithms which can classify captchas at an extremely high rate. Second, since most of the bots out there are not actively maintained, they'll be completely useless compared to a bot that handles captcha. Third, and even better, an ML captcha system is probably far faster than the vast majority of people trying to solve a captcha.
Despite these opportunities, implementing captcha accurately is tough. We first have to decipher the networking calls, which is pretty hard since we have to create an event in the browser that we can monitor and study, and these captchas are appearing very infrequently. I'd assume they appear on harder reservations, which makes it harder for us to reproduce and test our implementation. Furthermore, once we have the networking calls down, there are a number of captcha tasks. Some involve typing letters and number, some involve selecting photos, others involve checking a box and then moving the mouse in such a way that google thinks a human is behind the IO. We will need algorithms for these separate functions.
Add the networking checks and calls to resy's reserve function, create a separate top level package for ML stuff.
None really, maybe somehow displaying the captcha to the user in the terminal, but that seems pathological.
There are a few papers online about breaking captchas. For analyzing network calls, we'll start with the common firefox/postman method of breaking and then modify if that doesn't work
This is a general note where I'll go over the overhead view of the architecture the codebase uses for new developers.
The codebase consists of three logical "layers".
The basest layer is the API layer. This layer is found in the api/ directory. At the top level is a package called the api package which provides the api interface. This interface specifies the functions each go api to an external reservation service (resy, opentable, etc.) should have in order to plug in to the rest of the codebase. This layer has sublayers representing the implementations of each external api. These can be found in the api/resy/ and api/opentable/ directories on the develop branch. These packages are where the network requests to resy and opentable are made.
One level higher, we have the App or Backend layer, located in the app/ directory. This layer provides a struct called the AppCtx struct, which takes in an(soon to be multiple) api type and uses it to provide the core functionality of the app. This includes scheduling reservation requests to be sent to servers at specific times and monitoring services on an interval to see if reservations have freed up. This layer is where all the concurrency happens.
The top level layer is dubbed the Runnable or Frontend layer located in the runnable/ directory. It acts as a namespace and common interface to front-end wrappers to the App layer. This is where the CLI application lives as a subpackage, and where the HTTP server will eventually live as subpackage.
There are also a few packages that don't fit anywhere into the architecture but just provide some domain-specific functionality. For example, the CLI application uses a cli tokenizer and parser implemented in the cli/ directory / cli top level package.
If a restaurant is only available for reservation on opentable, the app does not work
Create an Open Table implementation of the API interface
I've thought of creating a new object / application for Open Table specifically since it uses 2-step login, but I believe generalizing the bot's API pkg to represent 2-step login is a good idea.
I've already begun dissecting the internals of Open Table's API using postman, still unsure of how to manage logins, but I believe I might be able to introduce semantics for token refreshing so that multiple logins may not be required. This can improve the response times on the resy API as well
There's been a lot of posting and emailing about more or less the same bug/issue. Initially I thought this bug was related to the most recent changes adding table type selection to the bot, but even reverting to a version from a month ago(which was working perfectly fine), the error persists. This is alarming, since it means that something on Resy's side changed and that's causing the bug. I've done a preliminary analysis using some println debugging and reviewing the API in firefox and I've deduced two possibilities. 1) The API for the config step has changed, I'll perform some analysis on this the next free moment I have. 2) Resy has increased their use of Captcha, and this is blocking the bot. I personally think 2) is more likely than 1). Regardless, I can't look at 1) till I get a break around three weeks from now, so the bot will be non-functional until that time unless a user is curious enough to look at the code.
IF YOU PLAN TO SOLVE THE PROBLEM:
I've taken a quick look at this bug. The network error occurs on line 366 in api/resy/api.go . The status code returned is 500. For anyone whose looked in the source files, this occurs at the config step of the reserve api operation. I checked to make sure the api key in the codebase is still valid and tried adding a user agent header. These didn't fix the issue.
If logging in with an account that does not have payment set up, bot crashes.
Suppose ###EMAIL### and ###PASSWORD### are the email and password of an account with no payment id.
Not needed, this will definitely occur on any platform
This can be fixed with a simple if statement in api/resy/api.go I'm busy but someone else might be interested in solving this one ...
Right now there is no way to specify table type. If there are multiple table types for the same time on the same day, how will the system know which one to book? It would be great to be able to specify types like 'Indoors', 'Dining Room', 'Outdoors', 'Patio' etc. to make sure to get the right table.
N/A
N/A
N/A
The codebase needs improved documentation, this affects developers
I'll just write more documentation on this branch
None this is pretty necessary
For each function exported from a package, I'll write a comment describing required inputs and outputs. For each package, I'll include a list of API functions in a doc.go file along with a general purpose statement
After bot is firing I am getting an unknown network error.
I am using this version 60e88dd
I am just running a rats command and after the time hits for the request date and I run the list command I am getting an unknown network error. I have tested with a few different venue IDs.
rats -v XXXX-resD 2024:03:13 -resT 20:00 -ps 2 -reqD 2024:03:04:13:10
Windows - Git Bash
No response
for some reason the bot doesn't seem to be working. I put 3 requests in, two of which have passed and should have fired. yet when I request a list, it says all three are still in progress.
I used semma and via carota as the two restaurants, filled in reqD of 2.15 and 2.17 at midnight. now 3pm on 2.17 and neither have fired.
macos ventura
No response
When attempting to get a reservation (e.g. rats -v 2038 -resD 2024:02:18 -resT 20:00 -ps 2 -reqD 2024:02:07:22:2), the attempt fails and the result is "unknown network error"
rats commandreqD time to passN/A
No response
Now that there are two APIs, the AppCtx object should be improved to allow for multiple API objects and multiplex properly between them. This will affect developers and end-users, as well as any current applications.
My solution will introduce the ability to register multiple APIs to the AppCtx object, and restructure the semantics of API calls to force them to specify which API to perform scheduling ops on.
I've considered moving the multiplexing to the runnable layer, so like each runnable makes a separate app context for each api, but then that defeats the point of the common api interface almost, plus I wouldn't want to redo multiplexing logic across runnables
I'll update this with more specifics in a few days
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.