ticket tips and tricks Glastonbury 2024 resales

[BenG92]

Thanks for the VPN advice both, will avoid that then. 

[parsonjack]

14 minutes ago, leath02 said:

https://www.reddit.com/r/glastonbury_festival/comments/ddgggb/a_web_developers_advice_on_getting_tickets/

 

I think this covers most of what we currently know. The first bullet is bull though...there's no advantage to hitting the specific page URL directly other than it avoids a DNS lookup and a redirect....maybe saving a couple of milliseconds. 

[Havors]

2 minutes ago, BenG92 said:

Thanks for the VPN advice both, will avoid that then. 

Yeah public VPN's are bad. 

I had success using my work VPN though as that just puts me through to use my work ISP which funny enough is the same one Seetickets use 😄 

We recently changed all our systems for work though and dont use VPN anymore so im just figuring out how seetickets handles netskope. I think im going to fail miserably on ticket day now haha 

[Neil]

10 minutes ago, gfa said:

 

Ticket websites will likely not favour VPNs because these are what people use to exceed ticket limits with etc. Likely theres a universal block list of all VPNs i'd have thought.

There are ways to get a ridiculous amount of tabs open and all but guarantee one getting in or probably bypasses to just get straight through

If you've got lots of tabs open you'll probably not see if one gets thru. 

[Neil]

26 minutes ago, leath02 said:

https://www.reddit.com/r/glastonbury_festival/comments/ddgggb/a_web_developers_advice_on_getting_tickets/

 

He doesn't seem to know the difference between sessions and cookies. 

[Havors]

8 minutes ago, Neil said:

He doesn't seem to know the difference between sessions and cookies. 

I was thinking that haha 

[p.pete]

15 minutes ago, parsonjack said:

Yup this is where the load balancing could be part of the story....the request from Chrome is directed in such a manner that it's seen as breaching the limit, but the Edge request is directed elsewhere and seen as within the limit. 

Cool - I tried testing it myself over home wifi yesterday and after blocking on chrome it also blocked on Edge & incognito.  The above post mentioned that they were doing it from different computers in the same workplace, so probably a lot greater chance of getting sent different routes through the load balancing than for a single computer on a home wifi.  I did add my phone into the mix, also on the home wifi, and while the computer browsers were blocked my phone got through (MAC addresses mentioned above, so maybe it's checking that or maybe it's allowing the phone to take a different load balancing route for other reasons).

As part of my testing I realised I can do 60 refreshes in about 20 seconds - then leave it alone for 40(ish) seconds and it's back up and running again.  With my phone on 4G (rather than wifi, to avoid the load balancing concerns) I reckon I could make use of the 40 second downtime on the computer to focus on refreshing my phone.  For me that'll probably be more efficient, I always get a bit scatter brained trying to have one chrome tab, one incognito tab, one Edge tab, and one phone refreshing all at once.  I think I can manage the one-browser one-tab method for 20/30 seconds and then switch to my rubbish phone in between the gaps.

2 thoughts with that though 1) definitely don't want anything autorefreshing (which I tried last time), when it gets to the backing off for 40 seconds auto refresh would keep me blocked a lot longer and 2) the reality when tickets are actually on sale is I've no idea how many of my 60 requests actually get through to their server, everything always buggers up or slows down during the actual sale and I'm just looking at white screens and wondering whether anything is actually happening 😄 

[Neil]

Just now, Havors said:

I was thinking that haha 

sessions are often implemented with a cookie aspect, but they're distinct and separate things. if you were trying to build a secure system you're keep them separate.

[parsonjack]

I like to think that See tech's read this stuff on their lunch break and chuckle over their Pot Noodles like Moss and Roy.

Given that there has been no significant change in set up over recent years it suggests to me that we may be close to knowing how it works, but still far enough away to properly game the system to our advantage.

[Havors]

35 minutes ago, incident said:

It's more complicated than that. There's at least some other factors at play beyond the session - some form of browser/device fingerprinting I believe.

I did some experiments of my own a few years ago, got results similar to those reported above (ie multiple devices "locked out" at once), but couldn't figure out exactly what triggers what so just structured my setup in such a way that avoids the question entirely.

Its session based, uses your token I think. 

Easy to test. Open a chrome window and firefox window... bash away on one. Only that one will be locked. 

[p.pete]

1 minute ago, Havors said:

Its session based, uses your token I think. 

Easy to test. Open a chrome window and firefox window... bash away on one. Only that one will be locked. 

But with sessions probably being shared depending on your setup?

[Neil]

1 minute ago, Havors said:

Its session based, uses your token I think. 

Easy to test. Open a chrome window and firefox window... bash away on one. Only that one will be locked. 

nice easy instruction.  that will prove or not that its session bsed.

[Neil]

2 minutes ago, p.pete said:

But with sessions probably being shared depending on your setup?

sessions can't be shared anymore than cookies can, the point is to uniquely identify a session.

Edited October 20, 2022 by Neil

[leath02]

2 minutes ago, Neil said:

sessions can't be shared anymore than cookies can, the point is to uniquely identify a session.

You can export and then in turn share cookies by importing them 

Edited October 20, 2022 by leath02

[Neil]

Just now, leath02 said:

You can export and then in turn share cookies by importing them 

you cant share them in active use, you can't share a session.

[Havors]

4 minutes ago, Neil said:

sessions can't be shared anymore than cookies can, the point is to uniquely identify a session.

Yep. You get a session ID / Token this is unique. 

[p.pete]

3 minutes ago, Neil said:

nice easy instruction.  that will prove or not that its session bsed.

I've done it just now (and yest) and it blocks on both browsers after bash away on one browser.  So that proves that it's not session based for me (but maybe is session based for @Havors?

 

5 minutes ago, Neil said:

sessions can't be shared anymore than cookies can, the point is to uniquely identify a session.

😄 thank you - my grasp of this definitely tightens and then loosens again.  The ceiling of my interest levels has been well passed, other than it being glastonbury related!

[Fish Bulb]

8 minutes ago, Havors said:

Its session based, uses your token I think. 

Easy to test. Open a chrome window and firefox window... bash away on one. Only that one will be locked. 

Ok just tried this. Had Chrome, Edge and Firefox open at once. Smashed refresh on Firefox until it "locked" - the others didn't change at all. 

Also interestingly, I didn't turn off auto-refresh on Firefox and it looks like I wasn't actually "locked" at all. That is, it quickly jumped back to the normal page again, then back to the holding page, then back again. Are we sure that we actually have to wait 20 seconds if we get to that holding page?

[parsonjack]

2 minutes ago, Fish Bulb said:

Ok just tried this. Had Chrome, Edge and Firefox open at once. Smashed refresh on Firefox until it "locked" - the others didn't change at all. 

Also interestingly, I didn't turn off auto-refresh on Firefox and it looks like I wasn't actually "locked" at all. That is, it quickly jumped back to the normal page again, then back to the holding page, then back again. Are we sure that we actually have to wait 20 seconds if we get to that holding page?

What was your auto-refresh rate on Firefox?  It would jump back to the normal page once your refresh rate fell below 60/minute, but if the next auto-refresh is quick enough to then breach the limit again it would 'lock' again....and so on so forth.

[Fish Bulb]

1 minute ago, parsonjack said:

What was your auto-refresh rate on Firefox?  It would jump back to the normal page once your refresh rate fell below 60/minute, but if the next auto-refresh is quick enough to then breach the limit again it would 'lock' again....and so on so forth.

Gotcha! It was every 1 second. It seems like the auto-refresh limit is just over this maybe? I'm thinking if I have 4 tabs open, but set auto-refresh on all to 5 seconds, I should be safe but still increase my chances?

Edit: 4 different browsers of course.

Edited October 20, 2022 by Fish Bulb

[Havors]

8 minutes ago, p.pete said:

I've done it just now (and yest) and it blocks on both browsers after bash away on one browser.  So that proves that it's not session based for me (but maybe is session based for @Havors?

 

😄 thank you - my grasp of this definitely tightens and then loosens again.  The ceiling of my interest levels has been well passed, other than it being glastonbury related!

I did it and didnt get blocked. Will be because of the rate I guess

Yes it is, if you keep the refresh rate above 60 per min then it will block your IP. So its the IP rate limiting not your session. 

Edited October 20, 2022 by Havors

[Crazyfool01]

Skips page … is this some kind of foreign language people are talking ? 😂

[p.pete]

Just now, Havors said:

I did it and didnt get blocked. 

Same question as @parsonjack above - what is your refresh rate?  I'm refreshing about 60 times within 30 seconds to get blocked, so then there's at least a 30 second period before I get unblocked that I can test the other browsers with.  If you're going at only 60 per second then you should be unblocked almost immediately as soon as you pause to switch between browsers.  Or as per above, I've proved it for me but not for you!

[Havors]

1 minute ago, p.pete said:

Same question as @parsonjack above - what is your refresh rate?  I'm refreshing about 60 times within 30 seconds to get blocked, so then there's at least a 30 second period before I get unblocked that I can test the other browsers with.  If you're going at only 60 per second then you should be unblocked almost immediately as soon as you pause to switch between browsers.  Or as per above, I've proved it for me but not for you!

Yeah I edited the post 👍

 

[p.pete]

2 minutes ago, Havors said:

Yeah I edited the post 👍

 

Sessions or IPs, I don't mind which is getting rate limited.  How come I can block the site on one browser and then move to a different browser and it's also blocked until enough time has passed such that both browsers are unblocked, whereas your (home?) computer seems to block one browser but allow the other to continue as normal?

That's why I ask how much above 60 hits per 60 seconds, just trying to understand it.  Is my crappy Virgin media router assigning the same IP&/Session to all of my browsers whereas something different is happening for you?