2024 Ticket Buying Tips

[mobfant]

I think they'd have to act now that knowledge of the hack / method is so widespread and so many more people will be doing it for resale/future events.

[briddj]

When I put a second set of IDs in for another purchase after getting mine I was put back in the queue when I pressed submit.

[angelin]

The difference was in the old days anyone who had worked it out would post it on here as soon as they got their tickets  but now I suppose there are many other places where the6 prefer to share.

 

I remember finding the first secret resale by chance one afternoon I was off work. No warnings at all. I put it on the forum, Was this forum there them? I thought it was called something else. And many people got them that afternoon. I doubt we will ever see a secret resale again.

[BBC7BBCHEAVEN]

25 minutes ago, incident said:

I don't agree this is the same as 2013. The implementation and effect might be broadly the same, but the crucial difference is that this is bringing servers into play that were never intended to be used to sell Glastonbury tickets whereas the time you're referencing was more about working around broken load balancing.

So while I do agree that they probably won't do anything - I wouldn't entirely rule it out, and if they don't address it for next time then it'll cause them huge problems going forward.

My understanding (not much!) from other posts on it is that this is also a load balancing issue, it's basically forcing the login to a server that has less access and you get through? I don't really see the difference from this and 2013, the method seems the same with the host file etc.?

(Again my understanding is limited)

Either way it's an absolute embarrassment that one of the biggest ticket sales can have a workaround so easy that the average person can implement it with no IT knowledge

[incident]

2 minutes ago, BBC7BBCHEAVEN said:

My understanding (not much!) from other posts on it is that this is also a load balancing issue, it's basically forcing the login to a server that has less access and you get through? I don't really see the difference from this and 2013, the method seems the same with the host file etc.?

(Again my understanding is limited)

Either way it's an absolute embarrassment that one of the biggest ticket sales can have a workaround so easy that the average person can implement it with no IT knowledge

It's nothing to do with load balancing, given that the server was (from See's perspective) deliberately not included in the Glastonbury sale and all evidence suggests was never intended to be.

[stuartasmith85]

1 hour ago, incident said:

It's nothing to do with load balancing, given that the server was (from See's perspective) deliberately not included in the Glastonbury sale and all evidence suggests was never intended to be.

If this is right, how did people discover the IP address of the server in the first place?

Or would that have come from someone getting the IP from a non-Glasto Seetickets transaction this morning?

[CurlyPutz]

48 minutes ago, incident said:

It's nothing to do with load balancing, given that the server was (from See's perspective) deliberately not included in the Glastonbury sale and all evidence suggests was never intended to be.

Hey, I agree it's a different situation network wise this time but I am finding it interesting how this worked. 2013 was a bad load balanced server, planned for use but busted at the time I think. 

This time an "unplanned to be used for the sale" server was used to purchase glasto tickets, how though unless every web/app server has the same application set deployed at see tickets? Even then I would have thought the dns override via hosts to force to a server that just happens to have the glasto code installed would have caused issues with certificates and host names somewhere within the application/services somewhere? 

Missed out twice in a row now and always good to understand more about the tech side for potential future tickets. I don't have hundreds of mates to help and not joined any groups. 

[incident]

4 minutes ago, stuartasmith85 said:

If this is right, how did people discover the IP address of the server in the first place?

Or would that have come from someone getting the IP from a non-Glasto Seetickets transaction this morning?

Essentially - yeah. Someone will have looked up what www.seetickets.com (or similar) was set to and tried that.

 

2 minutes ago, CurlyPutz said:

This time an "unplanned to be used for the sale" server was used to purchase glasto tickets, how though unless every web/app server has the same application set deployed at see tickets? Even then I would have thought the dns override via hosts to force to a server that just happens to have the glasto code installed would have caused issues with certificates and host names somewhere within the application/services somewhere? 

Missed out twice in a row now and always good to understand more about the tech side for potential future tickets. I don't have hundreds of mates to help and not joined any groups. 

Yep presumably all the See servers are configured the same (which isn't as strange as it sounds - it makes their life a hell of a lot easier), which will have allowed this to happen.

[stuartasmith85]

I suppose the other interesting question is what changed about See’s setup to allow that to work this year (assuming it hasn’t worked in previous years)?

[incident]

4 minutes ago, stuartasmith85 said:

I suppose the other interesting question is what changed about See’s setup to allow that to work this year (assuming it hasn’t worked in previous years)?

It would have worked last year for sure. Not sure about before that.

It's quite possible people were doing it last year, but staying quiet (which, tbh, would be the logical approach).

[fraybentos1]

is there anything See can do to stop this?

Also is the backdoor method mean you can get on to book tickets easy or just that if you had tickets you could keep going in and buying multiple?

[incident]

Just now, fraybentos1 said:

is there anything See can do to stop this?

Also is the backdoor method mean you can get on to book tickets easy or just that if you had tickets you could keep going in and buying multiple?

Yes, if they configure their servers to do so.

And both.

[fraybentos1]

24 minutes ago, incident said:

Yes, if they configure their servers to do so.

 

Do you think that is likely based on how widespread it seems it is?

What I don't get is why did it work in 2013 or whatever then again now and not in the interim. Or has it always worked and just gone viral now?

[TheGoodWillOut]

2 hours ago, incident said:

It's nothing to do with load balancing, given that the server was (from See's perspective) deliberately not included in the Glastonbury sale and all evidence suggests was never intended to be.

What's the evidence that suggests it was never intended to be included? 
Potentially it could be a front end web server that the load balancers was misconfigured to not use or only push say 5% of hits to it. 

 

 

[stuartasmith85]

3 minutes ago, fraybentos1 said:

Do you think that is likely based on how widespread it seems it is?

What I don't get is why did it work in 2013 or whatever then again now and not in the interim. Or has it always worked and just gone viral now?

If I’m understanding rightly, two different situations. In 2013, going back to Neil’s old post, there was an issue where the DNS was configured incorrectly, so a server that was meant to be used was not being - that was then fixed live during that sale.

Here, it sounds like someone worked out that you could still access the Glasto sale pages via an entirely different server, that you wouldn’t have got to at any point this morning just going via the normal link.

[M-T]

6 minutes ago, stuartasmith85 said:

Here, it sounds like someone worked out that you could still access the Glasto sale pages via an entirely different server, that you wouldn’t have got to at any point this morning just going via the normal link.

I've seen chat indicating this may have always been a 'feature' - the question is will See address it due to the changes needed on their side.

5 IPs seem to have been involved, curious how were these isolated - anyone can share?

[billum]

2 minutes ago, M-T said:

I've seen chat indicating this may have always been a 'feature' - the question is will See address it due to the changes needed on their side.

5 IPs seem to have been involved, curious how were these isolated - anyone can share?

I'm no expert at all, but could it be that the IP addresses of a handful of See ticket servers were noted during sales of tickets for other events, and today they were co-opted into buying Glasto tickets?

[incident]

19 minutes ago, fraybentos1 said:

Do you think that is likely based on how widespread it seems it is?

Not a clue.

 

19 minutes ago, fraybentos1 said:

What I don't get is why did it work in 2013 or whatever then again now and not in the interim. Or has it always worked and just gone viral now?

As I've pointed out, the 2013 thing was very different. It will have worked last year. Full disclosure - I noticed this quirk during the November 2022 sale, but decided not to risk it. I might have made a different decision if it was only my own ticket at stake but would feel utterly sh*t if it backfired on friends.

 

17 minutes ago, TheGoodWillOut said:

What's the evidence that suggests it was never intended to be included? 
Potentially it could be a front end web server that the load balancers was misconfigured to not use or only push say 5% of hits to it.

The fact that it's in a totally different server pool to the ones they were using for Glastonbury. There's 5 servers in the (usual) main pool - all 5 of these were serving Glastonbury traffic today. There's also 3 servers in the backup pool - none of those were serving Glastonbury traffic today. However all 3 were (unusually) serving traffic on www.seetickets.com, www.gigsandtours.com, etc - it's inconceivable that this wasn't a conscious decision in order to isolate those sites from the madness. The server used for the IP switch is one of the 3 in the backup pool.

Edited November 19, 2023 by incident

[Acid Loafers]

13 minutes ago, fraybentos1 said:

What I don't get is why did it work in 2013 or whatever then again now and not in the interim. Or has it always worked and just gone viral now?

If this was around in previous years, no way it wouldn't leak one way or another.

My biggest bet is some tech savvy folk noticed a flaw during Thursdays sale? Not sure if people were already using it by then.

What this does show is that if SeeTickets cared (which I think they don't) an idea would be to limit tickets purchased to IP addresses, as 1 person buying 40+ tickets does not seem to be in the spirit of the festival or fair. Big groups would still have the advantage, but the person who gets through is "out" of trying for the rest, & the 5 people who had tickets bought for them, can now try for other groups.

But I can already see the posts "Our IP got blocked & we didn't buy any tickets" drama if this tech was introduced 

I have no idea on this stuff, so probably a flawed idea

[TheGoodWillOut]

1 minute ago, incident said:

Not a clue.

 

As I've pointed out, the 2013 thing was very different. It will have worked last year. Full disclosure - I noticed this quirk during the November 2022 sale, but decided not to risk it. I might have made a different decision if it was only my own ticket at stake but would feel utterly sh*t if it backfired on friends.

 

The fact that it's in a totally different server pool to the ones they were using for Glastonbury. There's 5 servers in the (usual) main pool - all 5 of these were serving Glastonbury traffic today. There's also 3 servers in the backup pool - none of those were serving Glastonbury traffic today. However all 3 were (unusually) serving traffic on www.seetickets.com, www.gigsandtours.com, etc - it's inconceivable that this wasn't a conscious decision. The server used for the IP switch is one of the 3 in the backup pool.

Thanks, wasn't aware of the different ip pools or if they were different for the backend. I've just seen the ip used for the hosts hack.  As you say very strange the backup servers were handling live data for seetickets & gigs and tours 

[Bolivia95]

I’ve seen a few people this year claiming a ‘back door’ link using an IP. Has this always been a thing? I’ve seen the posts from 2012 but not much mention of it since.

This comment is from 2018 which I think is referring to 2012.

 

[Toilet Duck]

3 hours ago, bob323 said:

that did not work for me!!!

Nor me! First thing I tried after I got my confirmation…kicked me back to holding

[TheGoodWillOut]

I guess all it would've taken is a dns lookup/interrogation  for glastonbury.seetickets.com last Thursday when the coach sale would've happened and this would've listed the public ip's used for that.  Someone's then noted the ip not in the main pool and thought hmmm maybe! 

or thought let's go via www.seetickets.com with the same web address and see if we get a anything different.

 

Edited November 19, 2023 by TheGoodWillOut

[JayBoogie]

I'd be interested to know how mainstream this hack stuff has got

Wouldn't be surprised if they introduced something pragmatic, like payment details have to match the main booker

 

[TheGoodWillOut]

3 minutes ago, JayBoogie said:

I'd be interested to know how mainstream this hack stuff has got

Wouldn't be surprised if they introduced something pragmatic, like payment details have to match the main booker

 

It's not really much of a hack to be honest, you're just using a different server that you weren't supposed to or were there for backup or emergency failover 

Edited November 19, 2023 by TheGoodWillOut