Ticket tips and Tricks for 2025 festival

[Alvoram]

15 hours ago, DeanoL said:

Theoretically it seems slightly worse for large groups. As previously if someone got in and got tickets for one group, they could try and get in again. That's not going to be possible now as they'll be at the back of the queue. 

 

But yeah, if people with bot farms were getting lots of tickets then that might be reduced (but it's always an arms battle with this sort of thing) which increases everyone elses chances.

Yes I guess, and that's certainly one way of looking at it. But lots of tickets were also taken out of rotation by people who were able to game that too, with the back button glitch, allowing people to buy there entire spreadsheet's groups in a couple of minutes...

Again, bad news if you were someone doing this / able to do this, good news for everybody else. 

 

15 hours ago, gsp8181 said:

Here's how it's working

 

You go onto glastonbury.seetickets.com. You'll hit an Akamai CDN which is protected with Akamai Bot Manager

 

It will calculate an initial score for you based on your hostname, IP address, useragent, ISP, and how many people are going through that IP. So if you're going through something dodgy like a cloud datacentre or a commercial VPN you'll be a lot higher. If you're going through a mobile network AND are a mobile phone you'll probably be given more leeway.

 

If your score is too high you'll be instantly blocked, if you're in the mid zone you'll be 'flagged', and if it's low you'll be let on instantly.

 

If you're in the midpoint you can usually tell because the first time you log into the website you'll see a short delay before you get on while it 'fingerprints' your browser. Whereby it uses Javascript to gather all the information it can and can identify you with surprising accuracy, from stuff like, do you have any custom fonts, what plugins do you have in your browser, to the weirder stuff like drawing animations and analysing them to see if your graphics card has any minute differences. So they can track you if you've got firefox and chrome on the same machine.

 

Akamai will then set a load of cookies to link you to a session.

 

They'll then continuously run the fingerprinting script to watch for changes. So if you transfer any queue cookies to another browser they'll figure it out pretty fast when suddenly that browser starts giving completely different information. It will also look at stuff like your mouse pattern and you tabbing in and out to build a behavioural pattern

 

They analyse it all serverside with machine learning to compare what you're doing, to that of a typical user and bot.

 

They can also link you to activity on previous Akamai sites to work out if you're bot like or not.

 

If it thinks you're a bot it will flag you for a ban which doesn't happen instantly but typically in a minute or two.

 

If you clear the cookie it will just refingerprint you and then ban you again.

 

Queue-It is integrated into the Akamai suite and uses Akamai session handling.

 

If you're on something that meets a typical shared IP pattern such as a CGNAT like using a phone on mobile data or on a work computer they will give you a lower score and more leeway basically. If you're logging on from those AWS instances you spun up you'll be given a high score. Plus like you might have different drivers, fonts, setups, running different mobile os versions, bought different device models, languages etc. If you're doing something it considers weird like running Linux, or keeping the tab in the background you'll be given a higher score.

 

My friends got a screen reader and triggered it trying to register so I guess they've got it on a pretty high setting. I emailed them to tell them

 

Also interesting is that the SeeTickets side after the CDN is not changed at all and still has the 'youre on a holding page, refresh in 20 seconds' active which I saw triggered the other day.

 

So i'm guessing the queueit will block access to the website until you're at the front of the queue and then give you a 10 minute token to access it normally

 

If they don't properly clear the queueit session then you will be able to buy as many tickets as you like in those 10 minutes

 

A lot of it is similar to how those click here if you're a human boxes work, sometimes they let you straight on because you look like a typical user from a typical network and haven't done anything funny, sometimes they might ask you to solve a picture puzzle if you're on a shared network, and if you're on a VPN it will blast you with tons of pictures that it intentionally makes very grainy to try and trip you up

 

I do DevOps work and have seen some presentations from their competitor so figured out how this ones working

Is that competitor Cloudflare?  

This is pretty much what I was trying to describe, though in much much more detail. If you're detected as using a bot, you're probably not getting anywhere near a queue-it page, never mind the front of the queue, because bot detection and human verification for Akamai is done on the edge.

I use a very simple tunnel system from Cloudflare called Zero Trust to protect my servers. When the URLs to my servers are entered, you get nowhere near my physical hardware until you've cleared Cloudflare's security (as it's only me that needs to access them, that is an MFA approach of an emailed code first, with only my address whitelisted, so any other entered will not get a code at all, then once that's cleared, a password and HW key.) I could also enable Cloudflare's bot protection amongst many other things, but I don't feel I need it for my use case, so I only use Zero Trust access control. 

Everything I've read about Akamai on their site is suggesting to me that it's a very similar system.

[Fake Encore]

I don't want to go to Glastonbury with people who use tunnel servers, vpn re-routing systems or pay £900 for slots in the tickets queue or stop in a kubutz 2 miles away.

 

I want the hippies at Strummerville, the great unwashed, the ones who will go to the JP Tent at 11.30am as they half heard a song on 6 a year ago, the one getting a swedish massage and not just for instragram but, because there back hurts lugging the thatchers up the hill.

 

Amen 

[Supernintendo Chalmers]

4 minutes ago, Fake Encore said:

I don't want to go to Glastonbury with people who use tunnel servers, vpn re-routing systems or pay £900 for slots in the tickets queue or stop in a kubutz 2 miles away.

 

I want the hippies at Strummerville, the great unwashed, the ones who will go to the JP Tent at 11.30am as they half heard a song on 6 a year ago, the one getting a swedish massage and not just for instragram but, because there back hurts lugging the thatchers up the hill.

 

Amen 

 

Beautiful. Even better if you read it aloud whilst playing "Jerusalem" in the background

[dg.bandol]

Naïve tech question: we have a router with a guest network - if one device is connected to the "regular" WiFi and another connected to the guest WiFi, will this have separate public IP addresses or would it still present to an external server as the same public IP? 

[Slimeyc]

8 minutes ago, dg.bandol said:

Naïve tech question: we have a router with a guest network - if one device is connected to the "regular" WiFi and another connected to the guest WiFi, will this have separate public IP addresses or would it still present to an external server as the same public IP? 

 

Most likely same IP 

[Ayrshire Chris]

11 minutes ago, Fake Encore said:

I don't want to go to Glastonbury with people who use tunnel servers, vpn re-routing systems or pay £900 for slots in the tickets queue or stop in a kubutz 2 miles away.

 

I want the hippies at Strummerville, the great unwashed, the ones who will go to the JP Tent at 11.30am as they half heard a song on 6 a year ago, the one getting a swedish massage and not just for instragram but, because there back hurts lugging the thatchers up the hill.

 

Amen 

Wonderful sentiments, and sadly, unfortunately that ship sailed a long time ago. Just like I’d love to go to gigs where when I stand up and get into the music the person behind doesn’t tut tut. 

[Crazyfool01]

1 minute ago, Slimeyc said:

 

Most likely same IP 

theres a way of testing that isnt there ? find my ip or something ? 

[Ayrshire Chris]

15 minutes ago, Supernintendo Chalmers said:

 

Beautiful. Even better if you read it aloud whilst playing "Jerusalem" in the background

Good suggestion, but I’d go for Radioheads pyramid song 

[t0paz]

16 minutes ago, dg.bandol said:

Naïve tech question: we have a router with a guest network - if one device is connected to the "regular" WiFi and another connected to the guest WiFi, will this have separate public IP addresses or would it still present to an external server as the same public IP? 

It’ll almost certainly be the same but you can confirm it by going to whatismyip.com on both devices and seeing what they are.

[stuie]

33 minutes ago, Fake Encore said:

I don't want to go to Glastonbury with people who use tunnel servers, vpn re-routing systems or pay £900 for slots in the tickets queue or stop in a kubutz 2 miles away.

 

I want the hippies at Strummerville, the great unwashed, the ones who will go to the JP Tent at 11.30am as they half heard a song on 6 a year ago, the one getting a swedish massage and not just for instragram but, because there back hurts lugging the thatchers up the hill.

 

Amen 

 

Can someone put this through the Morgan Freeman voice generator please? 🙂 

[merago]

16 minutes ago, Crazyfool01 said:

theres a way of testing that isnt there ? find my ip or something ? 

https://www.whatismyip.com/

[gsp8181]

7 hours ago, Mike A said:

 

Is there a way to tell if your browser is being scanned?

If so, would you expect the scan frequency to correlate with your score to some degree?

 

I'd like be able to get a sense if I'm clean (i.e low threshold) or not.

 

It is being scanned in the background anyway. However i've noticed on some of my machines it will show a white page when you first go onto the website (i.e. incognito) and will direct you a second or two later to the Glastonbury holding page. All it's doing it scanning your browser and I suspect you're over the low threshold. My phone (on 4g) lets me on instantly in incognito.

[Scrump]

1 hour ago, Fake Encore said:

I don't want to go to Glastonbury with people who use tunnel servers, vpn re-routing systems or pay £900 for slots in the tickets queue or stop in a kubutz 2 miles away.

 

I want the hippies at Strummerville, the great unwashed, the ones who will go to the JP Tent at 11.30am as they half heard a song on 6 a year ago, the one getting a swedish massage and not just for instragram but, because there back hurts lugging the thatchers up the hill.

 

Amen 

Totally agree, but I would add it's possible to be into all this techy stuff as well as being an unwashed hippy who loves music and cider.  In the same way there are self proclaimed hippies who don't live by it's ethos. 

 

People paying £900 for a spot in the queue can get in the bin.

[bob323]

52 minutes ago, gsp8181 said:

 

It is being scanned in the background anyway. However i've noticed on some of my machines it will show a white page when you first go onto the website (i.e. incognito) and will direct you a second or two later to the Glastonbury holding page. All it's doing it scanning your browser and I suspect you're over the low threshold. My phone (on 4g) lets me on instantly in incognito.

it would be interesting to learn how they do the fingerprinting using javascript - i suspect if you could be bothered it could be manipulated. but you'd still have the same IP address which I suspect would play a big part in their scoring algorithm

Edited November 8 by bob323

[gsp8181]

6 minutes ago, Scrump said:

Totally agree, but I would add it's possible to be into all this techy stuff as well as being an unwashed hippy who loves music and cider.  In the same way there are self proclaimed hippies who don't live by it's ethos. 

 

People paying £900 for a spot in the queue can get in the bin.

 

To be fair two lads in our campsite had paid something similar from some scouse lad who had a load of EPO bands, apparently Glastonbury had introduced a new system with an EPO scanner to stop people abusing them and somehow these lads had hold of one of the scanners within the hour.

 

5 hours ago, Alvoram said:

Yes I guess, and that's certainly one way of looking at it. But lots of tickets were also taken out of rotation by people who were able to game that too, with the back button glitch, allowing people to buy there entire spreadsheet's groups in a couple of minutes...

Again, bad news if you were someone doing this / able to do this, good news for everybody else. 

 

Is that competitor Cloudflare?  

This is pretty much what I was trying to describe, though in much much more detail. If you're detected as using a bot, you're probably not getting anywhere near a queue-it page, never mind the front of the queue, because bot detection and human verification for Akamai is done on the edge.

I use a very simple tunnel system from Cloudflare called Zero Trust to protect my servers. When the URLs to my servers are entered, you get nowhere near my physical hardware until you've cleared Cloudflare's security (as it's only me that needs to access them, that is an MFA approach of an emailed code first, with only my address whitelisted, so any other entered will not get a code at all, then once that's cleared, a password and HW key.) I could also enable Cloudflare's bot protection amongst many other things, but I don't feel I need it for my use case, so I only use Zero Trust access control. 

Everything I've read about Akamai on their site is suggesting to me that it's a very similar system.

 

Yeah i'd say Akamai is the big brother competitor to Cloudflare, they both offer identical products but Cloudflare throws more money at devs so they will talk it up around the office and be more familiar to it. Same deal, they offer enterprise bot management with the exact same detection methods and they have their own queuing system.

 

But the end result is the same, if you think you're going to do something cleaver with modifying the source in web inspector or pass around queue ids or cookies, it will know and block you. Even pressing 'view source' counts as a very heavy strike against you, or rapidly cycling around browsers/ip addresses/clearing cookies.

[gsp8181]

16 minutes ago, bob323 said:

it would be interesting to learn how they do the fingerprinting using javascript - i suspect if you could be bothered it could be manipulated. but you'd still have the same IP address which I suspect would play a part in their scoring algorithm

https://www.amiunique.org/

https://coveryourtracks.eff.org

 

if you're interested in the web fingerprinting methods, it will show you the same ways they're using.

[CaledonianGonzo]

If you're trying from abroad using an eSim - would two different eSim providers on two different devices generate two different IPs?

[merago]

3 minutes ago, CaledonianGonzo said:

If you're trying from abroad using an eSim - would two different eSim providers on two different devices generate two different IPs?

Yes

[CaledonianGonzo]

2 minutes ago, merago said:

Yes

 

Great - ta

[Fish Bulb]

29 minutes ago, gsp8181 said:

https://www.amiunique.org/

https://coveryourtracks.eff.org

 

if you're interested in the web fingerprinting methods, it will show you the same ways they're using.

Does clicking on either of those automatically increase your bot score?

[bob323]

36 minutes ago, Fish Bulb said:

Does clicking on either of those automatically increase your bot score?

no, they give you details on how unique your finger print is and some explaination on what to do

[stuie]

1 hour ago, gsp8181 said:

https://www.amiunique.org/

https://coveryourtracks.eff.org

 

if you're interested in the web fingerprinting methods, it will show you the same ways they're using.

 

I just tried https://www.amiunique.org/ on my work Terminal Server desktop and it closed my connection and disconnected the VPN so I probably won't try that method on ticket day.

Edited November 8 by stuie

[moo-e]

20 hours ago, gsp8181 said:

Here's how it's working

 

You go onto glastonbury.seetickets.com. You'll hit an Akamai CDN which is protected with Akamai Bot Manager

 

It will calculate an initial score for you based on your hostname, IP address, useragent, ISP, and how many people are going through that IP. So if you're going through something dodgy like a cloud datacentre or a commercial VPN you'll be a lot higher. If you're going through a mobile network AND are a mobile phone you'll probably be given more leeway.

 

If your score is too high you'll be instantly blocked, if you're in the mid zone you'll be 'flagged', and if it's low you'll be let on instantly.

 

If you're in the midpoint you can usually tell because the first time you log into the website you'll see a short delay before you get on while it 'fingerprints' your browser. Whereby it uses Javascript to gather all the information it can and can identify you with surprising accuracy, from stuff like, do you have any custom fonts, what plugins do you have in your browser, to the weirder stuff like drawing animations and analysing them to see if your graphics card has any minute differences. So they can track you if you've got firefox and chrome on the same machine.

 

Akamai will then set a load of cookies to link you to a session.

 

They'll then continuously run the fingerprinting script to watch for changes. So if you transfer any queue cookies to another browser they'll figure it out pretty fast when suddenly that browser starts giving completely different information. It will also look at stuff like your mouse pattern and you tabbing in and out to build a behavioural pattern

 

They analyse it all serverside with machine learning to compare what you're doing, to that of a typical user and bot.

 

They can also link you to activity on previous Akamai sites to work out if you're bot like or not.

 

If it thinks you're a bot it will flag you for a ban which doesn't happen instantly but typically in a minute or two.

 

If you clear the cookie it will just refingerprint you and then ban you again.

 

Queue-It is integrated into the Akamai suite and uses Akamai session handling.

 

If you're on something that meets a typical shared IP pattern such as a CGNAT like using a phone on mobile data or on a work computer they will give you a lower score and more leeway basically. If you're logging on from those AWS instances you spun up you'll be given a high score. Plus like you might have different drivers, fonts, setups, running different mobile os versions, bought different device models, languages etc. If you're doing something it considers weird like running Linux, or keeping the tab in the background you'll be given a higher score.

 

My friends got a screen reader and triggered it trying to register so I guess they've got it on a pretty high setting. I emailed them to tell them

 

Also interesting is that the SeeTickets side after the CDN is not changed at all and still has the 'youre on a holding page, refresh in 20 seconds' active which I saw triggered the other day.

 

So i'm guessing the queueit will block access to the website until you're at the front of the queue and then give you a 10 minute token to access it normally

 

If they don't properly clear the queueit session then you will be able to buy as many tickets as you like in those 10 minutes

 

A lot of it is similar to how those click here if you're a human boxes work, sometimes they let you straight on because you look like a typical user from a typical network and haven't done anything funny, sometimes they might ask you to solve a picture puzzle if you're on a shared network, and if you're on a VPN it will blast you with tons of pictures that it intentionally makes very grainy to try and trip you up

 

I do DevOps work and have seen some presentations from their competitor so figured out how this ones working

 

Great post! A bit of info about the queue-it side - (caveats - all the following is from having a look at their github repos and using dev tools on see tickets)

 

queue-it have a nice diagram showing how the queue-it Edge connector (EC) (term for the bit of queue-it code that runs in Akamai) interacts with the origin server (seetickets) and queue-it 

https://github.com/queueit/Documentation/tree/main/edge-connectors

 

The diagram/process could be well out of date (2 years old) but from a look at the Sam Fender (SF) tix on seetickets some parts of that described flow are in place (hard to say if all of it is the same since there is no actual queueing for SF at the moment)

 

So using the SF use case to (partially) step thru the EC diagram 
- hit link https://www.seetickets.com/event/sam-fender/first-direct-arena/3205111 with your browser. This is a protected url and will be processed by Akamai first

- The EC in Akamai sees you have no QueueITAccepted cookie so it redirects you to https://www.seetickets.com/queue/ with an enqueue token as a query string param

- Since there is no queuing at the moment for SF you're redirected to https://www.seetickets.com/event/sam-fender/first-direct-arena/3205111?queueittoken=XXXXX by the EC. You now have a  queueittoken token (I think this would be generated by queue-it in a waiting room case but in this case it is generated by the EC)

- the EC validates the queueittoken and in the response headers sets a QueueITAccepted cookie (not token) for the session

- that QueueITAccepted cookie is now present for all subsequent requests, it is checked by the EC and if valid the EC allows the request back to the origin (seetickets)

 

[speculation as to how this will work for Glasto sales]

- I think this enqueue token will be given to Glasto users when they gather for the prequeue i.e. the page with the countdown timer before sales start - the enqueue token will be part of the redirect to the queue-it waiting room

- users who go to glasto sales url after sale has started will be given a enqueue token that puts them at the back of the queue (there are docs in queue-it.com showing how you can prioritise one set of users - namely those who gather at the prequeue countdown page over the latecomers who now have a standard first-in first-out queuing experience - but behind all those who gathered at the prequeue countdown page)
- queue-it waiting room redirects users as their turn comes back to the EC with a queueittoken token

- the EC validates the queueittoken, one of the checks can be an ip check (the token can have an ip encoded in it, the EC checks if it corresponds to the source ip of the request https://github.com/queueit/KnownUser.V3.Akamai/blob/master/sdk/queueit-knownuserv3-sdk.js#L1072 ). I am not saying this happens all the time, the code will handle situations where the ip is not in the token).

- if queueittoken is valid your browser is given a QueueITAccepted cookie by the EC and allows you thru to the origin (seetickets) where you can happily buy tickets. As you browse thru the ticket buying flow the presence (or not) of QueueITAccepted cookie is checked and validated by the EC on each request. It has an expiry time and once that is reached the EC will redirect you back to the waiting room

[end speculation]

 

So 2 tokens and a cookie, all tamper proof (encrypted or signed). The can contain fields like expiry, ip (or a hash of it), queueid. They are all validated on each redirect.

- enqueuetoken is for entering the waiting room to queue. It can have a uuid - which might be the basis for the your position in the queue https://github.com/queueit/KnownUser.V3.Akamai/blob/master/sdk/queueToken.js#L405 

- queueittoken, you get after you have finished queueing - I think it can be generated by the queueing room but in the SF case it was generated by the EC https://github.com/queueit/KnownUser.V3.Akamai/blob/master/sdk/queueit-knownuserv3-sdk.js#L780

- QueueITAccepted - the cookie that let's you thru! https://github.com/queueit/KnownUser.V3.Akamai/blob/master/sdk/queueit-knownuserv3-sdk.js#L1140

Here is the validation done by the EC on QueueITAccepted  https://github.com/queueit/KnownUser.V3.Akamai/blob/master/sdk/queueit-knownuserv3-sdk.js#L1211 (which can include an ip check)

 

In the Sam Fender case the queueittoken and QueueITAccepted cookie I got did not have an ip or hashed ip (they are signed rather than encrypted so you can inspect the fields). Am sure that is all configurable by seetickets/queue-it depending on the event.

 

I don't think queue-it are doing much checking (bot detection, browser fingerprinting, browser reputation, user behaviour) in their EC code other than ip checking - and this check is just to confirm the token/cookie wasn't created on source ip A and then copied to be used on source ip B. Queue-it may well be are doing the more sophisticated detection in their waiting room/queuing component - which is place for bots to attack, to try and jump ahead of the queue. For the EC code they are leaving all that to Akamai (who've been doing it for years). 

 

Lastly - some of queue-it variables for the EC are handily listed https://github.com/queueit/KnownUser.V3.Akamai/tree/master 

It sort of confirms some of the above e.g. "If enabled at waitingroom, it is used to validate the vistor IP by connector"

final thoughts

- I think Akamai will be the source of "403 Forbidden" etc. Check your devices https://www.akamai.com/us/en/clientrep-lookup/

- we don't know how your queue position is formed other than "random"

- there is a flexible "payload" field on the enqueuetoken which could be used to transmit info from Akamai to queue-it (e.g. browser behaviour/reputation) which might be used to determine where you are in the queue but it doesn't seem to be used for that from a look at the code on that repo (which is 2 years old of course!)

- one interesting blog post from queue-it about how tickets can appear to be sold out when they are not - not sure if this will apply to Glasto since the tickets are only removed from inventory when the card transaction goes thru (??) but it should still encourage us to not give up https://queue-it.com/blog/tickets-sold-out-debunking-instant-sellout-myth/

- queue-it queues can be paused as well. e.g. if seetickets have some of DB meltdown then they can pause the queue (no more users come thru to seetickets), sort things out and unpause. 

 

[Crazyfool01]

has anyone got a translation tool handy ? 🙂 

[bob323]

9 minutes ago, moo-e said:

 

Great post! A bit of info about the queue-it side - (caveats - all the following is from having a look at their github repos and using dev tools on see tickets)

 

queue-it have a nice diagram showing how the queue-it Edge connector (EC) (term for the bit of queue-it code that runs in Akamai) interacts with the origin server (seetickets) and queue-it 

https://github.com/queueit/Documentation/tree/main/edge-connectors

 

The diagram/process could be well out of date (2 years old) but from a look at the Sam Fender (SF) tix on seetickets some parts of that described flow are in place (hard to say if all of it is the same since there is no actual queueing for SF at the moment)

 

So using the SF use case to (partially) step thru the EC diagram 
- hit link https://www.seetickets.com/event/sam-fender/first-direct-arena/3205111 with your browser. This is a protected url and will be processed by Akamai first

- The EC in Akamai sees you have no QueueITAccepted cookie so it redirects you to https://www.seetickets.com/queue/ with an enqueue token as a query string param

- Since there is no queuing at the moment for SF you're redirected to https://www.seetickets.com/event/sam-fender/first-direct-arena/3205111?queueittoken=XXXXX by the EC. You now have a  queueittoken token (I think this would be generated by queue-it in a waiting room case but in this case it is generated by the EC)

- the EC validates the queueittoken and in the response headers sets a QueueITAccepted cookie (not token) for the session

- that QueueITAccepted cookie is now present for all subsequent requests, it is checked by the EC and if valid the EC allows the request back to the origin (seetickets)

 

[speculation as to how this will work for Glasto sales]

- I think this enqueue token will be given to Glasto users when they gather for the prequeue i.e. the page with the countdown timer before sales start - the enqueue token will be part of the redirect to the queue-it waiting room

- users who go to glasto sales url after sale has started will be given a enqueue token that puts them at the back of the queue (there are docs in queue-it.com showing how you can prioritise one set of users - namely those who gather at the prequeue countdown page over the latecomers who now have a standard first-in first-out queuing experience - but behind all those who gathered at the prequeue countdown page)
- queue-it waiting room redirects users as their turn comes back to the EC with a queueittoken token

- the EC validates the queueittoken, one of the checks can be an ip check (the token can have an ip encoded in it, the EC checks if it corresponds to the source ip of the request https://github.com/queueit/KnownUser.V3.Akamai/blob/master/sdk/queueit-knownuserv3-sdk.js#L1072 ). I am not saying this happens all the time, the code will handle situations where the ip is not in the token).

- if queueittoken is valid your browser is given a QueueITAccepted cookie by the EC and allows you thru to the origin (seetickets) where you can happily buy tickets. As you browse thru the ticket buying flow the presence (or not) of QueueITAccepted cookie is checked and validated by the EC on each request. It has an expiry time and once that is reached the EC will redirect you back to the waiting room

[end speculation]

 

So 2 tokens and a cookie, all tamper proof (encrypted or signed). The can contain fields like expiry, ip (or a hash of it), queueid. They are all validated on each redirect.

- enqueuetoken is for entering the waiting room to queue. It can have a uuid - which might be the basis for the your position in the queue https://github.com/queueit/KnownUser.V3.Akamai/blob/master/sdk/queueToken.js#L405 

- queueittoken, you get after you have finished queueing - I think it can be generated by the queueing room but in the SF case it was generated by the EC https://github.com/queueit/KnownUser.V3.Akamai/blob/master/sdk/queueit-knownuserv3-sdk.js#L780

- QueueITAccepted - the cookie that let's you thru! https://github.com/queueit/KnownUser.V3.Akamai/blob/master/sdk/queueit-knownuserv3-sdk.js#L1140

Here is the validation done by the EC on QueueITAccepted  https://github.com/queueit/KnownUser.V3.Akamai/blob/master/sdk/queueit-knownuserv3-sdk.js#L1211 (which can include an ip check)

 

In the Sam Fender case the queueittoken and QueueITAccepted cookie I got did not have an ip or hashed ip (they are signed rather than encrypted so you can inspect the fields). Am sure that is all configurable by seetickets/queue-it depending on the event.

 

I don't think queue-it are doing much checking (bot detection, browser fingerprinting, browser reputation, user behaviour) in their EC code other than ip checking - and this check is just to confirm the token/cookie wasn't created on source ip A and then copied to be used on source ip B. Queue-it may well be are doing the more sophisticated detection in their waiting room/queuing component - which is place for bots to attack, to try and jump ahead of the queue. For the EC code they are leaving all that to Akamai (who've been doing it for years). 

 

Lastly - some of queue-it variables for the EC are handily listed https://github.com/queueit/KnownUser.V3.Akamai/tree/master 

It sort of confirms some of the above e.g. "If enabled at waitingroom, it is used to validate the vistor IP by connector"

final thoughts

- I think Akamai will be the source of "403 Forbidden" etc. Check your devices https://www.akamai.com/us/en/clientrep-lookup/

- we don't know how your queue position is formed other than "random"

- there is a flexible "payload" field on the enqueuetoken which could be used to transmit info from Akamai to queue-it (e.g. browser behaviour/reputation) which might be used to determine where you are in the queue but it doesn't seem to be used for that from a look at the code on that repo (which is 2 years old of course!)

- one interesting blog post from queue-it about how tickets can appear to be sold out when they are not - not sure if this will apply to Glasto since the tickets are only removed from inventory when the card transaction goes thru (??) but it should still encourage us to not give up https://queue-it.com/blog/tickets-sold-out-debunking-instant-sellout-myth/

- queue-it queues can be paused as well. e.g. if seetickets have some of DB meltdown then they can pause the queue (no more users come thru to seetickets), sort things out and unpause. 

 

brill and thanks, thats the info i was after (eg the sequence diagram)

 

based on what are saying, it's possible (but a risk) that having multiple tabs (possibly in containers) or multiple browsers open would increase your chances, as each would get their own tokens?

Edited November 8 by bob323