this is definetly worth usd $20
So the most expensive MMO on the market canāt protect itself from DDOS attacks. So this also means SEAT and AA are useless except for 4 days out of the month if you are LUCKY.
Glad to see that subscription hike going to good use.
Its not ddos
It basically is at this point going off the numbers they are saying. People not knowing how to use the ESI correctly. Requesting an ungodly amount of requests which is overloading the serverā¦ oh that sounds like something I canāt put my finger onā¦
@CCP_Zelus @CCP_Zelus AWS has a acceptable use policyā¦ why not report them directly to the people they also use?
" * to violate the security, integrity, or availability of any user, network, computer or communications system, software application, or network or computing device"
https://support.aws.amazon.com/#/contacts/report-abuse
Deal with the issue, get those people locked out of AWS. After a few resetsā¦ they will get the point.
Protect your player base, and attack the issue directly. Then do the ESI change planning, so you can deal with abusers from the other side of things.
One other suggestion, maybe a partner program for people that provide third party services. I provide Linux instances to people that do not want anything to do with information technology but still need ESI verification tools. Partner up with us, communicate with usā¦ lets attack this together as a team.
Now that I know people are taking advantage, I understand. Just wish you guys would have tried all the other options first like I listed above and told us about it.
Just my two cents.
2 Likes
why donāt you just block anonyous request? and just let people who has been identified by a sso eve account does the requests ? so if they abuse, you disable esi requests for this account.
@CCP_Zelus We already have to generate our keys and such for our applications, Would it not be possible to simply use those keys, or have developers provide the IP their queries will be coming from and whitelist that? Could even have a different authenticated/whitelisted endpoint that has a shorter cache duration than the unathenticated endpoint. You could also use some form of IP based rate limiting, NGINX supports this and that would be trivial to put infront of your existing stack.
I rely heavily on tools like Pathfinder and EVE IPH to enhance my EVE Online experience, they are a key factor in my continued enjoyment of the game. I believe that many other players feel the same way.
I understand that maintaining old code can be challenging, but it is part of what I pay for as a player, and I hope that you will make the necessary investments in your engineers and resources to address these issues with the ESI endpoints.
I am confident that with the input and ideas of the player community, a fair solution to tracking abuse of these endpoints can be found.
For those mentioning the affiliation endpoint. Its worth noting that the sole individual causing all these issues for us is trying scrape everything from ESI, but is very impatient and cant spend the 2 or 3 days it would take to scrape everything with a rate limit.
The affiliation endpoint returns nothing if a character ID does not exist, this means the dev scraping is going to be hammering that endpoint with single character IDs at a time.
Iām not sure how the above isnāt obvious to the ESI maintainers at CCP.
Given CCPās current trend with ESI, the affiliation endpoint will be the next endpoint killed.
I am an administrator for a small-medium sized wormhole group. This will kill my ability to actually manage my infrastructure without introducing immense overhead. It is unacceptable that the caching is 1 day.
However, since this is caused by a bunch of less pleasant people, Iād like to propose a solution.
Allow me to link the IP-address of my server to the Developer Key. This means that itās one key per server, resulting in you being able to shut down abuse while those who actually adhere to the rules can keep using the platform. Youāre still able to use different hosting solutions but it is limited how it can be abused.
Edit: Additionally, allow development API keys only when the account has been Omega subscriber for at least 3 months. That way youāll at least get the most problematic spam reduced and make it so people need to actually play the game / pay for AFKing (and not just DDoS your ESI environment)
Neither AA, SeAT or Seatplus is affected by this as these all use the affiliation endpoint and donāt rely on the character endpoint.
1 Like
So why has everyone got their knickers in a knot?
@Awox
Effectively this change means a lot of tooling will break. CCP didnāt tell us ahead of time and the reason for this change is because SOMEONE is unable to adhere to the rules and is using AWS to flood the entire ESI platform; kiling it.
How much ahead of time did you want? Before it happened.
probably, because people tend to be not as informed as they could have been.
Generally these kind of things should be way ahead (like months) so that devs can adjust. I understand why they didnāt but there are solutions; they just donāt want to put those solutions in.
Because this marks a pattern of CCP attempting to band-aid ESI
ā¦and on this episode of shoot first and ask questions laterā¦the overlook of WH corps continuesā¦
Hey everyone!
Just to let you know that Iāve updated my original post with a few extra details but we have adjusted this back from 7 days to 1, which was what it originally was, this afternoon. This may again be increased in the future if the requests are found to impair the server.
A recommendation from the team also suggests using as many of the authād endpoints as possible for future development, as those are easier to maintain uptime for. For this case, the affiliation endpoint may prove to be more beneficial in the long run!
As before, Iāll keep this post updated should any further changes be made.
6 Likes
Make caching dynamic? The more an end-point is being hammered from one ip for the same parameters, the longer the refresh delay?