Examining the Glastonbury Ticket Sales Website - Comments
By Chris Gilbert
Old Article Comments
I exported these from my old wordpress blog, so they are a bit out of date, but I thought I’d keep them around for posterity.
Lewis Cook - Sep 1, 2015 Great blog post. . Any chance of an updated blog post for Sunday’s ticket showdown?
chrisgilbert42 - Oct 0, 2016 Hi Lewis, hope you managed to get tickets last year/this year. I’ve noticed a few things that have changed this year, I’ll see if I can come up with an updated post soon. Won’t be quite as detailed, but does appear they are now using IP rate limiting (hence the advice to only use one device at once).
James Simpson - Oct 0, 2016 It seems that its all changed this year… Apparently they have new servers. I tried ping, and it seems they have blocked this function now. After sitting back and looking over my actions from this morning, the only way I can see anyone having a better chance is to use something like Google Chrome with a few windows open in incognito mode, with a plugin like Refresh Monkey running every 5 seconds on all windows pointing to the following url “http://glastonbury.seetickets.com/event/glastonbury-2017-deposits/worthy-farm/1100000/" and have the mode set to “Stop refresh when URL changes” - this would mean it would stop the page when it loads into the application / payment window, as once you are in, you have a session saved on the server for you to fill in your details. After reading up on Twitter and Facebook on what people did to get their tickets, it seems waiting the 20 seconds is pointless, as people were hitting the refresh button every 5 seconds regardless if they had a page display on their screen. I seemed to have failed by waiting for a timeout or anything to happen when trying to get tickets this morning. I’ve even took up writing a little Applescript that will check the URL every 3 seconds to see if it gets a connection, if not, it will try again till it can receive a connection and open up the URL once it does… might give this a try this next time around to see if I can get a ticket, along with using the above method… fingers crossed.
Matt - Apr 0, 2016 Thanks very much for the information about the ‘Check4Change’ plugin. With six computers running Firefox and with the refresh set to 2 seconds, I was able to order Glastonbury tickets for my sister. I also installed another plugin called ‘ImageBlock’ to stop images loading although I’m not sure if this helped or not.
chrisgilbert42 - Apr 0, 2016 Glad to hear it Matt! I didn’t have the chance to update the post for this year as I was out of town. But the technology and queuing system was slightly enhanced last year. It makes it more difficult to purchase more than 6 tickets, though I am glad to check4change plugin is still useful!
James Simpson - Oct 0, 2016
Can you tell I’ve been bored today, and done some research into a bit more of this now, and have more questions then answers haha… Anyway, so as with most popular websites, they use load balancing, so See Tickets have a number of servers.
On your first visit, you are directed to a server behind the load balancer and are set an X-Mapping-XXXXXXXX cookie with a string of encrypted code (this will be your session ID on the server behind the load balancer), and the XXXX’s are probably the load balances identity code - you will notice these below. Anyway, the question now is, would it be better to get a new ID each time you refresh your browser, in theory pointing to another server behind the load balancer, would that give you more chance of getting a website to display? So for example, If I cURL the URL from within Terminal, I get a different server every time:
Set-Cookie: X-Mapping-kgibjjhc=78CEF00D91D78687A41C9C2369AE1755; path=/Set-Cookie: X-Mapping-kgibjjhc=DBADD375D5D3EAE853E0A2FECAC0F77E; path=/Set-Cookie: X-Mapping-kgibjjhc=52F6FBC54C65511FB7F38FB2D142FED1; path=/Set-Cookie: X-Mapping-kgibjjhc=D99C5766EC99492734EE6A5E86FDE251; path=/Set-Cookie: X-Mapping-kgibjjhc=F52A55C3DF592650DA48FE55FCF3E5AE; path=/Set-Cookie: X-Mapping-kgibjjhc=F52A55C3DF592650DA48FE55FCF3E5AE; path=/Set-Cookie: X-Mapping-kgibjjhc=2A017EE24B74BB0AFB714CC687CA23AB; path=/Set-Cookie: X-Mapping-kgibjjhc=AA05972B9548CFFA739C04F521677B59; path=/Set-Cookie: X-Mapping-kgibjjhc=1EF073EF63C31B3E935A08684E5406F2; path=/Set-Cookie: X-Mapping-kgibjjhc=C08E1BD6F1BB00CF0844CF2DA5EEAF68; path=/Set-Cookie: X-Mapping-kgibjjhc=AA05972B9548CFFA739C04F521677B59; path=/Set-Cookie: X-Mapping-kgibjjhc=C08E1BD6F1BB00CF0844CF2DA5EEAF68; path=/That is just a few, but you will notice some duplicates (where i was sent to the same server behind the load balancer, for instance post 5&6, 10&12 and 8&11….) So in my little script, I get it to open a new incognito window once its received a connection, and it will open up to 9 windows every 3 seconds… I noticed that once a cookie is set (even on incognito), i will be redirected to that very same server from my initial visit… Is this a good thing? Or a bad thing? Now I can code in and grab that cookie above and send that to Chrome once each window opens…. That would mean I could have a window session for each server behind the load balancer…. would that give me more chance, or would there be more chance on concentrating on a single server?
chrisgilbert42 - Oct 6, 2016 Great work James. I think you’d have more chance distributing your requests across all servers, since it’s likely one or more will go down or be too busy. That could also be why a lot of requests were failing to connect at all (the server the cookie was directing to was unable to handle the traffic). However, if they are using IP rate limiting, that would mean only a certain number of your requests would be allowed to connect to the load balancer at all (probably Stingray traffic manager I think). A way around this would be multiple devices using VPN tunnels via Tor or providers like ExpressVPN or VanishIP. That would give each device a different originating address so would work around any IP rate limits too. You could have each device hitting a different server through your script. Once you do get in the queue and are redirected to a new URL, you want to keep using the same cookie - that’s what decides whether you are allowed to progress to registration or not, and gives you a limited time to do it before you are thrown back in the main queue again.
chrisgilbert42 - Jul 1, 2019 I don’t remember what analysis I did, but there was a post from Emily Eavis implying that mutliple tabs and browser windows would cause problems last time around. We also found that multiple computers on the same IP was getting much less good results than using phones on 4G, and connecting to a VPN. I didn’t make as big of an effort though last October, so I didn’t do much analysis on what was happening. I failed to purchase the tickets twice after putting card details in, which hasn’t happened to me on previous years.
Ziggy - Jul 5, 2019 Hi Chris, doing some prep for 2020 already haha - how did you find out they are rate limiting by the way?