{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigrwhzdhpp3st75wki4azp3lk2gwmh6hyeqvzfygzyvysxy27pzta",
    "uri": "at://did:plc:qfsyszxhq5agxsg2n5zo4lno/app.bsky.feed.post/3mory7ubbobc2"
  },
  "path": "/t/why-do-i-see-i-1-at-the-end-of-a-url/49356?page=2#post_32",
  "publishedAt": "2026-06-21T08:42:37.000Z",
  "site": "https://forum.infinityfree.com",
  "tags": [
    "Ifastnet",
    "iFastNet",
    "IFASTNET"
  ],
  "textContent": "aauthentication:\n\n> Stupid way\n>  Pretty sure you could recreate this without params with nearly the same amount of code\n\nIt’s harder than it looks. But if you have any specific ideas on how to achieve this, I’d like to hear them.\n\nPlease keep in mind that the reason this parameter is added is for the cases where the browser does execute Javascript but doesn’t store or send the cookie. Just leaving out the parameter would result in the security check being hit continuously, which triggers an endless loop. The parameter is designed to break that endless loop.\n\nAny system to replace it would need another way to track state. Tracking state across requests is usually done with cookies, but cookies not working is the only reason why this system is needed.\n\nThis browser validation system is also just the most visible part of a suite of security checks we run. There are also less visible parts, including IP rate limiting and user agent detection to block bad traffic.\n\naauthentication:\n\n> Atleast let us make our own security system, then submit it for review or something, if it’s good enough it can stay instead of this “?i=” system.\n\nThe problem is that it cannot realistically be good enough.\n\nOur system is very lightweight and blocks attack traffic with minimal server load, long before hitting your website code. Anything you could build into your own website runs after the request already reached it, so it can’t match that.\n\nAlso, basically any time when someone says “I want a different security system”, what they actually mean is “I want a less intrusive security system”, but “less intrusive” also means “less effective”.\n\nAnd good to keep in mind: protecting your website against attacks doesn’t just benefit you, it benefits everyone. A website being attacked generates excessive server load, which hurts performance and availability for other websites on the server too. So we cannot just let you weaken the security of your own website.\n\nThat’s also setting aside a whole category of practical issues. A custom system would require us to design standards for it to conform to, contribute engineering effort to review the code, potentially implement and support integration points, and then monitor on an ongoing basis whether the system stays effective and isn’t weakened after the fact.\n\nSo no, per-site custom security isn’t going to happen. There is going to be one solution, applied system wide for all websites. What that shared system actually looks like is something we can debate.\n\naauthentication:\n\n> Unless it’s required by Ifastnet, I suggest you replace this.\n\nIt is setup by iFastNet, so I cannot “just” replace it. But the people at iFastNet are reasonable, and are willing to consider good ideas.\n\naauthentication:\n\n> By the way, if you make plans that ARE NOT CONTROLLED BY IFASTNET, even if it doesn’t affect hosting that much, I would buy it\n\niFastNet’s premium plans are genuinely good, and don’t have this system. Any plan I could offer either keeps the core hosting the same, just with a few extra features, or means building a completely parallel platform to iFastNet’s premium plans, which would just be redundant. Either way, there is not going to be anything that’s substantially different from anything available today.",
  "title": "Why do I see ?i=1 at the end of a URL"
}